Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Implementing a Simple Login State Mechanism  : Page 2

Enforcing authentication via an ASP page requires you to maintain login state.


advertisement

Two Common Techniques
So how does page A, B, or C know that a successful login has taken place? One technique is to check the value of a session variable. The login page, on successful authentication, sets the value of a session variable to True:


Session("LoginSuccessful") = True

Each of the subsequent pages checks the value of this session variable and either allows the user to proceed or redirects the user back to the login page:




If Session("LoginSuccessful") <> True Then
	Response.Redirect "login.asp"
	' - or in Windows 2000, this is better code
	' - Server.Transfer "login.asp"
End if
...
... The rest of the page's code here
...

This technique relies on session variables, a definite no-no when working with Web server farms where more than one machine can handle requests to the same Web site. In this case, it's possible that Login.asp may be served by Server 1 and the subsequent calls to page A, B, or C can be handled by another server.

Because session variables are limited to the Web server on which they are created, the other servers will not be able to access the value. In this situation, you can have valid users who have been authenticated already being denied access to pages simply because the session variable value does not exist. Another issue is that the session variable's value is maintained for about 20 minutes, even after the user closes the browser. So, if the user is checking for some data on your site after logging in (say the user is checking their e-mail) and uses a public Web terminal—a kiosk or a public machine in a library, for example—any user who uses that machine after the legitimate user has closed the browser and walked off can access the data even without logging in. If there are any other browser windows still open, all they have to do is to type in the URL for your pages in the browser, and poof—they get to see the data because the session variable value is still true! Definitely not a good idea!

Another technique is to make sure that select pages never accept requests directly from the browser but always be "referred" from another page within the same site. You can check the value of the page that referred another page by using the HTTP_REFERER server variable. So, in each of the subsequent pages, you can check for the value:


If Request.ServerVariables("HTTP_REFERER") <> SomeValidValue Then
	Response.Redirect "login.asp"
	' - or in Windows 2000, this is better code
	' - Server.Transfer "login.asp"
End if
...
... The rest of the page's code here
...

The question is: what will you use for the value of "SomeValidValue" in the code above? Should it be "login.asp"? That may not always be possible. How about just checking for the initial X characters and making sure that it equals your Web server or domain name? For example:


If Left(Request.ServerVariables("HTTP_REFERER"),19) <> "http://www.mydomain" Then

I have found that HTTP_REFERER is not always reliable. Its value depends on the browser type, the means by which the user arrived at the site and probably other factors I don't know about. I have found it to be very fickle—let me know if your experience has been different.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date