[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: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-10-07 21:07:35 CEST

There's still the question of how to behave when updating a working
copy that has auth info which is no longer valid on the server.

Let me expand this to the general problem:

Subversion has some commands that, in some circumstances, can prompt
the user for information. Any script that runs such commands may need
a `--non-interactive' option to suppress the prompting, because the
script can't always control whether or not the prompt-causing
circumstances will arise.

We can get rid of the option, but only if we also *never* prompt as a
default fallback behavior.

Do we want that?

-K

Colin Putney <cputney@whistler.net> writes:
> I'd stick to this simple rule of thumb:
>
> If the authentication information has been provided explicitly on the
> command line, but does not resulting in successful authentication,
> fail with an appropriate error. Otherwise, prompt the user.
>
> This would mean prompting when implicitly supplied authentication
> information (such as cached tokens) is unsuccessful, or when it's
> simply not available. The common use case for this would be a regular
> user, which fits.
>
> Script writers need only be explicit about how to authenticate in
> order to get the behaviour they want. Subversion should supply a long
> option for each type of authentication information it can use. So, for
> example, if we supported ssh key exchange, we'd need an --rsa-identity
> option. No big deal.
>
> The failure modes here aren't too bad. Script writers who run into
> problems because of the prompt have a clear and easy way to deal with
> it - they just add an option to their command line. Users who go to
> the trouble of explicitly supplying authentication information on the
> command line aren't going to be put out when they receive and error
> message instead of a prompt. We can assume their doing things the hard
> way for a reason and can deal with the results.
>
>
>
> Colin Putney
> Whistler.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 7 21:34:43 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.