--On Saturday, March 29, 2003 4:35 PM -0800 Manoj Kasichainula
<manoj@collab.net> wrote:
> - 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 intent was for the repository UUID to be passed into the auth function.
This would allow some idea of which repository it is for. (Ideally, a cache
underneath .subversion rather than in the WC would leverage this.) There
should be a property set in one of the config values that is the UUID. (I
seriously haven't looked at it since mbk committed the UUID's to make sure it
is in there.)
> - The client won't know how to cache the credentials. There can be
> multiple servers, or multiple user databases on a given server.
If it has the UUID, I think it should be able to identify it. A more
user-friendly naming scheme could be helpful to the prompting providers
though. But, the UUID should be enough for the internals - I think. So, the
relevant information could be stored in the config hash and the prompting
provider could display that or whatnot.
> - "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.
Yeah, I like that name a bit better.
> - 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.
Nah, because we want to keep it simple - yes, that does mean there's a lot of
'em. In your example, I'd count at least 10 providers. =) I stopped
counting...
> 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.
Nah. I don't think so - my opinion. It should be depth-first. A store
should be exhausted before it moves on. Let's say you have multiple
credentials for a repository in your .subversion dir. The first one fails.
I'd rather it try again before it hits the prompting provider. With a
breadth-first, the prompting provider would get called before the second
credential is tried from the cache. Ick. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 31 18:58:10 2003