Nicolas Alvarez wrote:
> With cookie-based login, the "something" to expire is the session ID 
> kept in the cookie. Even if the client doesn't expire the cookie, the 
> server wouldn't accept the session ID anymore once it expires.

No. If the only thing you're expiring is the cookie, then there's no 
point in having the cookie. The cookie is there to track some state on 
the server and associate it with the user's session. The cookie by 
itself isn't useful. It's the cookie's association with the row in the 
database representing the shopping cart or whatever that's useful.

> With HTTP auth, the "something" that the client sends is the user 
> credentials. Should I expire the user's password?

The cookie is there to identify the user. The auth is there to identify 
the user. What exactly is it you do at the server when the "cookie 
expires". You don't "log out" the user, because the user isn't "logged 
in" at that level of abstraction. You're changing some system state, 
which you have to do when "the cookie expires" regardless of what the 
browser does.

Put it this way: You give me a cookie that's set to expire in an hour. 
If I come back in 3 hours with the same cookie (because my browser 
didn't expire it), are you going to let me in with exactly the same 
state? If so, why are you expiring my cookie?  If not, why is the cookie 
better than auth?  If it's really important my cookie expires, you need 
to enforce that at your end.

So what action do you take when someone says "log out" other than 
deleting the cookie, and why do you care? Why not just have a "log out" 
button that cleans up the server side, and from then on return a 403 if 
they go anywhere other than the "log in" link from the home page? :-)

It's really not that hard if you think about it a while. It's just 
easier to pretend HTTP is stateful. And of course the marketing people 
don't like it, because it doesn't work like everyone else's web site, 
all of which work differently.

(Of course, you don't get to do CAPTHCAH either.)

> Anyway, just Google "http auth logout" [1] and see how many people 
> complain about it. *Sometimes* even people who know what they're talking 
> about :)

Oh, I'm not saying it's never appropriate. It's just used almost never, 
and it has definite advantages.

Just looking at the first link, 
http://www.artima.com/weblogs/viewpost.jsp?thread=155252

He lists "username prompt can't be customized". Sure, but that can also 
be a good thing. It's a UI standard. :-)

Numbers 2, 3, 4 are all bogus. "No way to do optional authentication", 
for example, is baloney. Don't return a 401, you don't need to 
authenticate.  5, "difficult single sign-on", is true, but just as bad 
for forms-based sign-ons, because you have to use SSL for that, and 
hence you need to either spend big bucks on a wildcard cert or suck up a 
whole bunch of public IP addresses because you don't like built-in 
authentication. :-)

Basically, the problem is "http auth is lame, because browsers implement 
it in a lame way, so we're not going to use it, so browser authors won't 
bother to de-lame it."  Which makes sense, given HTTP isn't really 
designed to be used for stateful applications anyway. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message