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

Re: On backporting r21531 to 1.4.x.

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-10-09 22:01:28 CEST

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

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.