Logout form secure site

[gary thomson]

Apologies if this is not quite the correct ng to be asking this
question and sorry to be so vague in what I'm asking, but can anyone
give me any pointers to implementing a logout button from a secure web
site. Ie I want to supply a means to users of our staff extranet so
that their sessions may be closed securely at will. They login with a
user name and password and then they can end the session so that the
browser returns to a page outside of the secure area of the extranet
and the password is removed from their cache.

TIA

[Boris]

gary thomson wrote:

Apologies if this is not quite the correct ng to be asking this
question and sorry to be so vague in what I'm asking, but can anyone
give me any pointers to implementing a logout button from a secure web
site. Ie I want to supply a means to users of our staff extranet so
that their sessions may be closed securely at will. They login with a
user name and password and then they can end the session so that the
browser returns to a page outside of the secure area of the extranet
and the password is removed from their cache.

A session ties various stateless HTTP requests by sharing some data across
these requests. This is done preferably on the server side using session
variables in PHP, ASP or whatever. These session variables are saved
somewhere, eg. in a file. When someone logs out the store with the session
variables simply has to be deleted. How this is done depends on the
technology used. Therefore it might be better to ask in a PHP, ASP or
whatever group.

HTH,
Boris

[Alan J. Flavell]

On Mon, 7 Jun 2004, Boris wrote:

A session ties various stateless HTTP requests by sharing some data across
these requests.
Right (though I'm not sure what this is doing in a specifically "HTML"
authoring group).
This is done preferably on the server side
Eh? HTTP itself is stateless: maintainence of state *has* to be a
co-operative process in which the "sharing" takes place between
both sides of the conversation. I.e passing some kind of unique token
to and fro between server and client.
using session variables in PHP, ASP or whatever.
I agree with the "or whatever". Although the implementation details
may vary, they are all based in the same underlying principles.

By the way, don't confuse this kind of thing with the "basic
authentication" mechanism of HTTP. Basic authentication doesn't
involve maintenance of state: the browser gets to learn, via the
exchange of 401 status, which basic credentials are appropriate for
accessing different parts of a site, and will then continue to supply
them auomatically, without any exchange of status information with the
server. Normally, that's done with credentials which remain stable
for long periods, and there's no particular defined mechanism for the
server to tell the client that it should forget a particular set of
credentials: that's something between the user and their browser.

This mechanism can be adapted by having the server report that the
credentials are no longer valid. But it's not a particularly robust
way of managing time-limited sessions, IMHO.
These session variables are saved somewhere, eg. in a file. When
someone logs out the store with the session variables simply has to
be deleted. How this is done depends on the technology used.
Therefore it might be better to ask in a PHP, ASP or whatever group.

Agreed; but the underlying principles (of passing a token to and fro
between client and server) are the same no matter how they're
implemented in detail on the server side.

[Boris]

Alan J. Flavell wrote:

On Mon, 7 Jun 2004, Boris wrote:

A session ties various stateless HTTP requests by sharing some data
across these requests.
Right (though I'm not sure what this is doing in a specifically "HTML"
authoring group).

This is done preferably on the server side

Eh? HTTP itself is stateless: maintainence of state *has* to be a
co-operative process in which the "sharing" takes place between
both sides of the conversation. I.e passing some kind of unique token
to and fro between server and client.

Yes. I only stressed server side as the OP said something with "password is
removed from their cache" (which sounded to me like a store on users'
machines).

Boris
[...]

[Alan J. Flavell]

On Mon, 7 Jun 2004, Boris wrote:

Alan J. Flavell wrote:

On Mon, 7 Jun 2004, Boris wrote:

This is done preferably on the server side

Eh? HTTP itself is stateless: maintainence of state *has* to be a
co-operative process in which the "sharing" takes place between
both sides of the conversation. I.e passing some kind of unique token
to and fro between server and client.

Yes. I only stressed server side as the OP said something with "password is
removed from their cache" (which sounded to me like a store on users'
machines).

I see, thanks! If I misinterpreted what you were saying, then
please accept my apology.