I think by now, most ASP.NET developers have come across some of the different provider models in ASP.NET 2.0. Most likely the Membership, Roles and SiteMap provider but also the custom provider model that you can use to create your own providers.

Still, I often come across custom authentication and authorization mechanisms instead of using the Membership and Roles provider model. Typically, a business object called User has a Logon method that does the authentication and returns a Boolean back to the login page, which sets a cookie and maybe session variable and then redirects the user to the password protected area of the website.

Then there’s usual also some custom authorization mechanism that prevents certain logged in users from certain areas such as admin pages. The menu is custom designed to hide and show only the pages available to the current user and the individual pages also makes the checks.

That is a common scenario and I see it very often. If you have such a scenario on your web application, then consider converting your existing logic to use the provider model. By creating a custom implementation of the Membership, Roles and SiteMap provider, you get all this for free and it is very simple to do so. You can keep your existing code and then build the providers on top of that.

The benefit is that these three providers work together so that the SiteMap automatically shows only the pages a user has permissions to see based on her role. You also get the cookie management for free. But the best part is that you can easily switch to a new provider when needed without changing your existing code. I did that today when I installed BlogEngine.NET on our intranet at ZYB. It had to use the Active Directory Membership provider so that we could log on using our network credentials. It took me 5 minutes to make the transition from my custom XML Membership provider to the Active Directory one. There’s a good guide at MSDN for using the Active Directory provider.

That flexibility comes free of charge with ASP.NET 2.0 and makes the lives of all .NET web developers much easier, more flexible and powerful. I have published my XML Membership provider and will wrap up the XML Roles provider soon and publish it as well.

When you first try the provider model, I promise that you’ll never go back.

Resources

• Video: Create a Custom Membership Provider
• Sample Role provider implementation
• Membership and Role providers in ASP.NET 2.0
• Examining ASP.NET 2.0's Site Navigation
• SiteMap provider introduction

I was recently made aware of a peculiar bug in BlogEngine.NET that would delete all posts, comments and pages. Now, this specific issue is not new, but it was new to me so I thought I would share it with you. Maybe it’s new to you too.

The scenario is extremely rare and that’s why I’ve never come across it before. Here’s the step to reproduce this issue:

1. Sign in to your BlogEngine.NET installation using Internet Explorer.
2. Open Microsoft Visio and use it’s reverse engineering to generate a sitemap of the blog.
3. All your posts, comments and pages are now deleted.

The reason you need to use Internet Explorer is that Visio and Internet Explorer share the same cookie container behind the scenes. The cookie you got when you signed in using Internet Explorer is still present when you open Visio and therefore you are still signed in when you use Visio.

Ok, so now you are signed in using Visio and you start Visio’s crawling feature and point it to your blog address. All the delete-links under each post, comment or page gets crawled and thereby you delete them all.

The protection

It’s very easy to protect against this kind of bug. Just change the delete-links. This is an example of an unprotected link:

[code:html]

<a href="?delete=1234" onclick="return confirm('Are you sure?')">Delete</a>

[/code]

And this is the protected version

[code:html]

<a href="#" onclick="if (confirm('Are you sure?')) location.href='?delete=1234'">Delete</a>

[/code]

The difference is that now you can only delete if the client supports JavaScript, which of course Visio doesn’t. Remember that this is only an issue if you are signed in, so this is not something everybody can do and that is why I’ve never come across it before. In other words, it is not a dangerous bug at all and by fixing the links you will just be protected from your self.

The point is that if you expose delete-links on your page; make sure they are protected from Visio and other applications that share cookie container with Internet Explorer.

FYI, this has been corrected in the upcoming 1.2.5 release of BlogEngine.NET due in about a week.