So, I'm adding NTLM authentication support to ra_serf and I'm stumbling
on an issue. Basically what happens is that negotiating an
authentication connection fails for the 4 connections that are created
to serve as parallel pipelines (see subversion/libsvn_ra_serf/update.c
finish_report).
What happens is this: ra_serf sets up an initial connection, on the
first request the server is asking for authentication and ra_serf
responds with the credentials of the user authenticating the request.
For basic authentication that's about it, we store the credentials in
the session and keep reusing them for all other connections that ra_serf
creates later.
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.
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.
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.
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.
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.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 7 22:24:01 2007