Hi

My site requires security, for which I have used Login pages.
My implementation is that, ALL the pages that require a login have the following code in them....
-------------------------------------------------------------------
<%
Response.ExpiresAbsolute = Now() - 1
Response.AddHeader "Cache-Control", "must-revalidate"
Response.AddHeader "Cache-Control", "no-cache"
%>


<% if Request.Cookies("CID")="" then
response.redirect "Login.asp?nextf=add.asp"
else
'HTML Page information...
%>
-------------------------------------------------------------------
I check if he is logged in and if so, display the page. I not, I redirect him to the Login page.

There is a sequence of such sucure pages in my site. But the problem with the above code is that, he is NOT able to use the browser's back button to navigate to the previous secure pages back and forth.

Now, if I try to REMOVE the first part(Code 'A') of the above code,i.e.,
---------
Code 'A' follows....
---------
<%
Response.ExpiresAbsolute = Now() - 1
Response.AddHeader "Cache-Control", "must-revalidate"
Response.AddHeader "Cache-Control", "no-cache"
%>
-----------
then even after he logsout, he could use the browser's back button to visit the secured pages. So, removing this doesnt help me either.

Any clues abt. how to impose security while letting him navigate as long as he is logged in?

To be more clear,
I want 2 things to happen....
1. I need the LOGGED IN user to navigate back and forth among the secured pages(which is NOT possible if Code 'A' is present in the secure pages).
2. When the user tries to use the browser's back button to navigate to a secure page AFTER he is LOGGED OUT, he should NOT be allowed to view the page.

Any help is grately appreciated!

Thank you very much.

-Srivalli.

Why not just use a session cookie and control the contents upon login and logoff...

First set the Session variable GoodUserX upon Logging in, with say the user name.

And, upon logging off, set GoodUserX = "LOGGEDOFF"

Then, on all your pages, add code similar to the following...

Tim

Thanks MrWizard for your reply.
I got it working right!
Thanks again.

Yes, it just doesn't work to fiddle around with "back." But if the session-ID is zapped on the user's workstation, and the saved session-information is changed to "user is logged out" (in case the user somehow presents the session-ID again), any attempt to go back will simply lead to the login-page.

(That is, the user will wander back to the old page, and you'll see he's not logged-in, and you'll redirect him to the login page.)

Incidentally: any time you're doing something that deserves "logging in," you also need to make sure that the HTML interaction is secure (https://).

Don't allow information that's supposed to be protected by login, including the user/pass sequence itself, to go across any network unsecured.

Hi sundialsvcs,

Thanks a lot for the information you provided!
I shall use https while connecting the user to any other site! this way, no one can crack my id/password. correct?

Thanks again.

-Srivalli.

In order to use https you have to purchase a ssl certificate (or your hosting service does) - which I have not seen mentioned in this post.

Yes, you probably need to purchase an SSL certificate, for which there are several competing vendors. (Thawte and VeriSign are probably the most expensive.) Your hosting company will probably have links, and maybe discounts, for that.

But let's discuss, simply, what this technology does, and how it relates to the "security" of a page.

The so-called "Secure Sockets Layer" (SSL) is a way: (1) to encrypt the information that flows across the Internet (to prevent interception); and (2) to authenticate the transmission so that the user can have reasonable confidence that the site he is talking to, really is the site he thinks he's talking to (that is, if he cares to actually check).

(SSL relies upon these "certificates" to accomplish the authentication. Certificates are 'issued' by a 'certifying authority' whom presumably is trustworthy, and they are built to be hard to counterfeit. If authentication is not important to you then you can "roll your own" certificates, which will work for encryption only.)

What this gives you is a secure two-way link between the user's machine and your web-server. If you check that the link is secure, starting with and including the initial user/password prompt, then you can indeed be reasonably confident that any information you're transmitting isn't being intercepted and also isn't being "spoofed" to you from someone else.

Does this make a website "secure?" Well, yes and no. Remember that you can build the most "secure" bank vault door in the world but it won't do you any good if you put it in the wooden wall of a balloon-frame house! SSL will provide you with a reasonably-trustworthy channel of communication and nothing more or less. It can be used (and definitely should be used) for the TCP/IP links to your SQL server de jour, and for any other situation where confidential data needs to flow across any public network. It also creates the all-important perception of security: "the little padlock is closed."

Great!
Thanks sundialsvcs and rnealejr for the information you provided.

-Srivalli