Issue connecting to VisualSVN 5.0.2 with svnkit 1.10.6

SVNKit
#1

I am trying to connect to a VisualSVN repo using SVNKit 1.10.6
I have basic and windows auth turned on in visualSVN.
I am using the jsvn and jsvn.bat method of using svnkit to make a simple testcase that eliminates my web app as the problem.

When I run on linux, I haven’t been able to find the log file output. This is consistent across all versions of svnkit that I tested, including 1.10.6. It fails to connect and seems to be trying Negotiate, even though I set the EXTRA_JVM_ARGUMENTS on line 91 of jsvn to include
-Dsvnkit.http.methods=Basic

On Windows, I get the log, and it works when I have
-Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM in the EXTRA_JVM_ARGUMENTS of jsvn.bat

My test command is
linux
./jsvn info --username user --no-auth-cache htpsslashhost/svn/TEST
windows
jsvn info --username user --no-auth-cache htpsslashhost/svn/TEST
On Linux box its not working, and I can’t find the log, even though I renamed the logging.properties.disabled to logging.properties, which worked on Windows for me.

I found this stackoverflow page from several years ago with the same issue:

It suggests to use an absolute path for the logging path, so I tried that. No change.
I also made an absolute path to the logging configuration file in the jsvn file, but that also didn’t help me get a log.

Can you verify that logging on linux is possible and help me figure out what I need to do so that I can get to the bottom of why I can’t auth with Basic as expected?

My devops server is running on Linux, so I need it to work there.

#2

I found that 1.10.7 was also released, so I also tried with that, and have the same result, I can’t connect, and I can’t find any log file on Linux.

#3

Hello Karl,
thanks for reporting this. Does it help if you edit ‘jsvn’ script to change

EXTRA_JVM_ARGUMENTS="-Djava.util.logging.config.file=\"$LOGGING_PROPERTIES_PATH\" -Dsun.io.useCanonCaches=false"

line to

EXTRA_JVM_ARGUMENTS="-Djava.util.logging.config.file=$LOGGING_PROPERTIES_PATH -Dsun.io.useCanonCaches=false"

?

Theoretically $LOGGING_PROPERTIES_PATH could contain spaces and JVM requires quotes around values with spaces. For some reason escaping didn’t work and at the moment I’m not sure how to get it right.

#4

it did indeed!
Good idea.

I will try that with the customer facing the issue and see what the logs give me.
Thanks!
Karl

#5

They were also able to gather the logs this way like I did.

The logs showed that we were getting some SSL errors in addition to what we saw in the console, so they switched to a different Java version. We are still getting the same output at console. Attached is the log file from the run with java 1.8.0.51.

It seems that it is ignoring the svnkit.http.methods parameter and connecting with Negotiate which is the first option that was in the VisualSVN server’s options, and not Basic, which we specified in the extra jvm args.
svnkit.0.log_after_java (41.8 KB)

Here is the jsvn file that they used.

jsvn (3.6 KB)

#6

Hello Karl,
thanks for information! Looks like a bug in HTTPAuthentication#sortSchemes:

public static Collection<String> sortSchemes(Collection<String> authHeaders, Collection<String> authTypes) {
        String priorities = System.getProperty(AUTH_METHODS_PROPERTY, System.getProperty(OLD_AUTH_METHODS_PROPERTY));
        final List<String> schemes = new ArrayList<String>();
        if (authTypes != null && !authTypes.isEmpty()) {
            //<--- schemes arrays gets filled from either 1) a fixed array (this could also be a bug); 2) 'http-auth-types' option of host options in ~/.subversion/servers
            schemes.addAll(authTypes);
        } else if (priorities != null && !"".equals(priorities.trim())) {
            //<--- here we take 'svnkit.http.methods' property into account to fill 'schemes' array
            for(StringTokenizer tokens = new StringTokenizer(priorities, " ,"); tokens.hasMoreTokens();) {
                String scheme = tokens.nextToken();
                if (!schemes.contains(scheme)) {
                    schemes.add(scheme);
                }
            }
        } else {
            return authHeaders;    
        }
        
        List<String> ordered = new ArrayList<String>(authHeaders);
        Collections.sort(ordered, new Comparator<String>() {
                 ... //here the comparator uses 'schemes' array to determine sorting order
        });
        return ordered;

As you see from this snippet, ~/.subversion/servers file (‘http-auth-types’ option) has priority over the JVM property, though it should rather be vice versa. I would guess, specifying the correct order in servers file could be a temporary work-around. Or unsetting ‘http-auth-types’ option.

What is strange is that we have a fixed set of ‘authTypes’ in HTTPConnection#connect (line 168):

Collection<String> authTypes = Arrays.asList("Basic", "Digest", "Negotiate", "NTLM");

What is more strange: even this fixed order has “Basic” as the first option, so if this were the source of auth types, it couldn’t make “Negotiate” higher priority.

So I would guess, your client has ‘http-auth-types’ option and the JVM property just doesn’t override it.

#7

@dmitry.pavlenko

I understood that their todo is:

modify ~/.subversion/servers
​comment the line that sets "http-auth-types "
and try it again.

Is that correct?

thanks,
Karl

#8

Yes. And if it doesn’t work, set ‘http-auth-types’ to the value according to priorities you want (Basic first).

#9

Commenting that line as you suggested did resolve the issue.
Thanks much for your support!

#10

I’ve created SVNKIT-766 for that. The fix will be included into 1.10.8.