On 2/25/14, 1:25 PM, Markus Schaber wrote:
> I tend to think it might be a sensible behavior to not prompt for
> Authentication on the client side during specifically this kind of
> upwards tree walk when the client successfully authenticated for the
> "main" request, and later fails with the same credentials for a parent
> directory - it could catch this situation, and just treat it like a
> "forbidden" internally.
>
> However, I'm not sure whether this is easy to implement given the
> asynchronous, parallel architecture of serf...
If only it were so simple. HTTP is stateless.
Just because the credentials worked for some of the requests doesn't mean they
will continue working for all requests. Authentication credentials can change.
If you just think about passwords that seems absurd but you can't just think
about passwords in this case.
Digest authentication has the ability to expire nonces. The server gets to
decide if the client should be prompted to provide authentication again or not
with the stale=TRUE flag. Kerberos has tickets that can expire.
Even with basic auth a user can change their password in the middle of an
operation. If you think that's silly consider a enterprise system with a
checkout that takes a long time to run and a user decides to change their
password in the middle (probably a bad idea but we really shouldn't fail).
That said this whole thing does raise the issue that a 1.8.x client talking to
a 1.7.x or older server that's configured with mixed anonymous/authenticated
access is going to prompt users for a password when doing the PROPFINDs for
inherited properties unless the anonymous user has access all the way up to the
root. When the user happens to have credentials you can consider this
beneficial. When the user is a fully anonymous user then this turns into a
hassle that means anonymous users have to know to enter a bogus password to
trigger the code to stop the inherited properties walk. Granted setups like
this are already problematic in other ways, so this isn't entirely new. I'd
imagine that's why we haven't already had someone complaining about this.
In my opinion Subversion needs the 401/403 distinction to really work properly.
There are too many intertwined protocols/implementation details to avoid that
now. Add one more detail to why using a stateless protocol is annoying.
Received on 2014-02-26 03:56:41 CET