SVN is requesting password too often for realm

Still need help?

The Atlassian Community is here for you.

Ask the community

Problem

The following appears in atlassian-fisheye-YYYY-MM-DD.log

2015-05-31 21:27:43,800 DEBUG [SvnExecution1878 Repository] fisheye SvnPasswordSupplier-prompt - prompting for realm: <https://URL:443> Authorization Realm with username: <username>, maySave = true
2015-05-31 21:27:43,800 WARN  [SvnExecution1878 Repository] fisheye SvnPasswordSupplier-prompt - SVN is requesting password too often for realm '<https://URL:443> Authorization Realm' and user '<username>'
2015-05-31 21:27:43,801 ERROR [IncrementalPinger3 Repository] fisheye BaseRepositoryScanner-handleSlurpException - Problem processing revisions from repo Repository due to class com.cenqua.fisheye.rep.RepositoryClientException - org.tigris.subversion.javahl.ClientException: svn: E200015: authentication cancelled
com.cenqua.fisheye.rep.RepositoryClientException: org.tigris.subversion.javahl.ClientException: svn: E200015: authentication cancelled
...
Caused by: org.tigris.subversion.javahl.ClientException: svn: E200015: authentication cancelled
...
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: authentication cancelled
...

Cause

There could be several causes to this issue. Essentially, this problem occurs because Fisheye is using the credentials from the config.xml file too often. This could be caused by:

  • Subversion is configured not to save passwords in the credential cache, just saving username information
  • Fisheye is not picking up the correct credential cache or because there isn't any cache
  • Credential cache may be outdated
  • Native SVN not caching credentials  FE-5329 - Getting issue details... STATUS

A few more important notes to understand before moving on:


  • As of now, Fisheye is designed to reject credentials should it be requested too many times (or hit the maximum allowed). 
  • The authentication credentials can usually be found in:
    • Mac OS X / Linux : ~/.subversion/auth/svn.simple
    • Windows can be found either in : C:\Users\%USERNAME%\AppData\Subversion\auth\svn.simple or C:\Users\%USERNAME%\AppData\Roaming\Subversion\auth\svn.simple
  • Credentials are cached into individual files and each of the file there would be values containing the credentials for one repository. It may look something like this:

    $ ls ~/.subversion/auth/svn.simple/
    5671adf2865e267db74f09ba6f872c28
    3893ed123b39500bca8a0b382839198e
    5c3c22968347b390f349ff340196ed39
    
    $ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28
    
    K 8
    username
    V 3
    joe
    K 8
    password
    V 4
    blah
    K 15
    svn:realmstring
    V 45
    <https://svn.domain.com:443> Joe's repository
    END


  • Details about the above can be found here

Workaround

If SVN is missing those credential caches or getting outdated credentials, we need to rebuild those credential caches first:

  1. Make sure that Subversion is allowing saving passwords in the credential cache. With recent versions of Subversion (~ 1.8) you can configure password caching via .subversion/servers:

    [global]
    store-passwords = yes
    store-plaintext-passwords = no

    Note that in some environments (Unix/Linux) you may have to cache plaintext passwords:

    [global]
    store-passwords = yes
    store-plaintext-passwords = yes

    and possibly also add the following property in the auth section of ~/.subversion/config. See FE-7246

    [auth]
    password-stores =
  2. Restart Subversion / Apache service so that these changes above are applied

  3. Go to Fisheye administration panel and stop the affected repository

  4. Open up a Terminal / Command Prompt window on the server running Fisheye

    Ensure that the user who is running the Terminal / Command Prompt is the same user who is running Fisheye

  5. Navigate to the user home directory. In Unix machines that is usually /home/<username> and on Windows machines that is usually C:\Users\<username>.
  6. Search for a directory named .subversion, which may be hidden.
  7. If the directory was found, access the .subversion directory and backup the auth directory. For example:

    cp -a .subversion/auth .subversion/auth-BACK
  8. Navigate to .subversion/auth/simple.svn and look though all the cached credentials
  9. Check if the credentials used for the repository are present in the folder and, in that case, remove them
  10. Open up a new Terminal / Command Prompt window on the server running Fisheye. 

    Ensure that the user who is running the Terminal / Command Prompt is the same user who is running Fisheye

  11. Perform svn info command against the affected SVN repository in order to build the credential cache. Sample command: svn info https://URL@HEAD

    This process should require a username and password. If it is not requesting them, the SVN command was probably executed with a different user or the credential from the wrong user was deleted

    If the command does not work it may mean that Subversion and Fisheye are installed on different servers and the svn  executable is unknown or is not in the system PATH. In that case, you can either:

    1. Temporarily install a Subversion client on the server hosting Fisheye so as to run the command, then uninstall the client, or
    2. Use Fisheye's bundled SVNKit library to run the command. To do so:
      1. Navigate to <FISHEYE_INSTALLATION_DIR>\lib\svn 
      2. Make sure that jsvn  (or jsvn.bat , if on Windows) have execute permission. On Unix systems this usually means running chmod +x jsvn .
      3. Execute ./jsvn info https://URL@HEAD (or jsvn.bat info , if on Windows) instead of the regular svn info  command.
  12. Once the command finishes, there should be a new file in the simple.svn directory containing three settings: the username, the password and the svn:realmstring.
  13. Access Fisheye Administration, click the name of the affected repository, go to SCM Details >> SVN Connection Details and ensure that the username and password specified earlier when svn info was executed (Step 9) are exactly the same ones configured in Fisheye.
  14. Start the repository and the problem should no longer happen.

If there are hundreds of repositories having this problem, running svn info against each of them might mean a lot of manual work. So, this Python script comes in handy:

#!/usr/bin/python

import os
import sys
import getopt
import subprocess
import xml.etree.ElementTree

def main(argv):
    opts, args = getopt.getopt(argv,"hc:")
    for opt, arg in opts:
        if opt == "-c":
            config = arg

    print 'Using "' + config + '"'
    print 'Processing repositories:'

    root = xml.etree.ElementTree.parse(config).getroot()
    for repository in root.iter('repository'):
        svn = repository.find('svn')
        if svn is not None:
            auth = svn.find('auth')
            url = svn.get('url')
            if auth is not None:
                username = auth.get('username')
                password = auth.get('password')
                devnull = open(os.devnull, 'w')
                info = subprocess.call('svn info ' + url + '@HEAD --non-interactive --username ' + username + ' --password ' + password, shell=True, stdout=devnull, stderr=devnull)
                if info == 0:
                    print '[DONE]', url
                else:
                    print '[FAIL]', url
            else:
                print '[SKIP]', url, '(no auth)'


if __name__ == "__main__":
    main(sys.argv[1:])

This script will parse config.xml and execute svn info command against each SVN repository that has credentials defined. This should generate the files in svn.simple directory automatically, so it won't be needed to run that command manually anymore for each repository. In order to run the script:

python PATH_TO_PYTHON_SCRIPT -c PATH_TO_CONFIG_XML

If you are using Native SVN, there is a bug where Native SVN are not caching credentials. You can track it here FE-5329 - Getting issue details... STATUS . To be able the cache this credentials, simply follow "Building Credential Cache" section onwards.

Description

This page covers errors present when authentication occurs too frequently and how to resolve it.

ProductFIshEye, Crucible
Last modified on Dec 20, 2021

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.