By John Peterson
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
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
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.