🚀 go-pugleaf

Malcolm Hoar <malch@malch.com> wrote in message news:364a3765$0
>BTW, cookies appear to be very broken on some installations of
>Netscape Communicator 4.5ish, as I have learned to my cost.

I wish we could just throw that turkey back wherever it came from. I didn't
think Netscape could make me love Microsoft, but 4.5 seems to have done it.

Ed.

On 11 Nov 1998 16:52:43 -0800, yossie@best.com wrote:
>How does one 'un-authorize' a browser.  In other words, how do you implement a
>cgi 'logout' button for a "basic" authorization page?  Once the browser has
>learned the user/password for a given realm, it seems to remember it till you
>quit the browser.  Can I (from a cgi) make it forget?   Thanks - Yossie

Well, in theory, you could send it to a place in the same domain, that had a
different set of passwords. Or rather, explicitly had everyone set to null.
This should trigger the browser with a "retry auth" popup or something. At
which point, they can then enter a null password, and you will have reset it.

But I don't think there's a way for a normal cgi to tell the browser
"Hey, forget all your passwords now", without user interaction.



-- 
[trim the no-bots from my address to reply to me by email!]
 --------------------------------------------------
"initiating.. 'getting the hell out of here' maneouver" - Lennier, babylon5

In article <72dbgr$gqq$1@shell8.ba.best.com>, yossie@best.com (Joseph Silverman) wrote:
>How does one 'un-authorize' a browser.  In other words, how do you implement a
>cgi 'logout' button for a "basic" authorization page?  Once the browser has
>learned the user/password for a given realm, it seems to remember it till you
>quit the browser.  Can I (from a cgi) make it forget?   Thanks - Yossie

No easy way as far as I know. You'd have to either:

* Remove the users entry from your password file or change it, or

* Implement a second level of security using some other technique
  based on IP address, a cookie or whatever.

BTW, cookies appear to be very broken on some installations of
Netscape Communicator 4.5ish, as I have learned to my cost.

-- 
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar           "The more I practice, the luckier I get". |
| malch@malch.com                                     Gary Player. |
| http://www.malch.com/               Shpx gur PQN.                |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In article <slrn74kdl8.8j4.phil.s2@shell3.ba.best.com>, phil.s2@bolthole.no-bots.com wrote:

>Well, in theory, you could send it to a place in the same domain, that had a
>different set of passwords. Or rather, explicitly had everyone set to null.
>This should trigger the browser with a "retry auth" popup or something. At
>which point, they can then enter a null password, and you will have reset it.

You'd have to move from Realm1 to Realm2 to force a new prompt. But,
the Realm1 password would still be cached in the browser - at least
that how most browsers appear to implement HTTP authentication.

Authentication applies to "Realm" within a "server" and browsers
will normally cache "n" of them where "n" is not a trivially
small number.

>But I don't think there's a way for a normal cgi to tell the browser
>"Hey, forget all your passwords now", without user interaction.

I don't think you can even do it _with_ user interaction (short of
exiting the browser).

-- 
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar           "The more I practice, the luckier I get". |
| malch@malch.com                                     Gary Player. |
| http://www.malch.com/               Shpx gur PQN.                |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Thu, 12 Nov 1998 01:34:20 GMT, malch@malch.com wrote:
>In article <slrn74kdl8.8j4.phil.s2@shell3.ba.best.com>, phil.s2@bolthole.no-bots.com wrote:
>
>>Well, in theory, you could send it to a place in the same domain, that had a
>>different set of passwords. Or rather, explicitly had everyone set to null.
>>This should trigger the browser with a "retry auth" popup or something. At
>>which point, they can then enter a null password, and you will have reset it.
>
>You'd have to move from Realm1 to Realm2 to force a new prompt. But,
>the Realm1 password would still be cached in the browser - at least
>that how most browsers appear to implement HTTP authentication.
>
>Authentication applies to "Realm" within a "server" and browsers
>will normally cache "n" of them where "n" is not a trivially
>small number.


???
What the heck are we talking about here? last I heard, browsers do
authentication on a server-by-server basis. Or at least netscape seems to.

SO, 
 have ~/public_html/dir1 have bhaccess set with password file set to
     ~/public_html/dir1/password


 have ~/public_html/dir2 have bhaccess set with password file set to
     ~/public_html/dir2/password


Normally a user would go through the dir1 tree. but when time to "log out",
throw them a link in to /dir2/logout.
This should then make bestwwwd access the dir2/password file.
But you'll still be in the same "WWWDirect" domain, aka www.yourdomain.com

Which should cause the browser to retry authentication.

Which should cause overwriting of the existing value.


Tell me why that wouldn't work.


-- 
[trim the no-bots from my address to reply to me by email!]
 --------------------------------------------------
"initiating.. 'getting the hell out of here' maneouver" - Lennier, babylon5

In article <slrn74kf5q.8j4.phil.s2@shell3.ba.best.com>, phil.s2@bolthole.no-bots.com wrote:

>>Authentication applies to "Realm" within a "server" and browsers
>>will normally cache "n" of them where "n" is not a trivially
>>small number.
>???
>What the heck are we talking about here?

Chapter 11 of RFC 2068.

I don't just make this stuff up :-)

If you can find a kludge that works, it's an artifact of some
specific server and/or browser implementation, IMO. "Realm and
Server" is how the HTTP spec. defines it.

-- 
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar           "The more I practice, the luckier I get". |
| malch@malch.com                                     Gary Player. |
| http://www.malch.com/               Shpx gur PQN.                |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In article <364a54bb$0$12767@nntp1.ba.best.com>, "Ed Gauci" <gauci@good-things.org> wrote:

