Re: On backporting r21531 to 1.4.x.

C. Michael Pilato wrote:
> 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).

with SSPI compiled into neon < 0.26:
neon authenticates with SSPI
if (authentication successful)
   tell client auth successful
else
   try other auth methods (e.g. basic auth)

there's no way to reauthenticate with basic auth, because neon will
always use SSPI first and always succeed (for the setups which have
problems now, those where the *authorization* fails). That's why I asked
Joe Orton for the new API, and that's why he added it in neon 0.26.x.
The only way I could avoid these problems in TSVN 1.3.x was by not
compiling SSPI into neon at all.

without SSPI compiled into neon:
neon authenticates properly because it uses basic authentication. But
since it doesn't use SSPI, people who need SSPI can't connect to the
repository.

with SSPI compiled into neon 0.26.x:
the client can tell neon whether to authenticate with SSPI or not. The
current implementation in Subversion trunk is to configure the use of
SSPI in the servers config file. That means for a certain server, it
either always or never uses SSPI. And users need to do the configuration
themselves, which will automatically lead to a lot of mails reporting
that they can't connect to their repositories (users don't read manuals).

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
failure
* Subversion retries the authentication, but this time tells neon to not
use SSPI
* neon uses basic authentication, which makes it ask Subversion 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.

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