RE: SVN re-requests authentication for LOCK operation

Hi George

Thanks for your prompt reply. We do indeed seem to have the situation you describe. When users do an update/commit, the authentication data is automatically given to the apache svn server, and the data is saved in the %APPDATA%\Subversion\auth\svn.ssl.server directory. However, when users attempt to acquire a lock it would appear that subversion looks in the %APPDATA%\Subversion\auth\svn.simple directory for saved authentication. When it finds nothing there, it prompts the user instead of automatically providing the domain authentication. Unfortunately users requesting locks must be authenticated so we can't make use of your suggestion of the "<LimitExcept LOCK>" directive.

I am not sure whether this is a subversion or Tortoise SVN issue or whether it is a bug/feature. Any suggestions how to get around this issue would be much appreciated.

Regards
Sam

________________________________________
From: George Stein [mailto:george.stein@go4more.de]
Sent: 28 June 2007 14:46
To: users@subversion.tigris.org
Subject: Re: SVN re-requests authentication for LOCK operation

Sam Duncan wrote:
>
> Hi
>
> We are running Subversion Server 1.4.3 (r23084) with Apache/2.0.59
> (Win32) (mod_ssl/2.0.59 OpenSSL/0.9.7j SVN/1.4.3 mod_auth_sspi/1.0.4
> DAV/2) with Tortoise SVN clients.
>
> The mod_auth_sspi is working perfectly to authenticate users against our
> domain controller and users can perform update and commit operations
> without having to enter any authentication details (when they are
> connected to the domain of course).  However, it seems that when users
> try to acquire a lock on a file using the "Get lock..." menu item from
> Tortoise SVN, Tortoise requires them to re-enter their authentication
> details.  If the details are entered correctly (i.e. DOMAIN\user.name
> with correct password) then the file can be locked, so the problem is
> not related to repository permissions.  We would ideally like users to
> be able to acquire locks without having to re-enter their authentication
> data.
>
> Has anyone ever come across this behaviour before?
>
> Regards
> Sam Duncan

Hi Sam

we observed a similar behaviour when entering svn ls -R

In our case the authentication token was stored in the
%APPDATA%\Subversion\auth\svn.simple directory instead of the
%APPDATA%\Subversion\auth\svn.ssl.server directory as for the other
requests. Our work around was to grant all users read access as
default and configure Apache with

<LimitExcept PROPFIND>
  Require valid-user
</LimitExcept>

Probably you have to change it to <LimitExcept LOCK> but check if
this is a behaviour you can accept.

I don't know if this is the intended behaviour or a bug.

Best
George

--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 28 16:40:58 2007