On 7/7/07, Lieven Govaerts <lgo@mobsol.be> wrote:
> This doesn't work for NTLM because it's a connection authentication
> scheme so:
> 1. we can't copy authentication session information from a connection to
> another, the server requires a new challenge/response cycle per connection.
> 2. we can't start pipelining requests until we have an authenticated
> connection. If the first request fails with a 401, most likely all other
> requests in the pipeline will fail with the same error code.
Serf has the ability to retry the requests in this case with an
authentication denied via the 'svn_ra_serf__request_create' call that
is invoked after handle_auth returns without an error.
IOW, I wouldn't worry - fix it up such that it properly negotiates the
NTLM authentication and just ride out the storm of remaining 401s
already sent until you get the challenge accepted. How do you know
when the storm is over? Dunno - you'll have to get creative.
> The first issue is handled in the current NTLM authentication code on
> the ra_serf-auth branch, but it's the second issue that I try to solve now.
>
> The solution - it's more a workaround actually - I'm thinking of is to
> send one request for each new connection, get it authenticated and only
> then start pipelining all the others. We can limit this to NTLM or other
> per connection authentication protocols since we have this information
> in the ra_serf session object.
Eh. IMO, that's hacky. Just ride out the storm of failed requests
and renegotiate properly when you get an NTLM challenge.
> This raises some questions though:
> 1. Are the requests in a session limited to one repository? If, for
> example, svn gets a feature to copy files from one repository to
> another, and those repository are in vhosts using a different
> authentication protocol that might be problematic.
RA sessions are per-repository - so all serf conns are per-repository
and won't be shared across RA sessions.
> 2. How to handle updates to partially accessible files? If I'm correct
> the server will send a 401 for files not readable to the authenticated
> user, right? In that case, with a notion of an authenticated connection
> in ra_serf we can report all later 401's as 'access denied' errors and
> during update just continue with the other files.
It should be giving us 403 - not 401 when authorization fails.
> 3. I'm not working on authentication proxy's yet, but I noticed in the
> Squid documentation for NTLM that it's closing the connection after the
> server returns a 401, so the client has to open a new connection and
> immediately provide the NTLM authentication request headers. Hm, that
> might be easy to solve if I change the current code a bit so for each
> new connection in an NTLM-auth session ra_serf already includes the NTLM
> authentication info in the headers of the first request.
Sounds potentially reasonable. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 8 16:36:31 2007