[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Configuring so there is a different authentication for reading and writing

From: Bruce Gough <bruce_at_ijws.com>
Date: Fri, 20 Jun 2008 13:29:59 -0400

How do I configure my server so I can use one authentication for read
and another for write?

See below for the thread from last September. We did get things to work
with read vs write with collabnet. When attempting to commit on the read
only account, it returns HTTP 401 which caused tortoise to ask for the
username and password, and I entered the account with write access. So
that worked fine.

Now we use just Apache with subversion over WebDAV (due to company
switch to jira), and use mod_authnz_svn module for access control. Now
on a commit when read only account is saved, it comes back with HTTP 403
(forbidden) and tortoise just boings and complains and does not ask for
new credentials.

How do I make this work the way it did before? We could change
mod_authnz_svn to return 401 instead of 403, but we don't want to
maintain a vendor branch for our branch tracking system...

Help!

We are running Subversion 1.4.6, latest tortoise clients.

Re: Feature Request: Allow "save authentication" for reading and writing
separately
Bruce Gough wrote:
>
>
> Stefan Küng wrote:
>> Bruce Gough wrote:
>>> Feature Request: Allow "save authentication" for reading and writing
>>> separately
>>>
>>> I have been using tortoiseSVN for a couple of years, and it works
>>> great. To avoid mistakes, I leave my client configured so that I
>>> must authenticate every time I access the repository. I have avoided
>>> doing "update" or completing the commit dialog by mistake more than
>>> once.
>>>
>>> My only problem with this is when I am doing activities like "check
>>> for modifications", then I click "Check repository", it does an
>>> authentication step. Then if I want to double click any file in the
>>> list of changed files and see the differences, it does another
>>> authentication each time I double click another file in the list of
>>> changed files.. Each one has the "save authentication" checkbox, but
>>> I think that checking it would save the authentication and use it
>>> for all authentication steps.
>>>
>>> I have worked around this by checking the box, then later going into
>>> the settings and setting it back to requesting authentication.
>>>
>>> It might be a bug for the specific case where I have checked for
>>> modifications, then must authenticate for each file on which I want
>>> to view the differences. It seems like it should not be necessary then.
>>>
>>> One possible way to improve this could be to have a separate flag
>>> for "read" type operations vs. "write" type operations. Even though
>>> the diff of modifications could allow writing a merged file, that
>>> would not update the repository so it would count as a read operation.
>>
>> That feature is already implemented :)
>> You have to configure your server accordingly.
>>
>> Either configure the 'read' operations to not require authentication
>> at all (anonymous access) and only require authentication for the
>> write operations, or you could set up two different users, one which
>> has only read access (but still needs to authenticate, and for which
>> you then store/save the authentication data), and another one with
>> write access (for which you won't store/save the authentication data).
>>
>> Stefan
>>
>>
> Thank you for responding.
>
> We use collabnet authentication with subversion, and are at about 6
> developers. Doubling the users would come close to the license limit.
> My admin does not like the idea of anonymous access. It sounds like
> the saved authentication would fail, then it would come back with the
> prompt.
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-20 19:30:26 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.