> -----Original Message-----
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: 17 April 2012 11:02
> To: Cooke, Mark
> Cc: users@subversion.apache.org
> Subject: Re: Need help troubleshooting user authentication (apache)
>
> On Tue, Apr 17, 2012 at 11:34 AM, Cooke, Mark
> <mark.co...@siemens.com> wrote:
> > 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:jcor...@gmail.com]
> >> Sent: 10 March 2011 20:58
> >> To: Cooke, Mark
> >> Cc: Daniel Shahaf; users@subversion.apache.org
> >> Subject: Re: Need help troubleshooting user authentication (apache)
> >>
> >> On Thu, Mar 10, 2011 at 8:20 AM, Cooke, Mark
> >> <mark.co...@siemens.com> wrote:
> >> >> -----Original Message-----
> >> >> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> >> >> Sent: 09 March 2011 16:48
> >> >> To: Cooke, Mark
> >> >> Cc: users@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 think the easiest way to proceed (without the risk of compromising
> real passwords) would be to set up a separate test-repository, served
> via plain http, so you can easily take wire captures. Then make some
> test users with test passwords for that repository, and test you
> theory (by checking what goes over the wire).
>
> --
> Johan
>
OK, I think I have confirmation of a possible bug...
When using a browser, I get the following for <shift>-1 through <shift>-0 on my
UK keyboard (bounded by '[]'):
2012-04-17 16:03:09.734000 : svntest [!"£$%^&*()]
...but when I use the svn command line client I log instead:
2012-04-17 16:01:52.124000 : svntest [!"œ$%^&*()]
Note that the `£` is now different. I think that this explains the `Password
Mismatch` error?
How did I test this? I used something I found with mod_wsgi that meant that I
could log from my normal configuration as follows:
Apache httpd-ssl.conf excerpt (missing unrelated config stuff):
<Location />
AuthBasicProvider wsgi ldap
# subversion user credentials debugging...
# checks for a specific user name and then logs the password...
WSGIAuthUserScript D:/svn.dbg/auth.wsgi
<snipped>
</Location>
...which allowed me to slip in a wsgi script to do some logging as follows:
{{{
LOG_PATH = r'd:\svn.dbg\wsgiauth.log'
def check_password(environ, user, password):
if user == 'svntest':
ofs = open(LOG_PATH, 'a')
ofs.write('%s : %s [%s]\n' % (dt.now(), user, password))
ofs.close()
if password == 'secret':
return True
return False
return None
}}}
...before passing other credentials through (unlogged!) to LDAP as normal.
What can I do next? Is this an apache configuration issue or really something
in subversion? It only manifests itself when using the subversion client
(either TortoiseSVN or command line).
~ mark c
Svn command line version info (using alagazam latest):
D:\TEMP>svn --version
svn, version 1.7.4 (r1295709)
compiled Mar 8 2012, 18:47:27
Copyright (C) 2012 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
