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

Re: Thoughts on libsvn_auth

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-04-02 22:05:09 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

> I'm imagining this solution: we declare an 'auth_realm' structure in
> svn_auth.h which contains {UUID, URL, description_string}. The
> caller of svn_auth.h routines can create one of these, fill in
> whatever information it has at the time of the challenge, and pass
> the structure directly into svn_auth_first_creds(). Providers can
> make use of whatever info is available.

Ouch. Gstein pointed out to me that it's bad to assume that a
repository UUID might ever be available before authentication. People
may not want to leak this information, and it's too difficult a
requirement to force on every future RA layer. (As an example,
suppose in the future, ra_svn needs credentials just to set up a
tunnel -- it hasn't even accessed the repository yet.)

gstein came up with a better solution.

Let's allow each RA layer to create its own opaque 'realmstring'. The
string could be any combination of UUID, URL, description, etc. It
might vary not only by RA layer, but also based on the type of
challenge received, and how much information is available at the time
of challenge. It's completely up to an RA layer to decide how to
create a unique realmstring based on the circumstances.

Either way, svn_auth_first_creds() now takes a const char *realmstring
argument. Providers treat the string as an opaque blob, and use it to
differentiate one set of credentials from another.

---------------------------------------------------------------------
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:06:05 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.