|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
>> How do I delete that password within the session, without restarting
>> the browser?
>
> "According to RFC 2616, existing browsers retain authentication
> information indefinitely.
Note that "indefinitely" does not mean "forever". It means you can't
control how long they save it.
Just like you can't control how long the browser caches user name /
password information for a forms-based login.
> This is a
> significant defect that requires further extensions to HTTP." --Wikipedia
Without someone explaining why it's a defect, I'm not sure this is so clear.
> "Both Netscape Navigator and Internet Explorer will clear the local
> browser window's authentication cache for the realm upon receiving a
> server response of 401.
Right. That's basically exactly how you're *supposed* to do it. "The
password you provided to get to this page is invalid. Please reenter it.
> BTW: I think most people use forms for login just because everybody else
> is doing it, not because they gave it any thought :)
Exactly my point, yes.
Plus, it adds the overhead of requiring SSL (which sucks up both compute
cycles and IP addresses) just so you can accept the password without
sending it in the clear, unlike HTTP AUTH.
But of course, again the whole argument that cookies are better than
AUTH is based on the flawed premise that you should be having "logins"
in protocols running over a stateless protocol like HTTP in the first place.
--
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
|
|
| |
| |
|
|
From: Nicolas Alvarez
Subject: Re: As if we didn't have enough to worry about...
Date: 4 Apr 2008 19:56:23
Message: <47f6ce37@news.povray.org>
|
|
|
| |
| |
|
|
> Nicolas Alvarez wrote:
>> Session usually expires server-side at the same time as the
>> client-side cookie. There are no sessions with HTTP auth, nothing you
>> can expire.
>
> Of course there is. You're just not thinking. The server knows how long
> it has been since last you came back. After that time elapses, clean up
> whatever you'd clean up if the user hit the "logout" button.
>
> In other words, no, cookies do not "expire" on the server side, since
> the server doesn't have a cookie. A cookie is a way for the server to
> store something at the browser. The "something" is what expires. Hence,
> go ahead, expire that "something".
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.
With HTTP auth, the "something" that the client sends is the user
credentials. Should I expire the user's password?
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 :)
[1] or "http (auth|authentication) (logout|log out)" so that you don't
miss anything.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Nicolas Alvarez
Subject: Re: As if we didn't have enough to worry about...
Date: 4 Apr 2008 21:21:58
Message: <47f6e246$1@news.povray.org>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> 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.
Exactly. Hence, there's no real need for the cookie to do anything in
order to "log out" or "expire the session" of the user, am I right? If
the user comes back to a deep page with a valid login, bounce them to
the top-level page that says "Your session has expired, please start over."
Then there's sites like (say) Facebook, where you're contractually
obligated to have only one login, so having a "logout" button makes no
sense to start with. :-)
> I would use it. I'm just arguing it's not "perfectly good", like you
> said in your first post.
That's fair enough, yes. In part because the browsers don't support it.
It's perfectly good for the process of logging someone in. What's not
perfectly good is lame browser support. :-)
--
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
|
|
| |
| |
|
|
From: Chambers
Subject: Re: As if we didn't have enough to worry about...
Date: 5 Apr 2008 00:05:23
Message: <47f70893@news.povray.org>
|
|
|
| |
| |
|
|
Darren New wrote:
> Then there's sites like (say) Facebook, where you're contractually
> obligated to have only one login, so having a "logout" button makes no
> sense to start with. :-)
What about multiple persons using the same computer?
--
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
From: Darren New
Subject: Re: As if we didn't have enough to worry about...
Date: 5 Apr 2008 00:19:42
Message: <47f70bee@news.povray.org>
|
|
|
| |
| |
|
|
Chambers wrote:
> Darren New wrote:
>> Then there's sites like (say) Facebook, where you're contractually
>> obligated to have only one login, so having a "logout" button makes no
>> sense to start with. :-)
>
> What about multiple persons using the same computer?
Then you should be closing the browser and logging into the other
person's account, yes? :-)
(Yeah, OK, this has gotten a bit silly even for me. It's just a pet
peeve of mine that people use HTTP for all kinds of wrong stuff where
they'd be far, far better off with an actual statefull
connection-oriented protocol without quite so much hackery in it. The
fact that I'm now expected to do all the hackery myself is rather what
ticks me off, methinks.)
--
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
|
|
| |
| |
|
|
From: Gail Shaw
Subject: Re: As if we didn't have enough to worry about...
Date: 5 Apr 2008 03:15:20
Message: <47f73518@news.povray.org>
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:47f6c63b@news.povray.org...
>
> I said in my original post "travelling at almost c towards us".
> Pretty hard to notice.
>
Depends how close to c, and how long it's been travelling towards us. Long
enough and the red-shifted light and gravitational lensing (maybe) might
show its presence
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And lo on Thu, 03 Apr 2008 14:37:41 +0100, Gail Shaw sa dot com>
<"<initialsurname"@sentech> did spake, saying:
>
> "Phil Cook" <phi### [at] nospamrocainfreeservecouk> wrote in message
> news:op.t8083otuc3xi7v@news.povray.org...
>
>> So let me get this straight *Mr* Wagner, who studied physics, and Mr
>> Sancho, an author, are attempting to get an injunction in Hawaii
>> against a
>> European Science Group, of which they United States is not a part, fr
om
>> operating in Switzerland because they've failed to carry out an
>> environmental impact statement as required under a Act that doesn't
>> apply to them.
> For some extra fun, find the New Scientist article that reports on thi
s.
> The
> article's sane, the comments get progressively more ridiculous.
Perusing it now; heh.
> Why do these people seem to think they know more about subatomic physi
cs
> than the professional scientists do?
Because for some reason 'people' are being taught that their unqualifed
reasoning is equal to that of qualified reasoning; that their opinion
matters on every subject regardless of their knowledge (or lack thereof)
of it.
> Oh wait, I forgot. Science = Evil. Geeks are losers. Geniuses are al
ways
> trying to take over or destroy the world. Right. Now I got it.
Hell yeah, I'm betting all the negative comments are from Jocks (not you
Stephen) who used to shut up Geeks in their lockers and are now petrifie
d
that they're going to be zapped with Ray-Guns.
> Down with Progress! Back to the Stone Age!
Oh I don't know have you conducted a full H&S assessment on the results
of
banging two stones together? It could create a spark that sets the entir
e
atmosphere aflame; think we'd better return to the Mud Age instead.
--
Phil Cook
--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com
Post a reply to this message
|
|
| |
| |
|
|
From: Bill Pragnell
Subject: Re: As if we didn't have enough to worry about...
Date: 7 Apr 2008 07:20:46
Message: <47fa038e$1@news.povray.org>
|
|
|
| |
| |
|
|
Gail Shaw wrote:
> "Warp" <war### [at] tagpovrayorg> wrote in message
> news:47f6c63b@news.povray.org...
>> I said in my original post "travelling at almost c towards us".
>> Pretty hard to notice.
>>
> Depends how close to c, and how long it's been travelling towards us. Long
> enough and the red-shifted light and gravitational lensing (maybe) might
> show its presence
And if it were stellar-massed it'd move stars close to its trajectory,
whose light would reach us slightly beforehand. Although there's not a
lot we could do about it in either case...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|