Hi. This is my first post to the list in about 2.5 years. As a sort of
reintroduction, I'm Manoj, and I work at CollabNet along with many
others on this list. Some people here will know me from my past work
on Apache.
With some help, I've been learning the svn-client authentication
API, and I have some comments and questions on it.
- I see nothing in the API that tells the app or the user what the
scope of the authentication is. Am I missing something? The
libraries say "gimme a user, gimme a password", and the app provides
them. This is a problem because:
- The user won't necessarily know what repo the authen request is
for. Yes, the user specifies a repo, but what if there's an
svn:externals added, and it's the one generating the
authentication request?
- The client won't know how to cache the credentials. There can be
multiple servers, or multiple user databases on a given server.
So, the subversion libraries need to be able to tell the authen
providers in what "space" the credentials are recognized. I'll call
this a "realm" for now, though this overloads a term already used in
HTTP and elsewhere. The form of the realm and its usage would depend
on the cred_kind.
For HTTP basic auth, the realm would be a (host-name, port, HTTP
AuthName) tuple, though I'd need to look this up in the HTTP protocol
spec to be sure. I don't know how much of the credential caching is
handled by neon, but hopefully it handles a lot of the details.
For X.509 client certs, the realm would be a (host-name, port,
list-of-allowed-CAs) tuple. Here, again I'd need to learn how neon
handles auth caching, but there is usually SSL session caching, so
the application auth provider wouldn't be so involved.
- "save_credentials" has a name that implies a very specific purpose:
saving credentials for long-term storage. But that hook could be
useful for other things, and "saving" could be a vague concept
(which might apply to caching, for example). How about naming it
something like "credentials_accepted"? This better conveys the idea
that the auth provider can do what it wants in the case. This could
mean asking the user whether to save the password to disk, caching
the password for 10 minutes, or just popping up a nice dialog box.
- An example: the command-line subversion client could hypothetically
look in a password file, the svn config file, an environment
variable, and finally prompt the user in the xterm, and cache the
password in RAM for the lifetime of the program, with an option of
storing in the equivalent of .cvspass. A GUI client might query the
GNOME central configuration engine, read a very differently
formatted config file, then pop up a dialog box, then cache the
result in memory for a GUI-configurable 10 minutes, or store the
result in what I'm told is the GNOME equivalent of the Windows
Registry.
Except for the simple text mode case, I don't think that
authentication providers will be very sharable, and that if they
are, they are trivial enough that copying the code or just writing
utility functions is simpler.
Also, the way svn_auth loops through the providers might not be what
the client wants. Instead of exhausting one iterable provider before
trying another, maybe we want to try all the iterable providers once
instead, breadth-first instead of depth-first.
So, I claim that the cost of the logic for looping through multiple
providers isn't worth the benefit. So let the app just provide one
custom provider per cred_kind. The looping stuff can be left in some
utility code if we think that will be useful, and the client can
hook that to the single callback if desired. This makes the
interface easier to understand, at least for me.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 30 01:35:51 2003