Automatic Issue Assignment / "blame" : SVN Plugin : authentication supported (automatically) ?

[Alix Lourme]

Hi,

Using a fresh and uptodate SonarQube installation (v5.4, SVN SCM Provider v1.3), I have a "blame problem" on issue assign mechanism about user authentication on Subversion (v1.8.15).
(Some "blame problems" are related on this forum (here, here), but seems not have the same root cause).

The documentation plugin says : "Auto-detection will works if there is a .svn folder in the project root directory"

This is also true for user credentials ? Or these should be provided by another way (properties in command line or UI, internal SonarQube plugin, ...) ?

Log for info if it  could be a bug :

[...]
[INFO] --- sonar-maven-plugin:3.0.1:sonar (default-cli) @ my-test ---
[...]
[INFO] 0/3 files analyzed
[WARNING] Missing blame information for the following files:
[WARNING]   * C:/workspace_452/my-test/src/main/java/com/company/HttpTestClient.java
[WARNING]   * C:/workspace_452/my-test/src/test/java/com/company/HttpTestClientTest.java
[WARNING]   * C:/workspace_452/my-test/src/main/java/com/company/CommandLineHelper.java
[WARNING] This may lead to missing/broken features in SonarQube
[INFO] Analysis report generated in C:\workspace_452\my-test\target\sonar\batch-report
[...]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12.447 s
[INFO] Finished at: 2016-04-05T15:22:23+02:00
[INFO] Final Memory: 61M/339M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.0.1:sonar (default-cli) on project my-test: Error when executing blame for file src/main/java/com/company/CommandLineHelper.java: svn: E170001: Authentication required for '[Subversion 401 message]' -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.0.1:sonar (default-cli) on project my-test: Error when executing blame for file src/main/java/com/company/CommandLineHelper.java
[...]
Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: Authentication required for '[Subversion 401 message]'
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47)
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41)
    at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:203)
    at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:716)
    at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:398)
    at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:386)
    at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:863)
    at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:699)
    at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118)
    at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049)
    at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.hasCapability(DAVRepository.java:877)
    at org.tmatesoft.svn.core.io.SVNRepository.assertServerIsMergeInfoCapable(SVNRepository.java:787)
    at org.tmatesoft.svn.core.io.SVNRepository.getFileRevisions(SVNRepository.java:756)
    at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteAnnotate.run(SvnRemoteAnnotate.java:111)
    at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteAnnotate.run(SvnRemoteAnnotate.java:35)
    at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
    at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
    at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
    at org.tmatesoft.svn.core.wc.SVNLogClient.doAnnotate(SVNLogClient.java:295)
    at org.sonar.plugins.scm.svn.SvnBlameCommand.blame(SvnBlameCommand.java:100)
[...]

Available for any complement or some test/work if this is a bug.
Best regards.

[nicolas...@sonarsource.com]

Hello,

Auto-detection refers to the detection of SVN as the SCM. For authentication, as per the same plugin documentation you referred to: sonar.svn.username and sonar.svn.password.secured could come in handy.

Best regards,

Nicolas

...

[Alix Lourme]

Hi Nicolas,

Thanks for precision ; the analysis works ("fortunately") fine if the sonar.svn.username & sonar.svn.password.secured properties are filled.

I understand that the SVN plugin doesn't deal itself with :

%APPDATA%/Subversion/auth

It could have been very useful (if technically possible) !

Best regards.

[Julien HENRY]

Hi Alix,

The SVNKit library is supposed to be able to read credentials from SVN storage. But I just found in documentation:

On Windows machines name\password credentials are often stored encrypted. Unfortunately, SVNKit is not able to decrypt such credentials, therefore they are not used (just skipped).

http://wiki.svnkit.com/Authentication

Is it your case?

++

Julien

[Alix Lourme]

Hi,

Sorry for the delay of reply ...

The problem could be reproduced with a simple snippet using SVNKit doAnnotate (on v1.8.11) :

