Stefan Küng wrote:
> C. Michael Pilato wrote:
>> Stefan Küng wrote:
>>> 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).
>>
>> I had a bit of trouble parsing that last bit. Are you suggesting that
>> we could get by in 1.4.x by simply hard-coding a first attempt with SSPI
>> followed by a fallback attempt without?
>>
>> See, if we can avoid adding this runtime configuration option, my
>> concerns (at least about that matter) will vanish.
>
> No. Either you compile SSPI auth into neon, then it will always use this
> first. It will only fall back to basic auth if SSPI authentication
> fails. But the problems we have here are not failed SSPI authentications
> but a failed authorization due to SSPI authenticating as the 'wrong' user.
> If you don't compile SSPI in to neon, then you will always get the basic
> authentication - you can't authenticate with SSPI at all.
>
> That's why the runtime option in neon 0.26 is required to fix this
> issue. Because just not compile SSPI into neon won't solve the issues
> where users need SSPI to authenticate.
>
> Stefan
>
Uh. Hm. Can you perhaps rephrase this bit, then? I obviously missed
it the first time around.
(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).
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Oct 9 22:01:41 2006