I was away and will get back to you as soon as I got a chance to read through
the information that you provide.
> Hello Vladimir,
> this is from a 'user' perspective. Below is a reference to how Mozilla
> Firefox addresses / facilitates SSPI/SPNego/ authentication methods.
> they have a rather simple configuration method. user configures list
> of 'servers' where Negotiate authentication should be used. They also
> provide Proxy support.
> as regards SSPI issues?
> a) SVN 1.4.x compiled against 0.26.1 Neon doesnt work with SPNego on
> both win32 & linux environment. However, it works fine with 0.25.5
> Neon. May be its how SVN is making use of 0.26.1 changes that is the
> issue here, beyond my skill set. I am trying to learn though.
> b) please refer to http://svn.haxx.se/users/archive-2006-09/1336.shtml
> ... not sure if this is happening due to Neon or Mod_auth_kerb ..
> however mentioned here for ur reference.
>> 1) Ability to disable default credential being passed.
> please see Mozilla link above, the configuration layout, provides
> that. In case of Negotiate, 'only' default credential, in form of Kerb
> token, are provided.
>> 2) Ability to pass alternate credentials but still use SSPI
> I doubt if its gonna be possible in case support is
> Negotiate/GSSAPI only. Usually this is provided by external helpers
> such as 'runas', 'sudo', 'kinit', etc.
>> 3) Ignore SSPI challenge all together
>> 4) Ability to have separate proxy, server credentials???
> e.g., open Pref.js in ur Firefox profile (or go to URL about:config)
> and search for Auth :) I would have posted a link to
> google.com/codesearch page for that, however, not sure what policies
> we have regarding quoting external code.
>> 5) Issue with GUEST credentials being used
> ----- Original Message ----- From: "Vladimir Berezniker"
> To: "Mark Phippard" <firstname.lastname@example.org>
> Cc: "C. Michael Pilato" <email@example.com>;
> <firstname.lastname@example.org>; "Stefan Küng" <email@example.com>
> Sent: Friday, October 13, 2006 12:14 AM
> Subject: Re: On backporting r21531 to 1.4.x.
> Resending this as original did not seem to reach the list.
>> "C. Michael Pilato" <firstname.lastname@example.org> 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.
> Hello everyone,
> I am the guy who originally contributed the SSPI support to neon, and I
> would like to get it working right for majority of the users.
> A possible plan of attack would be:
> * Clearly define what SSPI issues are
> * Agree if there are neon API changes needed. Driven by users such as
> * Clear those changes with Joe Orton (if any)
> * Implement, test, repeat...
> The SSPI issues as I understood so far are:
> 1) Ability to disable default credential being passed.
> 2) Ability to pass alternate credentials but still use SSPI
> 3) Ignore SSPI challenge all together
> 4) Ability to have separate proxy, server credentials???
> 5) Issue with GUEST credentials being used
> Please let me know if I missed anything.
> I have a good idea about how to deal with the first four (4). I need to
> research the GUEST issue, so any relevant info will be appreciated.
> At a first glance, it seems the current flag in neon can only solve #3,
> but I need to check the code to be sure.
> For the Subversion/TSVN team,
> What kind of API in neon would make it cleanest for you to work with
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Oct 17 01:39:39 2006