Sad as it may be, it leaves me available for hire, to do Umbraco or EPiServer work, wherever I may be needed. I have several years experience, and am certified, on both platforms. I work well in teams, and solo, and you're really missing out if you don't hire me. If needed, I'll travel for start up meetings etc. So don't hesitate just because I'm Swedish. I'm that good.

There's an online resume-ish site here. And I'll even send you a PDF with more info, if you still have doubts.

I know, cheap trick, but I have a family to support. :)

I'm not going to cover the validation/SEO friendlyness here, not because I believe that what they said was bullcrap, but rather because I believe that their approach doesn't give the client the freedom of choice I think goes hand-in-hand with using a large scale CMS like EPiServer. When a client uses EPiServer, and tires of their development partner, they should be able to switch over-night. Furthermore, development time is, and this is only my personal oppinion, increased, since developers have to build their own post-back mechanisms. But enough on that, what they said mostly made sense :).

XSS, or Cross-Site-Scripting, is when someone injects HTML or a script, into a site. There are two different kinds, Non-persistent/Reflected or Persisted/Stored.

The Reflected approach is when someone exploits a XSS vulnerability, for example, modifies a querystring parameter so that html and/or javascript is rendered directly onto the page. They then spread a link to their modified URL, and anyone logging on there might be subjected to some form of fraud or some other malignant attempt at their data.

The Stored approach is when someone submits, for instance to a forum or blog comment, html and/or javascript that is then stored on the page for other visitors to be subjected to. Like as if a blog comment here would contain html and javascript that would render a login form on every page, but when fileld out, would send that data to a third party. In short, it would suck. Big time.

Now, how to protect yourself?

In short: Don't allow HTML being posted to your forms. Oh, and check for scripts too.

OK. But that won't always do. I know, so here's a few more lengthy pointers.

1. Enable validateRequest in web.config in system.web/pages - if this isn't an option for you, i.e. EPiServer's editor won't work, consider using it in combination with your <location> segments, only disabling it where absolutely needed.
2. Clean your output. HTML-Encode any input sent from the user, or use RegEx to clean those tags/attributes that can cause harm. For me anyway, RegEx is awesome, but I can NEVER seem to learn them.
3. Implement The Microsoft Anti-Cross Site Scripting Library
4. Evaluate your content, and look for vulnerabilites. Repeatedly.

Here are some useful links for those that want to know more.

• XSS Prevention Cheat Sheet
• Security Compass Exploit-Me Firefox Add-On
• XSS on Wikipedia
• The Microsoft Anti-Cross Site Scripting Library

So, what then is that other abbreviation, CSRF? CSRF, or Cross-Site Request Forgery, is when a malignant website uses valid data from your browser, like hi-jacking a validation cookie, and sends a request with that valid data, in your name. This was a wake-up call for me.

A possible scenario is, when you're out in your sunday best, couch-surfing. You check your mail at Gmail in one tab, and doing some "grown-up's surfing" in another tab. Your browser then has an authorization cookie for Gmail, certifying that you're logged in, and everything is A-OK. The grown-up-site you're watching has some malicious code on it, that tries to send data to Gmail behind your back, and since your browser is authorized, Gmail accepts that incoming request, forged as it may be.

Working around this can be a hassle, but it isn't impossible, here are a few tips.

1. Implement an ANTI-CSRF HttpModule.
2. Check the referrer header, and make sure it's your site making the request. It can be found in HttpContext.Request.UrlReferrer.
3. Make sure that any crossdomain.xml doesn't allow everything. This is a Flash thing, so if you don't have any Flash on your site, you don't need to bother.
4. Limit the lifetime of authentication cookies.
5. If you're using ASP.NET MVC, use the Html.AntiForgeryToken() helper in conjuction with the [ValidateAntiForgeryToken] attribute on your post method.

Here are some useful links for those that want to know more.

• .NET CSRF Guard
• CSRF on Wikipedia

I'll be testing Umbraco in general, and the Blog4Umbraco package specifically, for XSS vulnerabilites in the next few days, I'll keep you posted.

