Community
Participate
Working Groups
From user: Our Subversion server is set up to allow access via https, the user's credentials are checked against our company-wide ldap-system. The ldap is configured to lock the account after three requests with an invalid password in a row. After that the user needs to call our helpdesk to unlock his account. Very often we receive complaints from our developers that they lock their account when working with subversive. Many of our users do not want to check the "save password" checkbox. So they need to enter their passwort every day when accessing svn the first time. Mostly they enter they password when they are asked to. E.g. this can be after they started a synchronize. Though entering the correct password they are sometimes asked multiple times to enter their password. And in some cases the user account gets locked while doing this. ==1st example: One way I could reproduce such an unexpected and unwanted behaviour is the following: I checked out four projects from the same repository and modified a few files. Then I restarted MyEclipse. selected all projects and started a synchronize. As I did not check the "save password" box in my repository connection, I was asked to enter my credentials. The first time I entered an incorrect password and the credentials dialogue showed up again. At this time my account was already locked. It is not obvious for us why the account is already locked after only one false password-entry by the user! Parallel to this I was watching the server's error log to see what happened with my account information. I could see that between the call of the synchronize functionality and the occurrence of the password dialogue one invalid authentication was started with an empty password: [Wed May 19 11:29:05 2010] [warn] [client 6.207.129.113] [55319] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [Empty password not allowed][Invalid credentials] [Wed May 19 11:29:05 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch When I entered the wrong password and submitted this there were multiple authentication errors in the log. For this reason the account got locked: [Wed May 19 11:29:15 2010] [warn] [client 6.207.129.113] [51903] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [ldap_simple_bind_s() to check user credentials failed][Invalid credentials] [Wed May 19 11:29:15 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch [Wed May 19 11:29:15 2010] [warn] [client 6.207.129.113] [51903] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [ldap_simple_bind_s() to check user credentials failed][Invalid credentials] [Wed May 19 11:29:15 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch [Wed May 19 11:29:15 2010] [warn] [client 6.207.129.113] [51903] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [ldap_simple_bind_s() to check user credentials failed][Invalid credentials] [Wed May 19 11:29:15 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch [Wed May 19 11:29:15 2010] [warn] [client 6.207.129.113] [51903] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [ldap_simple_bind_s() to check user credentials failed][Invalid credentials] [Wed May 19 11:29:15 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch [Wed May 19 11:29:16 2010] [warn] [client 6.207.129.113] [51903] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [ldap_simple_bind_s() to check user credentials failed][Invalid credentials] [Wed May 19 11:29:16 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch [Wed May 19 11:29:16 2010] [warn] [client 6.207.129.113] [51903] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [ldap_simple_bind_s() to check user credentials failed][Invalid credentials] [Wed May 19 11:29:16 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch [Wed May 19 11:29:16 2010] [warn] [client 6.207.129.113] [51903] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [ldap_simple_bind_s() to check user credentials failed][Invalid credentials] [Wed May 19 11:29:16 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch Why does subversive one invalid attempt before asking the user for the password? And why does it multiple attempts with the wrong password? Shouldn't it stop right after the first attempt? I also checked the behaviour of TortoiseSVN. TortoiseSVN did only create one erroneous attempt for one wrong password input and did not start a failing request before it asked for the password the first time. ==2nd example When I try the same as described above just without entering a wrong password the behaviour is still abnormal. The password dialog itself creates once again an invalid request against the ldap with an empty password: [Wed May 19 12:30:38 2010] [warn] [client 6.207.129.113] [23937] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [Empty password not allowed][Invalid credentials] [Wed May 19 12:30:38 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch After I entered the correct passwort the synchronize finished successfully without asking me for the password again. My account did not get locked. But I can see in the error log that there have been numerous invalid requests with an empty password. [Wed May 19 12:31:06 2010] [warn] [client 6.207.129.113] [26519] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp [Empty password not allowed][Invalid credentials] [Wed May 19 12:31:06 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspEnterpriseApp": Password Mismatch [Wed May 19 12:31:06 2010] [warn] [client 6.207.129.113] [89142] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Dokumente [Empty password not allowed][Invalid credentials] [Wed May 19 12:31:06 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Dokumente": Password Mismatch [Wed May 19 12:31:06 2010] [warn] [client 6.207.129.113] [23937] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Dokumente [Empty password not allowed][Invalid credentials] [Wed May 19 12:31:06 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Dokumente": Password Mismatch [Wed May 19 12:31:07 2010] [warn] [client 6.207.129.113] [25389] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspWebStatic [Empty password not allowed][Invalid credentials] [Wed May 19 12:31:07 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspWebStatic": Password Mismatch [Wed May 19 12:31:08 2010] [warn] [client 6.207.129.113] [19570] auth_ldap authenticate: user j918090 authentication failed; URI /iapu/ksp/trunk/ksp/dev/Implementierung/KspWebApp [Empty password not allowed][Invalid credentials] [Wed May 19 12:31:08 2010] [error] [client 6.207.129.113] user j918090: authentication failure for "/iapu/ksp/trunk/ksp/dev/Implementierung/KspWebApp": Password Mismatch It seems to me that subversive has a problem storing the correct password and using it immediately. The behaviour is similar when you change your saved password to your new one. Then it again looks like the client is making multiple requests with the old password (which would be not empty in this case). Additionally it does seem that the correct password was used as well, because my account did not get disabled this time. That means that there have not been three continuous erroneous attempts.
We have few questions regarding this issue: 1. > Why does subversive one invalid attempt before asking the user for the password? When contacting SVN server Subversive uses default credentials stored for Repository Location, in your case as you don't save password, your password is empty, so your have authentication failure with empty password, but unfortunately we didn't manage to reproduce this, i.e. in our log we don't see such authentication failure. 2. > And why does it multiple attempts with the wrong password? There are several cases why it can happen. There could be problems with SVNKit, if it is the case then we'll report the problem to them. If you use SVNKit 1.5: we have a special handling in code for SVNKit 1.5: it fixes the problem with inadequate connector library behavior: "correct connector shouldn't ask for the same credentials twice for atomic operation if credentials are valid." Because of this handling there can be made several requests to SVN with the same credentials without showing prompt dialog. 3. > Though entering the correct password they are sometimes asked multiple times to enter their password. Unfortunately, we can't reproduce this problem, but we suppose that it could be caused by inadequate connector library behavior. Probably, you have svn:externals in project. Could you please provide steps to reproduce it? In order to understand what could be the source of the problem - it depends on svn connector you use, please, tell what Subversive and SVNKit versions do you use? You can find information about SVNKit in Window/Preferences/Team/SVN at SVN Connector tab, e.g. SVNKit 1.2.3 r5745. You can find versions of Subversive and SVNKit in Help/About Eclipse/Installation Details in Features tab.
From user: Default SVN Kit (SVN/1.5.6 SVNKit/1.2.3 (http://svnkit.com/) r5745) 0.7.8.I20090904-1300 >1. Why does subversive one invalid attempt before asking the user for the password? >When contacting SVN server Subversive uses default credentials stored for Repository Location, in your case as you don't save password, your password is empty, so your have authentication failure >with empty password, but unfortunately we didn't manage to reproduce this, i.e. in our log we don't see such authentication failure. You should be able to reproduce it this way: delete your cached svn-data, create a new Repository Location with entering credentials and without saving the password. Then restart Eclipse. You should be asked for your password when browsing the location. And just before that happens, your server should once be contacted with the user and without the password. Isn't there any way to save the information that there is a password required which is not saved? Something like using --no-auth-cache ? From our point of view it would even be more useful if you did not save the username as well. This way the client could at least not create a request with invalid credentials for one's user. I still have the feeling that there is something wrong with the behaviour of subversive and/or svnkit. As described earlier there are cases in which eclipse creates requests with invalid credentials (empty password) though the correct credentials have already been entered! Furthermore these requests are "mixed" with ones with correct credentials. You can see this because the result of the operation still occurrs (without any error message) and the account does not get locked. For details see the 2nd example from my first e-mail. >3. > Though entering the correct password they are sometimes asked multiple times to enter their password. Unfortunately, we can't reproduce this problem, but we suppose that it could be caused by inadequate connector library behavior. Probably, you have svn:externals in project. Could you please provide steps to reproduce it? As far as I know none of our projects uses externals. But I cannot say this for sure for every single project. At the moment I cannot reproduce this myself.
(In reply to comment #2) 1. >2. > And why does it multiple attempts with the wrong password? >There are several cases why it can happen. There could be problems with SVNKit, if it is the case then we'll report the problem to them. If you use SVNKit 1.5: we have a special handling in code for SVNKit 1.5: it fixes the problem with inadequate connector library behavior: "correct connector shouldn't ask for the same credentials twice for atomic operation if credentials are valid." Because of this handling there can be made several requests to SVN with the same credentials without showing prompt dialog. > In which subversive version did you introduce this handling? I can't determine exact version in which this handling was introduced but it exists for a long time, since Subversive migrated to eclipse.org. This handling was initially created for SVNKit connector which caused problems when working with svn:externals, e.g. checkout, update etc. And now it remained in code: if we're working with default svn connector then do our 'handling', now SVNKit 1.5 is default. I checked current Subversive status and SVNKit (1.4, 1.5 and 1.6) doesn't require any more such handling, so I'll just remove it. 2. > You should be able to reproduce it this way: delete your cached svn-data, create a new Repository Location with entering credentials and without saving the password. Then restart Eclipse. You should be asked for your password when browsing the location. And just before that happens, your server should once be contacted with the user and without the password. Isn't there any way to save the information that there is a password required which is not saved? Something like using --no-auth-cache ? From our point of view it would even be more useful if you did not save the username as well. This way the client could at least not create a request with invalid credentials for one's user. I can reproduce this problem, thanks for such detailed steps. Problem happens with SVNKit (1.5, 1.6) but not with JavaHL (1.5, 1.6). If username is also empty, then we don't have authentication failure in Apache log with SVNKit, we have failure only if user name isn't empty. Solution: don't save username too if 'Save Password' option is disabled. > Something like using --no-auth-cache ? SVNKit doesn't use auth cache. 3. > I still have the feeling that there is something wrong with the behaviour of subversive and/or svnkit. As described earlier there are cases in which eclipse creates requests with invalid credentials (empty password) though the correct credentials have already been entered! Furthermore these requests are "mixed" with ones with correct credentials. You can see this because the result of the operation still occurrs (without any error message) and the account does not get locked. For details see the 2nd example from my first e-mail. We need to investigate this problem, if possible please provide steps to reproduce it. As I understand you have following: when you got authentication prompt dialog and provide valid credentials, then after this you have auth prompt dialogs several times(despite that previously you provided valid credentials) and in Apache log you can see mixed requests with successes and failures, do I?
*** Bug 293644 has been marked as a duplicate of this bug. ***
*** Bug 272287 has been marked as a duplicate of this bug. ***
*** Bug 312771 has been marked as a duplicate of this bug. ***
As it seems it's ok now, I close the bug.
*** Bug 298861 has been marked as a duplicate of this bug. ***
*** Bug 262876 has been marked as a duplicate of this bug. ***
