Daniel Rall wrote:
> Stefan, thank you for the *excellent*, detailed explanation of all the
> various behaviors. :-)
> On Mon, 09 Oct 2006, Stefan Küng wrote:
>> So my suggestion would be:
>> * Subversion tells neon to authenticate with SSPI
>> * SSPI authentication succeeds
>> * Subversion tries to access the repository, but gets an authorization
>> * Subversion retries the authentication, but this time tells neon to not
>> use SSPI
>> * neon uses basic authentication, which makes it ask Subversion for
> With this strategy, GSSAPI/SSPI authentication could successfully
> authenticate you as the *wrong user* (since you're not explicitly
> providing it with credentials).
> If authorization doesn't fail, you could end up making commits under
> an inappropriate user ID.
That's what happens now too: SSPI is enabled all the time. Whatever user
SSPI authenticates with will be used to access the repository. That's
why we have the problems in the first place: users complain that the
authorization fails, without them being asked for username/password.
>> With my suggestion, the config option in the servers file would be
>> obsolete because Subversion would automatically retry without SSPI.
>> But of course, this only works with neon 0.26.x and not with neon 0.25.
>> And it requires using the new API of neon.
> Will specifying --username/--password on the command-line (or
> equivalent via the APIs) be enough to override the credentials
> inferred by GSSAPI/SSPI auth? I'm not certain that it is...
No, at least not with neon 0.25.x. It always uses SSPI first. Only if
SSPI authentication fails, it will fall back to basic authentication
where then Subversion can provide username/password.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Oct 9 22:49:50 2006