C. Michael Pilato wrote:
>>> * Your Windows credentials were passed over the wire without
>>> you having authorized such a thing in an automated attempt to
>>> authenticate. (At this point, if not earlier, my knowledge gets
>>> shaky, and I have to presume that if those creds failed against
>>> the server, some graceful fallback to Basic or Digest auth worked
>>> just fine -- but I dunno.)
>> No, it wouldn't fall back to basic auth. At least not in all
>> circumstances. One problem for example is that the authentication can
>> succeed (if the user is part of a domain which the server hosting the
>> repository is part of too), but later the authorization fails. In that
>> case, Subversion simply gives up with an error and doesn't try to
>> reauthenticate (because the authentication was successful before).
>> This can happen if e.g. the GUEST account is enabled on the domain
>> controller (sometimes it has to be, due to other company apps requiring
>> that). Or if the admin has set up different user accounts for the
>> repository than the users use to log in to their workstations (happens a
>> *lot* from what I get on the mailing list).
>
> Ah! Well, that puts a whole new spin on things, then. Pretend this new
> Neon option never existed. If we fixed Subversion so that it would
> reauthenticate, where would that put us on the usability chart?
If the reauthentication would be done completely by Subversion, then it
might work. But as far as I understand, with SSPI enabled in neon it
will always try first authenticating with that and never even ask
Subversion for authentication data (username/password). Of course that
happens only if the authentication succeeds with SSPI.
That's one of the reasons neon 0.26.x has now the option to disable SSPI
during runtime, so that clients can first try with SSPI, then try
authenticating without it.
(that's also why I think the current (trunk) behavior of Subversion
should be improved: avoid the option in the configuration file but after
the first authorization failure and reauthenticate again but this time
with SSPI disabled).
If it would be possible to just reauthenticate, I would have tried
adding that feature to Subversion myself. I know a little bit the code
where that happens (I once added there my own auth provider to save the
auth data encrypted on Win2k and later - until Subversion did that too).
Of course, I could be wrong here, but the last time I tried that
wouldn't work.
>> The only way to disable the automatic authentication with SSPI is by
>> disabling it during compile time.
>
> You mean without the new Neon API, yes?
The compile time option is still present in neon 0.26.x. And with SSPI
not compiled into the library, there's no use for the new API anymore.
FYI: here's one of the threads I mentioned this before:
http://svn.haxx.se/dev/archive-2006-06/0205.shtml
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 9 21:15:19 2006