Hi, i have method that uses svnkit to test a connection to a SVN repository, for a specific svn url the “svnRepository.testConnection()” doesn’t gives any exception, but for a similiar other url it works perfectly fine, Need some help in understanding this behaviour which makes it work in one case and doesn’t for another, is any configuration needs to be checked in SVN repository to make sure it gives the authentication exception
sample url below, both the urls are on “svn://” protocol.
url= svn://test.servebbs.com/SVN/Test,
adding code snippet below, it takes svnUrl and a bean SVNAuthenticationBean as paramaters having username and password.
:
public boolean testSVNConnection(String svnURL,SVNAuthenticationBean sa){
SvnOperationFactory af = new SvnOperationFactory();
try {
SVNURL url;
url = SVNURL.parseURIEncoded(svnURL);
final SVNRepository svnRepository = af.getRepositoryPool().createRepository(url, true);
ISVNAuthenticationManager authManager = new BasicAuthenticationManager(sa.getSvnUsername(),sa.getSvnPassword());
svnRepository.setAuthenticationManager(authManager);
svnRepository.testConnection();
System.out.println("Connection done..");
return true;
}
catch(SVNAuthenticationException e){
System.out.println("Not connected:Authentication Failed");
return false;
}
catch (SVNException e){
System.out.println("Failed to connect");
e.printStackTrace();
return false;
}finally{
af.dispose();
}
}
Hello,
do I understand correctly that you see “Connection done…” for this test? Or do you catch some exception but of wrong kind? Catching SVNAuthenticationException may be not the most reliable thing to do, it’s better to check ‘errorCode’ field of generic SVNException.
Do you have different behaviour with native SVN client? (if command line SVN doesn’t show any error as well, it’s the SVN server that could be misconfigured)
If you don’t get any exception while native command line SVN does, it’s a weird situation and the best thing to do would be to use sniffer to find out what SVNKit as SVN client sends to SVN server and how the server responds.
I hope all this information will help us to proceed and resolve the problem.
ideal scenario:
With this code for a url say url1 i will get “Not connected:Authentication Failed” if i pass wrong credentials , with correct credentials i will get “Connection done…” which i believe is the ideal behaviour.
problem scenario:
with the same code for another url say url2 i am always getting “Connection done…” part either the credentials are correct or not.
I am also suspecting misconfiguration of the SVN server in case of url2, any specific configurations that i need to check in this specific scenario ??
Also will the behaviour of above code will be different if the svn repo is having read-all access ??
I suspected that this issue could be due to Anonymous read-only access enabled on Svn repository, so i found a workaround that involves checking the commit access, which worked and gave authentication exception on giving the wrong credentials, here is the code snippet:
ISVNEditor editor = null;
try {
editor = repos.getCommitEditor(…);
editor.openRoot(-1);
} catch (SVNAuthenticationException e) {
// userName has no write access to URL.
} catch (SVNException e) {
// another error.
} finally {
if (editor != null) {
editor.abortEdit();
}
}
I see, internally we use similar code in SVN Mirror to check for write access while using testConnection() to check for read access.
another workaround that works fine for is by forcing authentication on my authentication manager:
ISVNAuthenticationManager authManager = new BasicAuthenticationManager(sa.getSvnUsername(),sa.getSvnPassword());
((BasicAuthenticationManager) authManager).setAuthenticationForced(true);
by adding the above property (setAuthenticationForced(true)) to my authManager object it giver authentication exception on wrong credentials which is expected behaviour, with setting that property it wont give any exception.
Thanks and appreciate your help with all the info provided, it will be nice if we can consider having a “testWriteAccess()” method to check commit access for a user, similiar to existing testConnection() method which checks read access.