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

Re: Options for how ra_svn client authenticates

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-10-18 05:27:03 CEST

On Fri, 2003-10-17 at 10:14, mark benedetto king wrote:
> I think you meant "stateful". :-)

Yes, of course.

> What if, when the server decides it needs credentials from the client,
> it sends back a special tuple, for example:
>
> (CHALLENGE (CRAM-MD5 DIGEST-MD5 ...))
>
> ra_svn is stateful, yes, but AFAIK, the client is always blocked inside
> svn_ra_svn_read_tuple() when waiting on the server.

I think read_tuple() is too deep of a level to be adding this
functionality; it would be a little like hooking a major control
subsystem into strcpy(). If we're going to take this route, I'm
thinking we should do it by adding a protocol capability which inserts
authentication challenge points into the protocol at key places (always
at the top level of control, not the middle of an edit or report). At
these points, the server can say "go" or "I need credentials with foo
nature" or "ha, not a chance".

I think this is probably the right direction to go in, divorced as it is
from the nature of most stateful protocols. It's the way our
infrastructure works, it's the way the Subversion project server wants
things to work, and it's the most similar option to the way ra_dav
works. And if, in the future, clients want a way to force stronger
authentication than the server needs to complete an operation (in order
to attach their names to commits when the commits could be made
anonymously), the libraries won't be stopping them.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 18 05:28:02 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.