Three interesting things about Apple Safari came out this past week.

1. Apple Safari 3.1 passed the Acid 3 test
2. Apple Safari running on a Mac was hacked in 2 minutes flat at PWN To OWN and fell in the second round using a default install of Mac OS X software.  Even Vista made it to the third round where it was successfully hacked through the Adobe Flash plug-in for IE 7.
3. Apple is pushing Safari to Windows users with out their permission.

In my opinion it is great that the Apple Safari team is working very hard to support web standards. However that should be secondary to building a secure browser platform that is going to protect their user base.  This should be obvious to every developer with in Apple, because Acid 3 features aren’t currently out on the net, so support isn’t that critical, however browser exploits are out there right now just looking for prey.

Combine all that with Apple pushing Safari out to Windows with out asking for permission from the user of the computer.  Windows already has enough problems with security and doesn’t need a new one pushed on it by Apple.

There is a simple way to tell if you can use MVC in your web application.  If any of the following are true, you probably shouldn’t:

1. You require the ViewState
   This includes any 3rd party control…  Quick way to check this is disable ViewState and check to see if you application works as expected.
2. You require post backs
   This usually is required by Web Forms or Microsoft AJAX Toolkit…  Fortunately most of the post back functionality can be duplicated on the client side with AJAX.  I fine jQuery makes a real easy job of this.

So that is all that you need to ask your self when thinking of upgrading or deciding which route to take when planning your new application.

So I just read Rob Conery’s blog post on Securing Your Controller Actions in MVC. I was a little perplexed about why guys at Microsoft love to reinvent stuff they have already done. I know Rob Conery is a really smart guy and has a wonderful grasp of the .NET framework, so I would have to assume he knows about what I have outlined below. My only guess is that he just wanted to re-invent something that is already built in to the framework using his own code.

Basically what Rob did was the following, created two attributes for attaching on the MVC Controller Action:

RequiresAuthenticationAttribute

[RequiresAuthentication]public void Index () { 
    RenderView("Index"); 
}

RequiresRoleAttribute

[RequiresRole(RoleToCheckFor = "Member")]public void Index () { 
    RenderView("Index"); 
}

I have accomplished the same thing using an attribute that has been apart of .NET since 1.0. The attribute is called PrincipalPermissionAttribute and is part of the System.Security.Permission namespace. The best thing about it is that it is integrated in to the run time, so there is no chance of unwanted people getting through. It also accomplishes both of Robs attributes up above, plus more. Using the examples up above I will demonstrate how to use PrincipalPermissionAttribute to secure and protect your Controller Actions.

RequiresAuthenticationAttribute

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]public void Index () { 
    RenderView("Index"); 
}

RequiresRoleAttribute

[PrincipalPermission(SecurityAction.Demand, Role = "Member")]public void Index () { 
    RenderView("Index"); 
}

In addition if you were inclined you can restrict things to just one user name with PrincipalPermissionAttribute. So for instance if you wanted to restrict adding and removing roles and their permissions to only the username “SiteAdmin”, you would do the following.

[PrincipalPermission(SecurityAction.Demand, Name = "SiteAdmin")]public void RolesAdmin () { 
    RenderView("RolesAdmin"); 
}

As you can see this is very powerful. Built in to the run time, by extending the CodeAccessSecurityAttribute, so it operates at a lower level than Rob’s solution. Only requires the use of one attribute, and throws only one exception called SecurityException.

I really hope that ASP.NET MVC doesn’t turn in to a lets-redo-everything-that-already-works framework, because they still have many issues that they need to achieve before ASP.NET MVC is usable, and focusing on things that are already implemented in the .NET framework doesn’t seem like the right course of action when developing a new offering.

Read more