Thank you, Ben, very informative. So I get from this that unmodified, mod_auth_digest behaves as I said, though it could be modified to force the browser to do a prompt. I note that in any case though, the module has no knowledge of what the user is doing with the browser, such as shut-down/restart, and there is no standard which requires the browser to send such information to the server. On Dec 22, 2013, at 3:56 PM, Ben Reser <ben@xxxxxxxxx> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|