[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

HTTP authentication (was: Thoughts on libsvn_auth)

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-04-02 22:49:27 CEST

[ somewhat moot since the other branch of this thread addresses this, but I
  wanted to discuss HTTP auth design here ]

On Wed, Apr 02, 2003 at 12:58:01PM -0600, Ben Collins-Sussman wrote:
>...
> ra_dav, however, is really messed up in this department. RA->open()
> doesn't immmediately connect to the network, and that's perfectly
> fine. But the *only* way it can get a UUID is by doing a PROPFIND
> right now, which might be an auth-protected request. This is absurd.
> This is exactly why I said (a while back) that the repository UUID
> should be a custom X-SVN header sent by the server. Any time httpd
> sends a "401 Authorization Required" response, the UUID should be sent
> in the response header. End of problem.

It is a problem only if you start with the premise that UUID is the proper
key for your auth data :-)

> gstein, is there anything wrong with that solution? Otherwise it
> seems like ra_dav is in a chicken-and-egg situation. And I don't want
> to make libsvn_auth jump through absurd retry hoops to get around it.

HTTP authentication specifies a "realm" as the key, along with the host
name. Using another key like the UUID circumvents what the administrator
might be arranging on the server by how they set up their realms.

IOW, the X-SVN-UUID header idea is moot since you want to use the realm
provided in the auth challenge. Furhter, the UUID is "wrong" since HTTP auth
already specifies a scope for user/pass queries.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 22:47:09 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.