[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: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2006-10-09 22:47:14 CEST

Mark Phippard wrote:
> Stefan Küng <tortoisesvn@gmail.com> wrote on 10/09/2006 04:25:08 PM:
>
>> 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.
>
> In general I think I agree with you -- based on your previous messages.
>
> That being said, suppose SSPI is enabled and I am using it. I connect to
> a repository, it correctly authenticates me as my ID via SSPI. I try to
> access something I am not authorized to. Won't I now get prompted for
> username and password? Is that really the behavior we want?

I think yes. From what I learned on the TSVN mailing list, a lot of
people have set up repositories where they have restricted access to
folders. But they sometimes still need access to those. In that case,
they then like to be asked for username/password so they can provide a
different auth data.
Something like the 'su' command. In desktop linux environments, you get
asked for the root password as soon as you start an application which
needs those. That doesn't mean you want to log in as root, but only get
asked for that auth data if needed.
The same would happen with Subversion in your example: most of the time,
SSPI authentication would succeed without problems, and you can access
the files you need. Once you want to access 'restricted' files, you get
asked for username/password.

> What would happen in authz scenarios where you are not authorized to a
> subset of files, such as on a checkout or log? Presumably in these
> scenarios it would just work like it does today and silently not include
> those files.

Worst case:
SSPI succeeds, authorization later fails
Subversion reauthenticates without SSPI, authorization fails again
Subversion behaves like it does now when authorization fails.

Which means: two authentication attempts, but which the user won't
really notice (the user will only notice one).

> Perhaps SSPI should be treated somewhat like SSL client certs or proxies?
> Off by default, turn it on if you need it as it is an "advanced"
> authentication method.

That's how it is implemented now on trunk (I don't know if SSPI is
enabled by default or not, but the config option is what you suggested).

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:47:13 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.