I read your reply and found it useful in my web site.
Furthermore, I need some more information regarding this.
I wish to prevent unathorised user /user whom idle after 30 minutes
from viewing the page( there are quite a number of pages, > 500 .asp
files) if they were to view it, they need to re-logon.
1) Can you show me the sample of checking cookies on top of each page
2) is there any other way to check on each asp file, instead of 
checking the presense of cookie on top of EACH file, can i have something
to check all the files under a folder, so that i needn't modify
every single of the file.

thanks,
caryn.


> Anand said previously in response to Richard's question:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ::: 1) How can I destroy the authentication information on
> ::: the client without closing the browser.
> ::
> :: call <% session.Abandon %> to destroy the
> :: authentication information.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Richard then asked:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> : Is there a trick to get session.Abandon to work?
> :
> : If I have basic authentication set for my site on the directory,
> : and call a page I get the login box.
> : If I go to another page via a form post that contains the
> : session.Abandon,and then go back to the first page everything
> : works, but there is NO request for authentication.  As long as the
> : browser stays open I have an authenticated link.
> : This is bad.  Any ideas?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> I think Anand was getting confused between sessions and authentication.
> They are very different things.
> 
> When your browser requests a page that you have marked as requiring 
Basic or
> NTLM authentication the browser sends back a Request Denied, 
Authentication
> Required header. The browser will then popup a dialogue box asking the 
user
> to input his/her credentials, which will then be sent back to the server 
as
> part of a new request for the same resource. This new request will use
> either Basic or NTLM authentication (depending on what the browser is
> capable of).
> 
> On each subsequent page request on that machine the same authentication
> information will be sent transparently by the browser, until the browser
> window has been closed.
> 
> Sessions are completely different, and used for primarily for managing
> state - not for authenticating users. When the user issues a request for 
a
> webpage from a site a new session is created. A sessionID is assigned to 
the
> browser - this is stored by the browser in an in-memory cookie. Session
> variables created for that user are stored by the server in the server's
> memory, and are associated with the browser by the sessionID. The browser
> returns this sessionID cookie on each subsequent page request and thus
> allows the server to associate the variables in its memory with the 
request.
> 
> Judging by what you want to do, I would probably suggest changing your
> authentication method...store the usernames and passwords in a database 
or
> similar. Use a SSL link to get the usernames and passwords from the user,
> and if they are authenticated set a cookie that will expire after a 
certain
> amount of time. At the top of each page, check for the presence of this
> cookie, and reset the time for expiry to again be Now() + 30 minutes (or
> whatever). If the cookie is not present (either the user never
> authenticated, or the cookie has expired) then redirect to the logon 
page.
> 
> Does that help?
> 
> Cheers
> Ken
> 
> 
>