The <string> element for the username/password entry must contain the hostname *and* the name of the basic authentication realm separated by a single space. One way to find this is to use curl:
$ curl -vk https://www.example.com/svn/repo ... < HTTP/1.1 401 Authorization Required < Date: Mon, 11 Jun 2012 16:58:23 GMT < Server: Apache/2.0.54 (Win32) DAV/2 mod_ssl/2.0.54 OpenSSL/0.9.8g SVN/1.4.6 mod_wsgi/3.1 Python/2.6.5 mod_jk/1.2.31 mod_auth_sspi/1.0.1 < WWW-Authenticate: NTLM < WWW-Authenticate: Basic realm="Subversion repositories" < Content-Length: 596 < Content-Type: text/html; charset=iso-8859-1 ... Another way is to just get Firefox to prompt you for credentials for the site; the realm name should be in the dialog. On Friday, June 8, 2012 1:49:07 PM UTC-7, Ryan wrote: > > I'm running into the same issue. Could you show an example of your final > configuration file? I'm using something very similiar to what is below, > and it's not working. > > /var/lib/jenkins/hudson.scm.SubversionSCM.xml > /var/lib/jenkins/jobs/<jobname>/subversion.credentials > > Both of the aforementioned files contain the following: > > <entry> > <string><https://www.example.com/></string> > > <hudson.scm.SubversionSCM_-DescriptorImpl_-SslClientCertificateCredential> > <certificate>cert is pasted in here</certificate> > <userName>username</userName> > <password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password> > </hudson.scm.SubversionSCM_-DescriptorImpl_- > SslClientCertificateCredential> > </entry> > <entry> > <string><https://www.example.com/></string> > <hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential> > <userName>username</userName> > <password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password> > </hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential> > </entry> > > and I get an SVNCancelException > > On Wednesday, May 2, 2012 2:34:18 PM UTC-4, Dustin Parker wrote: >> >> I did it! >> >> I looked at the files hudson.scm.SubversionSCM.xml and >> jobs/<jobname>/subversion.credentials. Both of them had, from a previous >> repository, an entry that looked like: >> >> <entry> >> <string><https://www.example.com/></string> >> <hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential> >> <userName>username</userName> >> <password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password> >> </hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential> >> </entry> >> >> and an entry that looked like: >> >> <entry> >> <string><https://www.example.com/> Subversion >> Repositories</string> >> <hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential> >> <userName>username</userName> >> <password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password> >> </hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential> >> </entry> >> >> so I gathered the former was for the *server* and the latter was for the >> *basic realm*. Even that wasn't true, this got me to realize that SVNKit >> would be *forced* to distinguish between the two: the realm isn't >> available until after the security has been negotiated, so if SVNKit is >> going to supply a password, it can only use the hostname. Then once the >> secure connection has been established, it will try to look up credentials >> in this map using the host and realm name. So I ginned up two entries: one >> with the certificate authentication and *only* the hostname, and another >> with password authentication and the host *and *realm names, just like >> above (only using certificate authentication for the first example). So >> far, crossing my fingers and toes, this seems to work! >> >> On Wednesday, May 2, 2012 10:41:14 AM UTC-7, Dustin Parker wrote: >>> >>> This issue (JENKINS-3912) is currently stalling our development effort, >>> too. I'm trying a variety of things to work around the issue. The >>> frustrating thing is that jsvn from the command line *works*, so the >>> SVN plugin is taking this functioning library and *breaking* it somehow. >>> >>> On Wednesday, July 13, 2011 5:40:50 AM UTC-7, michaelw wrote: >>>> >>>> Has this been resolved? Sorry to bring up such an old post but I have >>>> the >>>> same problem. >>>> >>>> The scenario is as follows: >>>> >>>> 1. SSL is configured on our apache server to require a client >>>> certificate - >>>> right at the front so you can't access any of the content if you don't >>>> have >>>> the client certificate. >>>> 2. The svn server is thus sitting behind the apache server - we thus use >>>> https to reach our svn server. >>>> 3. The svn server then has its own username/password resolution >>>> facilities, >>>> this is to do thing like permissions on svn folders etc. >>>> >>>> I can't get Jenkins to checkout my code. >>>> >>>> When I select the username/password option I get the following exception >>>> >>>> <wrapping exceptions removed> >>>> >>>> Caused by: java.lang.NullPointerException >>>> at >>>> org.apache.commons.io.FileUtils.openInputStream(FileUtils.java:129) >>>> at >>>> org.apache.commons.io.FileUtils.readFileToByteArray(FileUtils.java:1135) >>>> at >>>> >>>> hudson.scm.SubversionSCM$DescriptorImpl$SslClientCertificateCredential.<init>(SubversionSCM.java:1494) >>>> at >>>> >>>> hudson.scm.UserProvidedCredential$AuthenticationManagerImpl.getFirstAuthentication(UserProvidedCredential.java:205) >>>> at >>>> >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initialize(HTTPSSLKeyManager.java:319) >>>> at >>>> >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initializeNoException(HTTPSSLKeyManager.java:301) >>>> at >>>> >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.chooseClientAlias(HTTPSSLKeyManager.java:196) >>>> at >>>> >>>> sun.security.ssl.AbstractWrapper.chooseClientAlias(SSLContextImpl.java:282) >>>> at >>>> >>>> sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:629) >>>> at >>>> >>>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:228) >>>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610) >>>> at >>>> sun.security.ssl.Handshaker.process_record(Handshaker.java:546) >>>> at >>>> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:913) >>>> at >>>> >>>> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1158) >>>> at >>>> sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:652) >>>> at >>>> sun.security.ssl.AppOutputStream.write(AppOutputStream.java:78) >>>> at >>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>> at >>>> java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>> at >>>> >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.sendData(HTTPConnection.java:229) >>>> at >>>> >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:166) >>>> at >>>> >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:364) >>>> ... 59 more >>>> >>>> Almost as if it is looking for a client certificate file but as one >>>> isn't >>>> set, it cannot find one. >>>> >>>> Then if I try the other option - client certificate I get: >>>> >>>> Attempting an SSL client certificate authentcation >>>> Passing user name null and password you entered >>>> Failed to authenticate: org.tmatesoft.svn.core.SVNErrorMessage: svn: >>>> OPTIONS >>>> of /OldMutual/sandbox/trunk/maven/parent: 401 Authorization Required >>>> (https://svn.afrozaar.com) >>>> >>>> So it looks like it is getting passed the https level but being locked >>>> out >>>> by the svn authentication. >>>> >>>> The interesting thing about this scenario is that the log says "Passing >>>> username null and password you entered" - almost as if if the password >>>> was >>>> set, it would work. >>>> >>>> The .subversion config is configured correctly - so I'm not sure if it >>>> is >>>> reading this. >>>> >>>> -- >>>> View this message in context: >>>> http://jenkins.361315.n4.nabble.com/authenticating-with-certificates-username-password-tp373150p3664923.html >>>> Sent from the Jenkins users mailing list archive at Nabble.com. >>>> >>>>
