- From: Charles Iliya Krempeaux <supercanadian@gmail.com>
- Date: Mon, 13 Jun 2005 22:13:16 -0700
Hello,
On 6/13/05, S. Mike Dierken <mdierken at hotmail.com> wrote:
> A couple notes
> - HTTP doesn't have sessions, that's a fiction that server authors created
> to optimize resources by holding onto & later releasing those resources. It
> useful to talk about in regards to the application logic, but it's not part
> of HTTP.
Sorry. You are quite correct. I've been sloppy with my language.
(Hopefully I'll get it correct this time :-) )
What I was talking about was HTTP Authentication.
> - different applications have different concepts of being logged in. Some
> may allow a user to login under different 'roles', some may allow them to
> login to different areas of the site, etc. Any UI element embedded in the
> browser chrome wouldn't work for many apps - it really should be flexible
> enough for a page to have custom UI.
Agreed.
> - if the browser had a button or variant of an html form that cleared the
> user's credentials (username/password, certificate, etc) then that action
> would not be reported to the server.
Which is generally how most sites have it today when people just close
the browser window (without logging out.) (Although it is probably
not best practice.)
Typically I make sessions die if they aren't "touched" for a certain
period of time. (And web pages have a piece of JavaScript that
"touches" the server, so that the session stays alive if the browser
window is left open, but the user hasn't done anything that causes
requires a "hit" to the server.)
> Would this fit the use case that server
> developers have? My guess is that they would like to know when a user 'logs
> out'. Which means that the browser sends a message to the server. This
> message likely should be required to come from an authenticated user... else
> the bad guys could log people out by guessing the right message. If the
> client request is followed by a server response that clears out the
> credentials, I think that lets developers have various concepts of 'logged
> in' and 'logged out', implement it however they wish in both UI and server
> code, and integrates with the protocol at some level.
So you want some standard "hand shake" for logging off. I.e.,
#1: The client sends a "log me out" message to the server.
#2: The server receives the "log me out" message and "cleans up".
#3: The server sends a "you are logged out" message to the client.
#4: The client clears the "HTTP Authenication" data.
Is that something along the lines of what you are suggesting?
As far as I know, there isn't any standard for this. (I believe RFC
2617 defines the HTTP Authentication stuff. And there wasn't anything
in there like this that I saw. Nor am I aware of any other standard
for it.)
Maybe we need a standard for this.
See ya
--
Charles Iliya Krempeaux, B.Sc.
charles @ reptile.ca
supercanadian @ gmail.com
developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
Ask the toughest Linux System questions at... http://linuxmanagers.org/
Received on Monday, 13 June 2005 22:13:16 UTC