SVNClientManager clientManager = SVNClientManager.newInstance(SVNWCUtil.createDefaultOptions(true), SVNWCUtil.createDefaultAuthenticationManager());
clientManager.getLogClient().doAnnotate(new File(directory, "pom.xml"), SVNRevision.UNDEFINED, SVNRevision.create(1), SVNRevision.BASE, true, true, null, null);

Going into SVNKit by debug, I can see the chosen login/password, it is "in clear" during the call of HTTPConnection:myChallengeCredentials.setCredentials ... but this is not the good user/password !
The chosen are some of another repository (on the same server) ... not the one defined by the File in first argument of doAnnotate.
=> Perhaps a SVNKit bug ... I will try to investigate more.

Best regards.

[Alix Lourme]

Hi,

After investigation, this is not a SVNKit problem.
It comes from (potentially) the Subversion server configuration.
The credentials caching uses host+port+realm for hash (cf. doc)
=> If you have the same AuthName value (used as realm) for all repositories in Apache Location, the correct credentials could not be retrieved.

Some subversion config update & tests are coming soon, I will say if it fixes this problem.

Best regards.

[Alix Lourme]

Hi,

After realm update in apache configuration, it works perfectly ... on Windows.
But if you are using a CI platform who does not store the Subversion password when agent pool used on Linux (=> ~/.subversion/auth/svn.simple/ empty) ... back to the start : you should fill user/password.

I hope this tips could help in some case.
Sorry for inconvenience.
Best regards.

[Julien HENRY]

Thanks Alix for the feedback!

[Alix Lourme]

Hi Julien,

Sorry to bother you with that ... but for avoiding users to fill user/passwords (already in project context, like encrypted in pom, ...), I'm trying to fill dynamically the properties using SonarQube plugin : ProjectBuilder.

But in the SVN plugin, the user/password retrieved are always null in SvnBlameCommand.getClientManager ... seems not in settings (variable value is trunkated in Eclipse quick view) used in SvnConfiguration constructor.

In remote debug, I had verified that this code is call before the SvnConfiguration initialization:

public class ProvideMavenScmSvnCredentialsExtension extends ProjectBuilder {
    @Override
    public void build(Context context) {
                String scmUser = ...
                String scmPassword = ...

                // Fill credentials in root
                context.projectReactor().getRoot().setProperty("sonar.svn.username", scmUser);
                context.projectReactor().getRoot().setProperty("sonar.svn.password.secured", scmPassword);
               
                // Perhaps better on all projects including modules ...
                for (ProjectDefinition p : context.projectReactor().getProjects()) {
                    p.setProperty("sonar.svn.username", scmUser);
                    p.setProperty("sonar.svn.password.secured", scmPassword);
                }
    }
}

My failing use case is on SonarQube v5.4 & SVN Plugin 1.3. This process works perfectly with SonarQube v4.5.6 & SCM Activity Plugin v1.8 (one set on root ; keys was logically sonar.scm.user.secured/sonar.scm.password.secured).

I'm bad about how setting a property in SonarQube v5 plugins or perhaps the SVN plugin is more restrictive about that ?

When I check the result content in remote debug, the content of a property (in a module) setted in command line is :

com.company.foo:bar-java-module.sonar.svn.username=myLogin

=> It should be managed or the module prefix key is managed internally by SonarQube ?

Many thanks.
Best regards.

[Alix Lourme]

Hi idiot Alix (I'm talking to myself),

If you analyse the sonar-plugin-api classes, you can remark than the properties of ProjectDefinition are local to the context (ok it seems a change between v4.5 and a v5.x) ...

So if you want update the settings, update the sttings :

public class MyExtension extends ProjectBuilder {

    private Settings settings;

    public MyExtension(Settings settings) {
        this.settings = settings;

    }

    @Override
    public void build(Context context) {

        this.settings.setProperty("sonar.svn.username", "myUser");
        this.settings.setProperty("sonar.svn.password.secured", "myPassword");
    }

}

The simple way is ever the best ! (hummm...)
Good afternoon !
Best regards.