When using the command line/terminal svn client, a colleague is getting “svn: OPTIONS of ” [repo] “…authorization failed” error message when they attempt to checkout the repo to be their local working copy.
They used to be able to do this but have recently had to change their password (periodic routine security policy). And it stopped working. NOTE: The svn check command does ask for a password everytime (which they supply – i.e. their new one.)
BUT strangely they have no problem with Tortoise SVN, it works on that. They supply their usual login and new password and it works.
Our setup is a virtualised CentOS Linux machine with several Linux user accounts where development takes place and the SVN central repo is on a separate server, authentication is using our LDAP login (i.e. the same corporate login used to login to our Windows machines). We login as Linux users to our development server from our Windows machines, using standard terminal SSH tools, e.g. PuTTY or MobaXTerm or CygWin.
When I change my password I don’t get the same problem, I am able to checkout.
I have seen many questions about this error message from searching various forums on google but none have provided me with a solution as yet.
One of the solutions I found suggests to clear or remove a local cache containing authentication, in a .subversion folder, we tried this but still the same problem. Also tried checking out to another folder.
So it seems we have clean out any trace of cached passwords but yet it still rejects.
Could there be another place on our CentOS Linux machine that caches the login
What is meant by OPTIONS (could it be a setting somewhere on our development machine or on the SVN repo server?)
Could it be a HTTP Proxy cache of my colleague’s credentials stored somewhere – so we need to clear that when a password is changed?
(Mistakenly posted on superuser.com (which is about users), so closed it there and moved it here)
3
I bet Tortoise SVN is reading different configuration options than the CLI SVN. SVN can read its configuration from many different sources. I would try playing with settings like store-auth-creds in the per-user INI file or registry.
3
The root cause is most likely a character set issue. To explain, our SVN setup uses LDAP authentication meaning that the login/password we use for SVN is the same as what we use for our corporate Windows PC network account login, which popular convenient arrangement only needing one account for both. However, we usually set/update our password via the usual Windows password change (CTRL-ALT-DEL) and we believe that the ISO character set in Windows is different from that used for the SVN CLI in Linux.
Our password wouldn’t work because it contained a pound symbol which can be interpreted differently under a different character set or key mapping in Windows LDAP password changing compared to Linux LPAP SVN authentication due to mismatch in character set used. (Credit to WanDisco folk for assisting us with the investigation, in fairness we simultaneously arrived at the same conclusion while on a call, don’t work for them but use their services, I should give credit where it’s due.)
2