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

Re: Configuring so there is a different authentication for reading and writing

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

excuse typos, should be "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. "

Bruce Gough wrote:
> 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 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_tortoisesvn.tigris.org
> For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-06-20 19:23:34 CEST

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

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