Finally, thanks to Sergio Molero at Concrete IT for an excellent presentation.

So far so good. But as with all serializable objects, they need to have a default (parameterless) constructor. And I want my objects to behave, remember?

Enter another useful attribute. OnDeserialized.

[Serializable]
[DataContract(IsReference = true)]
public abstract class Element {
...
[OnDeserialized]
private void OnDeserialized(StreamingContext context) {
if (this.Children == null) { this.Children = new ElementList(this); }
//Make sure that any new child added gets a correct reference to its parent.
if ( this.Children.Element == null) { this.Children.Element = this; }
//Make sure that all children have correct parental references.
foreach (Element e in this.Children) { e.Parent = this; }
}
...
}

This will be executed every time my object has been de-serialized, enforcing my constructor logic.

Now, as far as I'm concerned, that's behaving.

Making sure that my object kan be serialized is simple, we just add the [Serializable] attribute to it.

[Serializable]
public abstract class Element {
...
}

However, since my object has a reference to its Parent object, serializing it will most likely result in a cyclic, never ending, recursion. Fail.

Enter the DataContract.

[Serializable]
[DataContract(IsReference = true)]
public abstract class Element {
...
}

By applying it to my class, it enables serialization and deserialization with, for instance, the DataContractSerializer. I simply apply the [DataMember] attributes to all members I want to serialize, and voilá, I get a nice and clean, reference enabled, serialization.

But, you might ask, how does this work with the fancy List implementation we did?

Simple, there's a [CollectionDataContract] attribute available for that. That ensures that my List gets serialized to exactly that, and not a stupid array.

Next up: What happens on deserialization.

Attempt 1: Adding Add and Insert methods to the Element

public abstract class Element {
public Element() {
this.Children = new List<Element>();
}
public int ID { get; protected set; }
public string Name { get; protected set; }
public virtual Element Parent { get; internal set; }
public virtual List<Element> Children { get; private set; }
public string Instructions { get; set; }

public void Add(Element item){
item.Parent = this;
this.Children.Add(item);
}
...
}

This solution works all-right for many cases, however, it doesn't solve the issue when the Add method is used on the List<Element> directly. We'll want this.

Attempt 2: Changing the List type

public abstract class Element {
public Element() {
this.Children = new ElementList();
}
public int ID { get; protected set; }
public string Name { get; protected set; }
public virtual Element Parent { get; internal set; }
public virtual ElementList Children { get; private set; }
public string Instructions { get; set; }
}

public class ElementList : List<Element> {
public Element Element { get; internal set; }
public ElementList(Element element) {
if (element != null){ this.Element = element; }
else { throw new ArgumentNullException("element"); }
}
new public void Add(Element item) {
if ( item.Parent == null) { item.Parent = Element; }
base.Add(item);
}
new public void Insert(int index, Element item) {
if (item.Parent == null) { item.Parent = Element; }
base.Insert(index, item);
}
new public void InsertRange(int index, IEnumerable<Element> collection){
foreach (Element e in collection){
if (e.Parent == null) { e.Parent = Element; }
}
base.InsertRange(index, collection);
}
new public void AddRange(IEnumerable<Element> collection) {
foreach (Element e in collection) {
if (e.Parent == null) { e.Parent = Element; }
}
base.AddRange(collection);
}
}

This solution ensures that all Elements added to an ElementList, gets their Parent property re-set to reference the ElementLists Element property. This way, one can always assume that an Element's Children, always have their Parent references set.

Next up: Serialization.

public abstract class Element {
public Element() {
this.Children = new List<Element>();
}
public int ID { get; protected set; }
public string Name { get; protected set; }
public virtual Element Parent { get; internal set; }
public virtual List<Element> Children { get; private set; }
public string Instructions { get; set; }
}

The problems:

How to make sure that any objects added to the Children property, gets a correct reference to the parent object (this)?

How to make sure that my object can be serialized in an orderly fashion?

How to enforce that initialization is done properly once the object has been de-serialized?