Hi,
CODESYS SVN plug-in seems to be losing the authentication details occasionally. This is observed with CODESYS V3.5 SP4 patch 2 release.
The CODESYS SVN installation on our test server is configured with correct authentication details and the 'Save authentication' box enabled. It is observed that the SVN plug-in occasionally complains about the missing Subversion Authentication details and pops-up the authentication dialog which is stalling our daily automation tests. However, after some time if i open another instance of CODESYS and check out a project, it works.
Many Thanks,
Mazahar S
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-06-04
Originally created by: M.Schaber
Hi, Mazahar,
CODESYS SVN uses the standard SVN Auth cache, which resides on %APPDATA%/Subversion/auth/ on windows.
As this data is part of the Roaming profile of the windows user, it may be backed by network shares in some configurations, which may be the reason why it does not work sporadically when those network sharings are unavailable.
Another reason could be that the server temporarily refuses client logins for some reason (e. G. timeouts while trying to resolve the IP to DNS name, or a connection limit in the http server).
Right now, I don't have any other idea why it may refuse to work sometimes, and does work otherwise.
To shed some light on this, the server logs around the time of the failed access, network traces (e. G. using WireShark, limited to connections to the repository) and exception traces of CODESYS (using the "Diagnosis Tool" which is available via our support department) could help to diagnose it further.
You can also create a copy of the auth cache directory, and (after failure and re-entering of the password), make a diff to see whether anything has actually changed.
Additionally, you should make sure that the authentication data really is correct - changing the repository url or UUID, or some other configurations may change the REALM which is the key for the Auth cache - when changing them, SVN simply thinks it is a different repository, and re-asks for credentials. If you get new entries in the auth cache directory on every failure, this may indicate such problems. One use-case is if you recreate a fresh repository for every test run - the UUID will always be a different one (which is a good thing by itsself, as it invalidates caches.)
Zitat:
On Windows, the Subversion client stores passwords in the %APPDATA%/Subversion/auth/ directory. On Windows 2000 and later, the standard Windows cryptography services are used to encrypt the password on disk. Because the encryption key is managed by Windows and is tied to the user's own login credentials, only the user can decrypt the cached password. (Note that . The Subversion client will behave as though they don't exist, prompting for passwords when required.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-06-04
Originally created by: M.Schaber
Hi,
I just got another idea from the SVN developers (thanks, Bert!):
If your setup uses NTLM, and the session ticket expires, this will cause SVN 1.7 based clients (as ours) to ask for username and password, instead of requesting a new ticket. Newer SVN versions fixed this issue.
HTH,
Markus Schaber
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
CODESYS SVN plug-in seems to be losing the authentication details occasionally. This is observed with CODESYS V3.5 SP4 patch 2 release.
The CODESYS SVN installation on our test server is configured with correct authentication details and the 'Save authentication' box enabled. It is observed that the SVN plug-in occasionally complains about the missing Subversion Authentication details and pops-up the authentication dialog which is stalling our daily automation tests. However, after some time if i open another instance of CODESYS and check out a project, it works.
Many Thanks,
Mazahar S
Originally created by: M.Schaber
Hi, Mazahar,
CODESYS SVN uses the standard SVN Auth cache, which resides on %APPDATA%/Subversion/auth/ on windows.
As this data is part of the Roaming profile of the windows user, it may be backed by network shares in some configurations, which may be the reason why it does not work sporadically when those network sharings are unavailable.
Another reason could be that the server temporarily refuses client logins for some reason (e. G. timeouts while trying to resolve the IP to DNS name, or a connection limit in the http server).
Right now, I don't have any other idea why it may refuse to work sometimes, and does work otherwise.
To shed some light on this, the server logs around the time of the failed access, network traces (e. G. using WireShark, limited to connections to the repository) and exception traces of CODESYS (using the "Diagnosis Tool" which is available via our support department) could help to diagnose it further.
You can also create a copy of the auth cache directory, and (after failure and re-entering of the password), make a diff to see whether anything has actually changed.
Additionally, you should make sure that the authentication data really is correct - changing the repository url or UUID, or some other configurations may change the REALM which is the key for the Auth cache - when changing them, SVN simply thinks it is a different repository, and re-asks for credentials. If you get new entries in the auth cache directory on every failure, this may indicate such problems. One use-case is if you recreate a fresh repository for every test run - the UUID will always be a different one (which is a good thing by itsself, as it invalidates caches.)
Addendum: The SVN documentation
Originally created by: M.Schaber
Hi,
I just got another idea from the SVN developers (thanks, Bert!):
If your setup uses NTLM, and the session ticket expires, this will cause SVN 1.7 based clients (as ours) to ask for username and password, instead of requesting a new ticket. Newer SVN versions fixed this issue.
HTH,
Markus Schaber