>>BTW, cookies appear to be very broken on some installations of
>>Netscape Communicator 4.5ish, as I have learned to my cost.
>
>I wish we could just throw that turkey back wherever it came from.

Hey - that's Mountain View - several thousand miles too close ;-)

-- 
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar           "The more I practice, the luckier I get". |
| malch@malch.com                                     Gary Player. |
| http://www.malch.com/               Shpx gur PQN.                |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In article <slrn74kf5q.8j4.phil.s2@shell3.ba.best.com>,
  phil.s2@bolthole.no-bots.com wrote:
> On Thu, 12 Nov 1998 01:34:20 GMT, malch@malch.com wrote:
> >In article <slrn74kdl8.8j4.phil.s2@shell3.ba.best.com>,
phil.s2@bolthole.no-bots.com wrote:
> >
> >>Well, in theory, you could send it to a place in the same domain, that had a
> >>different set of passwords. Or rather, explicitly had everyone set to null.
> >>This should trigger the browser with a "retry auth" popup or something. At
> >>which point, they can then enter a null password, and you will have reset
it.
> >
> >You'd have to move from Realm1 to Realm2 to force a new prompt. But,
> >the Realm1 password would still be cached in the browser - at least
> >that how most browsers appear to implement HTTP authentication.
> >
> >Authentication applies to "Realm" within a "server" and browsers
> >will normally cache "n" of them where "n" is not a trivially
> >small number.
>
> ???
> What the heck are we talking about here? last I heard, browsers do

I don't think Malcom understands what Philip is proposing.  Philip's solution
should work, but I don't want the browser to be *prompted* again immediately
(and I'm sure Joseph doesn't either) just to accomplish the task.

I just want the browser to null out it's auth entry so that if they come back
to the protected areas, they are prompted at *that* time.

Any ideas about that, Joseph??

Respond via e-mail, please...

TTFN,

j
jay_hannah@viatel.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

In article <72pa6q$ce5$1@nnrp1.dejanews.com>, hannj@my-dejanews.com wrote:

>I don't think Malcom understands what Philip is proposing.

Yes, he does ;-)

>I just want the browser to null out it's auth entry so that if they come back
>to the protected areas, they are prompted at *that* time.

The HTTP protocol simply does not provide a mechansim for the
server to tell the client to invalidate the Authentication
info. Even if it did, you couldn't be sure the client had
acted accordingly. Which brings us back to my original
solutions:

1. Remove or modify the users entry in the .htpasswd (or
   whatever) file. And/or:

2. Replace or supplement HTTP Authentication with some other
   security scheme.

Even solution 1 won't take effect immediately on some servers
(including Best's I believe) because those control files are
cached. AFAIK, it will take 1-2 minutes for the changes to be
effective with Best's httpd.

-- 
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar           "The more I practice, the luckier I get". |
| malch@malch.com                                     Gary Player. |
| http://www.malch.com/               Shpx gur PQN.                |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In article <365035c8$0$12782@nntp1.ba.best.com>,
Malcolm Hoar <malch@malch.com> wrote:
>In article <72pa6q$ce5$1@nnrp1.dejanews.com>, hannj@my-dejanews.com wrote:
>>I just want the browser to null out it's auth entry so that if they come back
>>to the protected areas, they are prompted at *that* time.
>
>The HTTP protocol simply does not provide a mechansim for the
>server to tell the client to invalidate the Authentication
>info. Even if it did, you couldn't be sure the client had
>acted accordingly.

Related to this is another problem:

  You're in a co-worker's cubicle, helping the user with a problem, and you
  need to look at a password-protected web page to get the answer.  They have
  a web browser already running, so you go to the protected web page, enter
  your username and password, get the info.  Satisfied, you walk away.

  The browser still has your password memorized.

  The only way to be sure that your password won't continue to be used is
  to tell the browser to exit completely.

	-Joe
-- 
INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran and our cats
See http://www.inwap.com/ for PDP-10, "ReBoot", "Shadow Raiders"/"War Planets"

In article <73583k$pgs$1@shell3.ba.best.com>, inwap@best.com (Smith and O'Halloran) wrote:

>  You're in a co-worker's cubicle, helping the user with a problem, and you
>  need to look at a password-protected web page to get the answer.  They have
>  a web browser already running, so you go to the protected web page, enter
>  your username and password, get the info.  Satisfied, you walk away.

Or, for example, when visiting a customer site ....

>  The browser still has your password memorized.
>
>  The only way to be sure that your password won't continue to be used is
>  to tell the browser to exit completely.

Yes, exit *all* instances of the browser! In most setups, multiple 
instances of the same browser will share the Authentication info.

-- 
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar           "The more I practice, the luckier I get". |
| malch@malch.com                                     Gary Player. |
| http://www.malch.com/               Shpx gur PQN.                |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In article <3656a9a9$0$12773@nntp1.ba.best.com>,
Malcolm Hoar <malch@malch.com> wrote:
>Yes, exit *all* instances of the browser! In most setups, multiple 
>instances of the same browser will share the Authentication info.

MSIE saves passwords... does it selectively save them, or would you
have to get rid of any passwords your customer may have accumulated?

In article <7370c3$82$1@machaut.medieval.org>, mccomb@medieval.org (Todd Michel McComb) wrote:

>MSIE saves passwords... does it selectively save them, or would you
>have to get rid of any passwords your customer may have accumulated?

Oh sheesh. It probably puts 'em all over the place - it does with
everything else. If I am ever forced to use MSIE on someone elses
machine, I'll just change my damn password. Thanks for the heads up.

-- 
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar           "The more I practice, the luckier I get". |
| malch@malch.com                                     Gary Player. |
| http://www.malch.com/               Shpx gur PQN.                |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~