Implementing a Simple Login State Mechanism

s ASP programmers, you have probably received a request to password protect a portion of the Web site you are developing. The client wants the user to access pages A, B, and C—only after logging on with a valid user ID and password. One obvious mechanism to enforce this is to use the Web server's security mechanism and control access to those pages, or even to a sub directory. Instead of allowing "anonymous" user access, which is the default, you can turn on Basic Authentication or Windows NT integrated authentication. The only problem with this scenario is that you need physical access to the Web server (and many Web developers have to toe the line with a Web master , DBA, or network administrator who "owns" the Web server). Secondly, you will need to create the user ID's and passwords as user accounts on the local machine.

A second technique is to enforce authentication via an ASP page itself. For instance, you may have a login.asp page that asks for a user ID and password. Only if the user is authenticated against data in a database (which is much easier to maintain than NT user accounts), are they allowed to proceed to select pages. This technique has its own problems. Each page now needs to know the state of the login—has the user passed the authentication process in login.asp and is being redirected here, or is the user accessing Page B on its own merit, bypassing the login page altogether?

To handle this scenario, you need to maintain the login state. You can have a range of techniques to solve this issue—from simple to very complex procedures depending on how sensitive the information in the pages is. For example, if you were building an online banking application, I would recommend being very paranoid, and opting for a complex solution. However, if you are building less sensitive applications, a simple login state mechanism should be enough.