Wrox Home  
Search P2P Archive for: Go

  Return to Index  

security_asp thread: Destroy authentication information?


Message #1 by "Richard Blair" <rblair@s...> on Tue, 6 Mar 2001 11:04:30 -0600
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




  Return to Index