> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_xbc.nu]
> Sent: Wednesday, August 11, 2010 10:37 AM
> To: dev_at_subversion.apache.org
> Subject: Re: Bikeshed: configuration override order
>
> On 11.08.2010 11:05, Bolstridge, Andrew wrote:
> > The second aspect: client-stored passwords, this isn't so much about
> storing them on the client but about having different ones. Enterprises want
> single-signon, ie, a single password, centrally held, that is used for all
> apps. They don't really care about storing it locally so much as caring when
> Mildred calls the helpdesk to say her password doesn’t work only to find
> she's changed her main login but her svn password is the old, different one.
> I don't think there's much to do here, except to get LDAP working.
> Fortunately, VisualSVN allows integrated authentication with Active
> Directory, and most enterprises still use Windows.
> >
>
> What has that got to do with anything? You stock plain-vanilla
> Subversion server can integrate with Active Directory just fine, if
> you're serving via Apache. You don't need VisualSVN for that. So a
> password update will change the SVN password, said user will receive a
> password prompt from the Subversion client *once*, and SVN will
> presumably store that password securely (at least, it will on Windows).
>
I should have been a little clearer - VisualSVN Server (the enterprise version) has the ability to log you on automatically without asking for a password at all.
I know Apache can do it too - VisualSVN Server (non-enterprise version) does that, but requires the client to supply a password as per normal. It doesn't need a separate password auth list as it uses the LDAP support in Apache (note that VisualSVNServer is apache under the covers).
That doesn't mean that svn (without Apache) doesn’t need LDAP support itself, Svnserve should support that natively as we're talking about the svn tools, not just svn-inside-apache.
Andy
Received on 2010-08-11 13:06:38 CEST