You said "Last night we upgraded our server to 1.8.8". I am simply saying
that upgrading the server would not change the usernames your clients were
authenticating with.
If you also upgrade the clients, then that could be relevant but you never
mentioned upgrading the clients.
If you have Apache access logs from before the server upgrade you ought to
be able to search them for these other user names to see if it was
happening before the server was upgraded.
On Fri, Apr 25, 2014 at 1:42 PM, Tom Kielty <calbuildmaster_at_gmail.com>wrote:
>
>
>
> On Fri, Apr 25, 2014 at 12:06 PM, Mark Phippard <markphip_at_gmail.com>wrote:
>
>> It couldn't have changed. As you said, you upgraded your server but the
>> username comes from the clients.
>>
>>
>> On Fri, Apr 25, 2014 at 12:56 PM, Tom Kielty <calbuildmaster_at_gmail.com>wrote:
>>
>>>
>>> On Fri, Apr 25, 2014 at 11:10 AM, Mark Phippard <markphip_at_gmail.com>wrote:
>>>
>>>> On Fri, Apr 25, 2014 at 11:45 AM, Tom Kielty <calbuildmaster_at_gmail.com>wrote:
>>>>
>>>>> Last night we upgraded our server to 1.8.8. Everything smooth.
>>>>> However, we are seeing some strange behavior regarding usernames.
>>>>>
>>>>> Issue 1: One of my users on a Win 7 64 bit machine, uses the SVN CLI
>>>>> as his client. Before the upgrade he was working fine. After the upgrade he
>>>>> keeps getting a forbidden error. The apach logs shows he is logging in with
>>>>> Xxx.Yyy as a username when we require and have defined in the
>>>>> svnaccess.conf file xxx.yyy. I had him delete the auth folder reopen a
>>>>> command window and try again. No luck. The server logs keep showing him
>>>>> trying to login with Xxx.Yyy. I even tried to use the --username argument
>>>>> on the update as well as a fresh checkout and it ignores it. His machine
>>>>> credentials are Xxx.Yyy. He is the only user so far that is having this
>>>>> problem. Any ideas what is causing this and how to fix it?
>>>>>
>>>>> Issue 2: An automated process on Windows 2003 R2, is having a similar
>>>>> problem as Issue 1. The process runs as "administrator" but the cached
>>>>> credentials are a different user. The process is able to run an update with
>>>>> no errors, but the apach log shows an unknown username from that IP
>>>>> attempted to access a SVN url.
>>>>>
>>>>> These issues seems to be new to 1.8.8. We upgraded from 1.7.5.
>>>>>
>>>>>
>>>> Subversion itself does not control the username on the server, Apache
>>>> does. Apache simply tells Subversion the username that was used.
>>>>
>>>> Your Subversion Apache configuration can include the following
>>>> directive that would "fix" this problem:
>>>>
>>>> AuthzForceUsernameCase lower
>>>>
>>>> If you add that directive, Subversion will convert all usernames to
>>>> lower case before comparing them to your access rules. Just make sure you
>>>> use all lower case in those rules.
>>>>
>>>>
>>>> --
>>>> Thanks
>>>>
>>>> Mark Phippard
>>>> http://markphip.blogspot.com/
>>>>
>>>
>>> Mark,
>>>
>>> Thanks for the workaround. This solved part of Issue 1.
>>>
>>> Why did this change? Why are SVN clients taking the logged in user name
>>> over the cached username?
>>>
>>> And yet with Issue2 it seems to be the opposite.
>>>
>>> Tom
>>>
>>>
>>
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>
> Mark,
>
> Something did change. My users who sign in to Tortoise or the CLI using
> lowercase names failed to authenticate. It feels like the newest clients
> are taking the logged in username and not one entered. Plus why could I not
> override the username passing in a --username to a checkout command. It was
> ignored.
>
> My main concern is that this upgrade is not seamless like the other ones
> have been.
>
> Tom
>
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2014-04-25 19:48:40 CEST