|
|
> 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 cookie-based login, the "something" to expire is the session data
stored in the server and identified by the session ID stored in the
cookie. Even if the client doesn't expire the cookie, the server
wouldn't accept the session ID anymore once the session expires.
Better like that?
> 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. :-)
I would use it. I'm just arguing it's not "perfectly good", like you
said in your first post.
Post a reply to this message
|
|