Apache and Safari strange Digest Behavior
am 11.04.2008 02:29:30 von joeyHi,
Setup:
- Apache 2.2.4 on Windows 2000
- Safari 3.1 for Windows XP
I'm new to Apache so I am still learning.
I prepared it so use AuthType Digest using the example provided in the
docs but for entire site, not just a private folder:
AuthType Digest
AuthName "SSI Research"
AuthDigestDomain /
AuthDigestProvider file
AuthUserFile /auth/.digest_pw
Require valid-user
Under Firefox 2.0, Internet Explorer 6.0 it is working as expected.
Under Safari 3.1 for Windows, it APPEARS to work until you look at the
access.log logs and what I am seeing after the login is a DOUBLE REQUEST
for each private resource.
In other words, when a private request is made, Safari will first send
it as an unauthorized request by not sending the Authorization header.
Apache sees this and issues a 401 with a new WWW-Authenticate: response
header and Safari will resent the quest with the authorization header.
So appearance way, it all looks ok, except for this double request behavior.
Is this normal DIGEST behavior? I don't think so.
Its a problem when you are in a public page which you might initiate the
login but requesting a private resource which would direct to the
private home page.
However under Safari, it sees the redirection and makes the request in
non-authorized mode, which the web server sees and redisplays the PUBLIC
home page instead again.
For example, using a C: client/user, S: server notation:
1 C: http://domain.com << user visits site
2 S: server requires authentication and redirects to:
/public/default.htm with there is a login "/LOGIN" button
3 C: /LOGIN is issued
4 S: Server sees /LOGIN as a private alias resource request and
issues a 401 with WWW-AUTHENTICATE digest response header.
It will also output cancelation html code if the user
clicks cancel.
5 C: Safari sees the DIGEST challenge and prompts the user
to login. The original /LOGIN request is reissued with
the authorization header.
6 S: Server sees /LOGIN as a private alias resource request and
also sees the authorization header. It is validated
and it now wants to redirect to /DEFAULT.HTM.
7 C: Sarafi sees the redirection but it will request it without
the DIGEST authorization header.
8 S: Servers sees the /LOGIN without any authorization header
and repeat step 4 again.
All other browsers will always send the authorization header with all
requests, including redirection responses by the server.
Whats the skinny here?
Thanks!
---