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

Re: non-interactive user authentication

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-10-07 22:32:34 CEST

Karl Fogel wrote:

>Branko Čibej <brane@xbc.nu> writes:
>
>
>>I think the first order of business is to make a clean separation
>>between the libraries and the client program. IIRC, right now the
>>prompt is coming from the RA lib. Instead, the lib should simply
>>return an error if authentication fails; then the client can decide
>>about prompting or not.
>>
>>
>
>I thought it is ultimately the client deciding whether or not to
>prompt? The RA layer just calls a client-supplied routine to get auth
>info. What that routine does is up to it.
>
>
>
>>The next problem is what to do with the failure in the client. IMHO,
>>if any auth tokens were passed in explicitly on the command line, it
>>should not prompt -- the user had her shot, and missed.
>>
>>
>
>Yes, I'm fine with that, but we still have to handle the circumstance
>where subversion might prompt when the tokens were *not* passed on the
>command line.
>

Right. I'm beginning to wonder whether we should prompt at all, and the
answer is far from simple.

Now, none of this is a problem ina purely interactive environment. The
problems we're discussing only show up when the "svn" command is being
scripted. A simple way out is to simply say that any script that's
complex enough to have to bother with authentication should use the swig
wrappers instead. :-)

Anyway, I'm glad we're having this discussion, because it shows that
even features that are simple to implement can involve complex design
decisions.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 7 22:33:15 2002

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.