Mark Phippard wrote:
> "C. Michael Pilato" <cmpilato@collab.net> wrote on 10/09/2006 04:01:28 PM:
>
>> 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).
>
> I think the only issue should be whether the current way this works is
> deemed a bug with a high enough severity to backport to an existing
> release. I happen to think it is.
>
> Once that is agreed to, then whatever the best solution is, regardless as
> to whether it involves adding a new config option, should be used. Having
> a client authenticate, fail authorization and then reauthenticate does not
> strike me as an ideal solution. Won't this happen over and over again?
> Having an option to just turn the feature off seems better to me and I do
> not see what negative impact this has on existing 1.4 users.
The config option definitely is not a bad idea. But in my experience,
people don't read manuals. Depending on the default option, this is
what's going to happen:
default is SSPI enabled:
* users can't connect to their repositories, because they always get an
"authorization failed" error. They first wonder why this happens, then
send a mail to the mailing lists with a big "BUG:" in the subject line.
* we tell them to disable SSPI in the config file for that server
default is SSPI disabled:
* users can't connect to their repositories, because they have a proxy
in between which requires SSPI authentication. They start wondering why
this suddenly doesn't work anymore, maybe revert back to a previous
version of the client and see that it works there. So they too write a
mail to the mailing list with a big "BUG:" in the subject line.
* we tell them to enable SSPI in the config file for that server
* they get angry because the default was changed and they were not told
(even if it was clearly stated in the release notes).
The best way to deal with this would be:
* option in the servers config file
* if SSPI is disabled in the config file, never use it
* if the option is not set, first try with SSPI, then try without SSPI.
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 22:25:05 2006