[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: Joseph Galbraith <galb_at_vandyke.com>
Date: 2006-10-09 22:36:06 CEST

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.

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.



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:36:27 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.