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

Thoughts on libsvn_auth

From: Manoj Kasichainula <manoj_at_collab.net>
Date: 2003-03-30 01:35:10 CET

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

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.