By John PetersonScript Output:
Access Denied! Hint: Both the login and password are 'Guest'. Note that they are CaSe SeNSiTiVe!
So you're running your web site and all of a sudden you think 'Hey, what if we had an area that only certain people could get into....now that would be cool!' So how do you do it?
Well that's a debate that has plagued many a newsgroup and web site, so we're not really gonna get too far into that, but if you just wanna keep the pesky people out and let the people who need access in, here's a quick and flexible solution that will work wonders!
Please note that this is exactly that....a quick and relatively simple login and password check. It isn't as secure as SSL. It doesn't come close to using NT challenge and response. Heck, it's not even as secure as plain text NT password validation. But here's what it does get you. You get a simple login and password check that can pull it's validation from any source you can access (hint! hint!) from ASP. It prevents you from giving out unnecessary NT domain passwords (generally a good idea since the log on locally right is required by users of the web server for some unknown reason!). It also doesn't tie you up for hours writing an authentication filter that by the time you get written you decide needs more features (you did get it finished, right?). And finally, it's simple enough for us here at ASP 101 to figure out.
A few more words of warning. While no security system is perfect, this method depends entirely upon your coding being sound in order for it to work at all. The check needs to be in each file you want to protect which means two things. First, you can only protect ASP pages. Secondly, you'll probably want to use a server side include (similar to the one below) at the very top of every page to ensure consistency. This sample assumes you stored site access levels in a session variable when the user logged in. The actual variables and how you test them will naturally be site specific.
The line in the file to be protected would look like this: <!-- #INCLUDE FILE="./secure.asp" --> The file included would look something like this: --- Begin secure.asp --- <% If Session("ValidatedForThisPage") = FALSE Then Response.Redirect "LoginPage.asp" Else Response.Write "<!-- Validated at " & Now() & " -->" End If %> --- End secure.asp ---
Note the .asp extension on the include file. We recommend this as opposed to the traditional .inc extension so that you don't run the risk of someone directly accessing your include file and learning the implementation details of your password system. The more someone knows about your security system, the easier it is for them to bypass it.
You can replace the correct criteria and paths with ones applicable to your scenario. You can also display a message instead of redirecting them to the login page. Just make sure you do a Response.End afterwards! Using this method, you can create an include file for each set of rights you want to check. That way, if you need to change how or what you check, it only needs to change in the include file which not only saves typing but also stops mistakes and possible security loopholes from appearing. (That's assuming you get code right in the include file!)
There are many different implementations of this method floating around which provide features we do not. Our goal here, as with all our samples, has been to introduce the topic to you. We feel that if you need a specific additional feature, it makes more sense to build upon simple code that you understand, in order to implement it yourself, rather than to just take a 50 line script that you found somewhere and use it's features without an understanding of what it is doing and what loopholes or drawbacks its implementation may contain. We're not saying that everything you use, you need to have written from the ground up! What we are saying is that, in a case like this where so little code can get the job done so well and with so little room for error, it makes you wonder not only what all those lines of the code are doing, but also just how cleanly are they doing it. In closing, at least take a look at what a script does before you use it! That's especially good advice if it's one of our scripts! ;)
One of our visitors has gone and written a DB-connected version for those of you looking for one.
Dear ASP 101,
I really liked your login script on your samples page, but agreed that the values for the login and password should come from a table as opposed to being hard-coded. To help beginners who wouldn't know how to perform this relatively simple task, but who have managed to get a DB online, why don't you add an improved security login script to your samples page. I'm sending you a copy of my rewrite of the script. Feel free to do any editorial work!
Thanks James. Those who want to take a look can download James' version from here. I took the liberty of doing some cleanup as well as including a sample Access 2000 database.
Database-Connected Auto-Navigation Version
A while back I received the following email from one of our readers.
I am completely new to ASP and I am having a very hard time with a script that I am working on.
What I am trying to accomplish is to get a script that will log in users, but I want it to send them to specific pages depending on their user name and password.
For example, if I have an MS Access table something like this:User Password Link me letmein me.asp you password you.asp he passwd he.asp
How can I achieve this? It is driving me nuts.
I appreciate the help. Thank you,
name removed to protect the guilty ;)
Accomplishing the above is really not all that complicated, but it can be a daunting prospect if you don't know where to start. Naturally I'm going to give you the finished code, but all I really did was combine the database driven version above with the basic premise behind our Pulldown Navigation sample. Granted I had to add some code, but the building blocks were there, just waiting to be combined. You'll find that's often the case... just try to think of things in terms of the individual things that need to be done and you'll most likely find them less daunting.
You can download a zip file containing the new script, the sample database, and the original database-driven version (for comparison) below.