You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Rich Bowen <rb...@rcbowen.com> on 2002/12/11 22:45:54 UTC
Docs correction? re Auth
The following is a conversation that I've been having with someone about
the authentication tutorial. To summarize, he says that the thing about
it being impossible to log out, is nonsense. He claims that the
following method works.
You create a link to <bogus:bogus@hostname.com/logout.html> or somesuch,
and that this effectively resets the password cache on the browser.
I guess I'm not entirely sure what he means, as I'm unable to reproduce
his findings. Anyone got any thoughts on this?
--
Rich Bowen - rbowen@rcbowen.com
As we trace our own few circles around the sun
We get it backwards and our seven years go by like one
Dog Years (Rush - Test for Echo - 1999)
---------- Forwarded message ----------
Date: Tue, 10 Dec 2002 17:13:40 -0600
From: Ron Rockwell <ro...@rrockwell.com>
To: Rich Bowen <rb...@rcbowen.com>
Subject: Re: simply incorrect information in docs
Rich,
I have never gotten the intermediate pop-window because the 403 is not
served
from the server in this example.... the crucial piece there is that the URL
that you
send them to with the false username:password is NOT protected by any
security,
its just an open page. In the HTTP conversation, the client asks for the
page and
authenticates itself, but the server ignores the extraneous information and
returns
a 200 response. I have tested this with all browsers, but not all servers
or versions
of servers... that remains to be seen....
Up to you about documenting it, but the way it is documented now leaves
the reader
with little hope that a solution can be found... in fact... that NO hope
exists, that the
experts have all tried all of the various things.. etc. etc. Documentation
has that
power of "all the experts" behind it. So, maybe you should put it down as a
work-around,
so that people have some hope... just my 2 cents..
Happy frags,
Ron Rockwell
ron@rrockwell.com
----- Original Message -----
From: "Rich Bowen" <rb...@rcbowen.com>
To: "Ron Rockwell" <ro...@rrockwell.com>
Sent: Tuesday, December 10, 2002 5:34 AM
Subject: Re: simply incorrect information in docs
> On Mon, 9 Dec 2002, Ron Rockwell wrote:
>
> > What I use instead is a false username:password pair to a known address
> > within the domain which does not have security placed on the url.
>
> When I have used this technique in the past, the result is that the
> server resends the 403 unauthorized header, and you get another password
> dialog, since the username:password pair were invalid. So, yes, you have
> invalidated the previous login, but you must now press cancel on a
> password dialog. This always struck me as a non-solution, since you end
> up getting this confusing intermediate dialog box. However, I'll
> experiment some more with it, and mention it in the doc if you like.
>
Re: Docs correction? re Auth
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Rich Bowen wrote:
>
> You create a link to <bogus:bogus@hostname.com/logout.html> or somesuch,
> and that this effectively resets the password cache on the browser.
clever. however, it has some drawbacks:
1. it can't be just any uri on the site; it needs to be one within
the realm where the credentials are valid.
2. if the above uri is in a 'require' area, the poor user is going
to get an 'authentication failed' popup.
3. if the uri is in an area within the realm but not requiring
valid credentials (e.g., allow from all/satisfy any).. h'm.
that might be browser specific. it may replace the validated
credentials with the bogus ones, or it may not. in the former
case, the results will be as desired.
*very* interesting..
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: Docs correction? re Auth
Posted by Rich Bowen <rb...@rcbowen.com>.
On Fri, 13 Dec 2002, Joshua Slive wrote:
>
> On Thu, 12 Dec 2002, Andr� Malo wrote:
> > The next point is: browsers are not the only possible HTTP-Clients. If you
> > think about, say DAV clients, the "logout" will become more undefined than
> > ever. Especially if they are compliant to the particular RFCs.
>
> I think the important point is that password caching is really completely
> up to the browsers. There are certain things that the RFCs tell them that
> they should or should not cache, but absolutely nothing that I know of
> that tells them they need to empty their cache. So in other words, it
> would be completely appropriate for the browser to try these bogus
> credentials, realize that they don't work, and fall-back to the old ones.
>
> Then as far as the docs, if it really can be shown that there is some
> technique that works for a wide variety of browsers, I have no problem
> with documenting it. But it must be noted that it is browser-dependent,
> not universal.
I've been completely unable to reproduce his technique, with any browser
I have access to. I suppose I could be doing it wrong, but I think I
followed his recipe, and tried to remain open-minded. It did not in fact
un-auth me. So I'm not leaning towards doing this until and unless he
sends me directions that work.
--
Rich Bowen - rbowen@rcbowen.com
As we trace our own few circles around the sun
We get it backwards and our seven years go by like one
Dog Years (Rush - Test for Echo - 1999)
Re: Docs correction? re Auth
Posted by Joshua Slive <jo...@slive.ca>.
On Thu, 12 Dec 2002, André Malo wrote:
> The next point is: browsers are not the only possible HTTP-Clients. If you
> think about, say DAV clients, the "logout" will become more undefined than
> ever. Especially if they are compliant to the particular RFCs.
I think the important point is that password caching is really completely
up to the browsers. There are certain things that the RFCs tell them that
they should or should not cache, but absolutely nothing that I know of
that tells them they need to empty their cache. So in other words, it
would be completely appropriate for the browser to try these bogus
credentials, realize that they don't work, and fall-back to the old ones.
Then as far as the docs, if it really can be shown that there is some
technique that works for a wide variety of browsers, I have no problem
with documenting it. But it must be noted that it is browser-dependent,
not universal.
Joshua.
Re: Docs correction? re Auth
Posted by André Malo <nd...@perlig.de>.
* Rodent of Unusual Size wrote:
> André Malo wrote:
>>
>> The problem is: Such an URL is illegal. It's explicitely
>> forbidden by RFC 1738 and RFC 2616.
>
> rfc 1738 section 3.1 defines this as a valid syntax. section
valid *generic* syntax, which will be restricted later, yes.
> 3.3 says it's not permitted in http: uris -- which is fine,
> since it is never(1) sent to the server.
That's not the point of failure. If I have a user interface, that allows
such "extended URLs" to be typed in and converts them to HTTP headers -
fine.
But <a href="..."> is defined to contain a valid URI (reference). In case
of the http scheme, it may not contain any credentials. Otherwise the
behaviour is simply undefined.
> the client always(1)
> decomposes it into a valid http: uri and an authorization:
> request header field. therefore, modulo my previous message,
> this trick should(1) work for all semi-reasonable clients.
>
> (1) i know of *no* clients that do not handle this as described,
> but it's possible there are some. they would hardly be mainstream,
> in any case, and almost certainly batch clients rather than
> user-interfacine browsers.
as said before: I've tried this (some time ago, a year or so).
I configured a proxy in the browser(s) and in my tests the MSIE was the
*only* client, which spreads the credentials around the world (401 or not)
as headers.
Tested also: NN4, Lynx, Opera 5, wget and some others (win32). All of them
sent the wrong uri to the proxy server (could see this in the proxy logs).
The next point is: browsers are not the only possible HTTP-Clients. If you
think about, say DAV clients, the "logout" will become more undefined than
ever. Especially if they are compliant to the particular RFCs.
nd
--
Wenn nur Ingenieure mit Diplom programmieren würden, hätten wir
wahrscheinlich weniger schlechte Software.
Wir hätten allerdings auch weniger gute Software.
-- Felix von Leitner in dasr
Re: Docs correction? re Auth
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
André Malo wrote:
>
> The problem is: Such an URL is illegal. It's explicitely
> forbidden by RFC 1738 and RFC 2616.
rfc 1738 section 3.1 defines this as a valid syntax. section
3.3 says it's not permitted in http: uris -- which is fine,
since it is never(1) sent to the server. the client always(1)
decomposes it into a valid http: uri and an authorization:
request header field. therefore, modulo my previous message,
this trick should(1) work for all semi-reasonable clients.
(1) i know of *no* clients that do not handle this as described,
but it's possible there are some. they would hardly be mainstream,
in any case, and almost certainly batch clients rather than
user-interfacine browsers.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: Docs correction? re Auth
Posted by André Malo <nd...@perlig.de>.
* Rich Bowen wrote:
> The following is a conversation that I've been having with someone about
> the authentication tutorial. To summarize, he says that the thing about
> it being impossible to log out, is nonsense. He claims that the
> following method works.
>
> You create a link to <bogus:bogus@hostname.com/logout.html> or somesuch,
> and that this effectively resets the password cache on the browser.
>
> I guess I'm not entirely sure what he means, as I'm unable to reproduce
> his findings. Anyone got any thoughts on this?
He means: let the browser send wrong credentials, so that the server will
respond a 401. Many (most?) browsers will forget the password for the
current realm then.
That's true.
The problem is: Such an URL is illegal. It's explicitely forbidden by RFC
1738 and RFC 2616. As a result of this, the trick may or may not work.
Most browsers convert such URLs into the appropriate HTTP headers, but not
all and not every time. For example, Netscape Navigator 4 sends the
original URL without converting if there's a proxy configured (in the
browser).
(Actually I had a proxy for a while that could not recognize such URLs and
therefore such requests never reached the server...)
Alternatively one could the server let respond a 401 itself, for instance
using a CGI script or a special prepared URL. But the same problem appears:
The client has to forget the credentials and that's not in the server's
sphere of influence.
nd
--
print "Just Another Perl Hacker";
# André Malo, <http://www.perlig.de/> #
Re: Docs correction? re Auth
Posted by André Malo <nd...@perlig.de>.
* Rich Bowen wrote:
> However, typing that URL into the URL bar (or highlighting the URL bar,
> and then pressing enter) will cause the browser to auth as user
> "no-auth" for that resource, which effectively logs the user out of the
> other area. Sort of. So it seems that these browsers, at least, ignore
> username/password information contained in a link, but trust it if they
> think that you have typed it into the URL line.
>
> I'm not planning to spend any more time on this, but I thought you might
> be interested in what I had discovered.
yes, thank you Rich. I find it very interesting - and one more point to say
"the behaviour is undefined" ;-)
nd
--
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~ # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord( # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see; # http://www.perlig.de/ ;
Re: Docs correction? re Auth
Posted by Rich Bowen <rb...@rcbowen.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 11 Dec 2002, Rich Bowen wrote:
> The following is a conversation that I've been having with someone about
> the authentication tutorial. To summarize, he says that the thing about
> it being impossible to log out, is nonsense. He claims that the
> following method works.
>
> You create a link to <bogus:bogus@hostname.com/logout.html> or somesuch,
> and that this effectively resets the password cache on the browser.
>
> I guess I'm not entirely sure what he means, as I'm unable to reproduce
> his findings. Anyone got any thoughts on this?
Got thinking about this this morning, and tried the following, which
almost works:
<Directory /www/docs/private>
AuthType Basic
AuthName "Go Away"
AuthUserFile /www/passwd/passwords
Require user rbowen
</Directory>
<Directory /www/docs>
<Files logout.html>
AuthType Basic
AuthName "Go Away"
AuthUserFile /www/passwd/passwords
Require user no-auth
<Files>
</Directory>
/www/passwd/passwords contains a user "no-auth" with password "none".
Here's the strange part. Clicking a link to
http://no-auth:none@hostname/logout.html will, on Mozilla (1.1a) and
Netscape (4.72), cause the browser to make a request using the cached
information for the auth'ed user rbowen:
[Sun Dec 22 09:01:42 2002] [error] [client 127.0.0.1] access to
/logout.html failed, reason: user rbowen not allowed access
However, typing that URL into the URL bar (or highlighting the URL bar,
and then pressing enter) will cause the browser to auth as user
"no-auth" for that resource, which effectively logs the user out of the
other area. Sort of. So it seems that these browsers, at least, ignore
username/password information contained in a link, but trust it if they
think that you have typed it into the URL line.
I'm not planning to spend any more time on this, but I thought you might
be interested in what I had discovered.
Rich
- --
Oh I have slipped the surly bonds of earth
And danced the sky on laughter-silvered wings
--High Flight (John Gillespie Magee)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.75-6
iD8DBQE+Bcc1XP03+sx4yJMRAiaUAKDpAclKBfh/fjd1tIdcLGx62HYhoACgynKu
EOTaGlAVS0BDp7Ig9Ze1NsU=
=ZaKY
-----END PGP SIGNATURE-----