On 12/22/13 6:07 AM, Allasso Travesser wrote:
> So I believe that mod_auth_digest has no and uses no mechanism for tracking
> sessions, and always operates in a stateless context. In essence, for each
> request it checks the request header for proper login metadata, and if and only
> if it qualifies does it allow access, otherwise, it sends a 401. The policy on
> prompting and gathering of login info from the user is entirely up to the browser.
>
> Does this sound correct?
Yes and no. mod_auth_digest doesn't provide a way to configure this, though it
probably could.
You can specify the lifetime for the nonce with AuthDigestNonceLifetime. Which
can trigger the client side to need to produce a new request which includes an
Authorization header that uses a new nonce.
The RFC says [1]:
The authentication session lasts until the client receives another
WWW-Authenticate challenge from any server in the protection space. A
client should remember the username, password, nonce, nonce count and
opaque values associated with an authentication session to use to
construct the Authorization header in future requests within that
protection space. The Authorization header may be included
preemptively; doing so improves server efficiency and avoids extra
round trips for authentication challenges. The server may choose to
accept the old Authorization header information, even though the
nonce value included might not be fresh. Alternatively, the server
may return a 401 response with a new nonce value, causing the client
to retry the request; by specifying stale=TRUE with this response,
the server tells the client to retry with the new nonce, but without
prompting for a new username and password.
and [2],
stale
A flag, indicating that the previous request from the client was
rejected because the nonce value was stale. If stale is TRUE
(case-insensitive), the client may wish to simply retry the request
with a new encrypted response, without reprompting the user for a
new username and password. The server should only set stale to TRUE
if it receives a request for which the nonce is invalid but with a
valid digest for that nonce (indicating that the client knows the
correct username/password). If stale is FALSE, or anything other
than TRUE, or the stale directive is not present, the username
and/or password are invalid, and new values must be obtained.
So it should be possible to change the module to force reprompting of the
password on the client by simply omitting the stale=true from the
WWW-Authenticate header. That could be done by adding a new timeout that once
the nonce age passes it doesn't send stale=true or by a configuration flag that
specifies that the sale=true isn't sent when the nonce lifetime has expired.
This all assumes that the clients actually follow the RFC (and interpret the
same way I am) in this regard and I haven't bothered to test that.
The RFC ultimately says nothing about how long a client should cache the
credentials. It implies that the client should prompt the user for credentials
if stale isn't true, but given that browsers have password caching, I'd suspect
that even the above may not be reliable since some browsers may simply try
their cached credentials first.
[1] http://www.ietf.org/rfc/rfc2617.txt (section 3.3)
[2] http://www.ietf.org/rfc/rfc2617.txt (section 3.2.1)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|