The Membership provider in is great. As is the Roles support. You can do some very nifty things with it with a considerable amount of ease. You can get hashed or encrypted passwords and a whole host of features that’s pretty much enterprise grade. And you get it for free. Well, not free, but it is pretty easy to set up.

But what if your website only needed two or three user accounts? What if you didn’t need all that fancy stuff. You just want to use a login system that’ll just block off an admin area or something and you want to do it quick and dirty. Maybe it’s a prototype. Maybe it’s your own little site where you just want simplicity for authentication. I’ve actually went through all the aspnet_regsql.exe trouble for a very simple site that would have just one user. Sounds like overkill? It is.

The login controls provided in 2.0 are quite handy, but they mostly work with a membership provider. The <asp:Login> control is specially helpful for creating a login screen in no time. But it too works with a Membership provider.

So how can we quickly setup a login system without using a Membership provider? And how can we use the <asp:Login> control to set up the login screen when using such a system? Read on…

Forms authentication actually allows you to store usernames and passwords in the web.config file. A typical web.config file doing this is shown here:



I’ve highlighted the important parts. The authentication mode needs to be Forms. The PasswordFormat is left as “Cleared” here. It can also be hashed or encrypted. I’ll make a post in the future about hashed and encrypted passwords. I’ve added a single <user> to the credentials node. You could easily add more. In the <authorization> node, I’ve allowed all users. In the <location> node for the “admin” folder, I’ve set it to deny all unauthenticated users. So, if a user is logged in, they can access the admin folder. If not, they’re asked to login.

Now, with this in place, if you were to put an <asp:Login> control on a page and expect it to work just like when using a Membership provider, then you’re in for a nasty surprise. Even if you enter the correct username and password, it’ll tell you the login has failed. Why? The reason is pretty simple. We’ve not mentioned a Membership provider to use, so defaults to the Membership provider in the machine.config, which usually is an sql membership provider drawing info from a database in App_Data. That database has no info about our user named admin with the password “pa$$w0rd!”. So, logging in fails. How do we overcome this? Simple. Just add a handler for the OnLoogingIn (NOT OnLoggedIn) event of the <asp:Login> control and in that handler, do this:


[If you don’t want the authentication cookie to persist between requests, set the second parameter of RedirectFromLoginPage to false.]


That’s all there is to it.

Now, that was very simple, but the question that pops up is is it secure?

Well, the answer is both a yes and a no. It’s yes in the sense that IIS will never serve anything with a .config extension from an outside request. So, users on your site will never be able to download the web.config and look at the username and passwords. The “no” part of the answer comes from the fact that if someone can look inside the web.config file, they’d be able to see the usernames and passwords. If you run your own server or have a hosted account that only you access, this is not that big a problem. [I add the latter coz no hosting company is ever going to go through the risk of looking inside of clients’ files for passwords.] For extra security though, you can use hashed or encrypted passwords in this system too, which I’ll cover in a future post.

A drawback to this is that the web.config file can get very big for a lot of users. But then again, this isn’t meant to be used for a lot of users. This is meant for very simple sites woth very few users. There are sites out there that are like this and don’t need all the Membership gloss. If your site’s like that, you can easily use this method.


Hope that helps.

Shout it