> Mark Phippard wrote:
>> "C. Michael Pilato" <firstname.lastname@example.org> wrote on 10/09/2006 04:01:28
>>> 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.
>> a client authenticate, fail authorization and then reauthenticate does
>> 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.
> In my humble opinion, which counts for nothing, I think
> where we need to be eventually is having subversion
> tell SSPI what user it wants to authenticate as.
> I'm 90% certain SSPI gives this level of control... of
> course, if I had to guess, I'd guess neon doesn't give
> this level of control :-(
> Right now, the main issue we are running into is that
> SSPI succeeded with a user like GUEST, and we wish
> it hadn't.
> I suspect it is entirely possible that we will run into
> cases where SSPI succeeds with user x, but we wish it
> had succeeded with user y (I don't think it is common
> to have multiple user credentials available but I don't
> think it is impossible either.)
> It seems rather like a using a sledge-hammer to drive
> finish nails to disable the feature because we are
> picking the wrong user.
with svn 1.4.x neon0.26.x, it just doesnt work. please refer to thread
http://svn.haxx.se/users/archive-2006-09/0950.shtml for a legnthy discussion
on how0.25.x Neon works but 0.26.1 doesnt. We resolved this issue by using
1.4.x compiled against 0.25.x of Neon (Thanks DJ Heap). Since TSVN 1.4.x is
shipped with Neon 0.25.x it was ok.
the current mention of Authentcaion retry in between a task is also a
current issue and very big one (although only surfaces when carrying out a
large repo activity). Also described here at
is SSPI/GSSAPI important, yes, especially authenticating against multiple
domain (e.g. a win2k3 forest with more then 1 domains, its probably the only
available option!). It will be worthwhile to backport to 1.4.x if it helps
mitigate these issues.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Oct 9 22:52:25 2006