Hi,
I am resurrecting this old thread as the problem has not gone away and I think I have new info but I am not sure how best to proceed... More inline below...
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: 10 March 2011 20:58
> To: Cooke, Mark
> Cc: Daniel Shahaf; users_at_subversion.apache.org
> Subject: Re: Need help troubleshooting user authentication (apache)
>
> On Thu, Mar 10, 2011 at 8:20 AM, Cooke, Mark
> <mark.cooke_at_siemens.com> wrote:
> >> -----Original Message-----
> >> From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> >> Sent: 09 March 2011 16:48
> >> To: Cooke, Mark
> >> Cc: users_at_subversion.apache.org
> >> Subject: Re: Need help troubleshooting user authentication (apache)
> >>
> >> Cooke, Mark wrote on Wed, Mar 09, 2011 at 14:44:31 -0000:
> >> > [Wed Jan 12 10:06:38 2011] [error] [client ip-address]
> >> > user user_a:
> >> > authentication failure for "/svn/dept/project/trunk":
> >> > Password Mismatch
> >> >
> >> > I do not understand where the 'Password Mismatch' error is
> >> > coming from, why does that only happen when using subversion
> >> > and not the browser? I have tried searching for "rejected
> >> > Basic challenge" (both svn.haxx.se and the wider net) but
> >> > I've not found anything that hes helped so far.
> >> ...
> >> > What can I do to try to work out what the problem is? It
> >> > is only svn and (currently) for only this one user... I'd
> >> > really appreciate any help at this point.
> >>
> >> * Have you tried creating a new OS user for that one user?
> >
> > Not yet. Corporate IT consider it my problem and that option is
> > definite *last resort* material *sigh*
> >
> >> * Yes, may be a good idea to look up where "Password Mismatch" is
> >> generated. (I haven't heard of it before, but I don't claim to
> >> have heard of all typical syslog messages.)
> >
> > I guess it means exactly what it says but I'll try looking in the
> > source once I've found it to confirm. I did find one comment to
> > an article that said they had problems with "AuthzLDAPAuthoritative"
> > set "On" so I might try turning that "Off" but I need to check the
> > implications of that.
> >
> > Still no idea why this only applies via the svn client (either
> > command line or TortoiseSVN) and not when accessing the server
> > using https via IE8...
>
> As a quick drive-by suggestion, two things come to mind:
> - SVN might use cached credential, browser doesn't. Maybe just
> (re)move the cached credentials on the client-machine (from
> %APP_DATA%/Subversion/auth, or from the registry (see svnbook)),
> and try again?
>
> - proxy: svn only goes through proxy if it is configured as such in
> the servers file in the runtime-configuration area. Browser might
> use different proxy settings.
We tried all the ways we could think of to clear cached credentials and it did not help. The only solution we found was to change the users password _and_ delete their roaming profile (a bit drastic considering all the info stored in there).
However, I have now had more than one user with a problem and have found that the issue appears to be related to specific characters in the passwords. I am wondering if there is a code page type issue here...
Details: running on corporate Windows XP (SP3) and IE8, using subversion 1.6.17 (both command line and equivalent TortoiseSVN). Server is Windows server 2008, apache latest 2.2 with SSL... All configured (as best I can tell) to English _UK_ settings.
All the passwords that have caused problems have used the English currency symbol `£`. The browser is being used to "remember passwords" and correctly prompts for a new one after the regularly enforced password change.
Is there any way to log on the server what subversion is receiving as the password? I realise this is a dodgy move but I do not know how to confirm my suspicions that the browser is correctly passing the `£` sign but for some reason both command-line and TortoiseSVN are passing something different...
I hope someone can help me to pin this down.
~ mark c
P.S. we have now upgraded to 1.7.4 but since we "know" not to use specific characters the problem has not reappeared. I'm happy to sacrifice my profile if anyone can help me on how to confirm the problem is (not) what I think it is...
Received on 2012-04-17 11:35:20 CEST