Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-17717

Plugin should use authentication from settings.xml

    XMLWordPrintable

Details

    Description

      As far as I can see, authentication for Nexus repository can only be given with url based authentication (http://user:pw@url).

      It would be more useful to take the authentication from already configured repositories instead (settings.xml).

      If Nexus is configured without anonymous access, the plugin returns 401.

      Attachments

        Activity

          oliver_2013 Oliver Fabry created issue -
          oliver_2013 Oliver Fabry made changes -
          Field Original Value New Value
          Description The plugin should use the authentication information already configured within the settings.xml.
          If Nexus does not allow anonymous access, the plugin will not find any artifacts and return 401 instead. Use of url-authentication is not an option.
          As far as I can see, authentication for Nexus repository can only be given with url based authentication (http://user:pw@url).

          It would be more useful to take the authentication from already configured repositories instead (settings.xml).

          If Nexus is configured without anonymous access, the plugin returns 401.
          oliver_2013 Oliver Fabry added a comment - - edited

          There is as strange behavior in this plugin: I used the plugin within a maven build job to present available nexus artifacts.
          From the beginning, there is no artifact version presented - empty list, I see 401 errors in the log file instead.
          If I click on "build" with this empty list, nothing happens - but suprisingly on the next try to build the project: the list is filled with the artifacts??

          oliver_2013 Oliver Fabry added a comment - - edited There is as strange behavior in this plugin: I used the plugin within a maven build job to present available nexus artifacts. From the beginning, there is no artifact version presented - empty list, I see 401 errors in the log file instead. If I click on "build" with this empty list, nothing happens - but suprisingly on the next try to build the project: the list is filled with the artifacts??
          gesh Gesh Markov added a comment -

          yes, the reason for this is that this plugin doesn't run a maven reactor, but rather follows the maven conventions to read artifact information from a maven repository (http://docs.codehaus.org/display/MAVEN/Repository+Metadata). It knows nothing of pom.xml and settings.xml and other maven things.

          The reason I built the plugin in the first place was to avoid bootstrapping the heavy maven just to find a couple of strings. I use it in a lot of deployment jobs which themselves don't run maven, but rather wget things for deployment or update metadata about future deployments.

          Basically all the plugin does is a single HTTP GET of the maven-metadata.xml file, parses it and presents the information inside in a dropdown (or has some simple logic to select one of those versions automatically) and does some simple string concatenations to generate a few env vars.

          It would be a lot of work for me to read and parse settings.xml files, or to integrate a maven reactor and I wouldn't want to do it anyway, because at the time I wrote this plugin there were others who already did that.

          You can try this plugin instead if you like: https://wiki.jenkins-ci.org/display/JENKINS/Maven+Repository+Client

          I myself haven't used that plugin, but it seems from the description it will do what you want.

          gesh Gesh Markov added a comment - yes, the reason for this is that this plugin doesn't run a maven reactor, but rather follows the maven conventions to read artifact information from a maven repository ( http://docs.codehaus.org/display/MAVEN/Repository+Metadata ). It knows nothing of pom.xml and settings.xml and other maven things. The reason I built the plugin in the first place was to avoid bootstrapping the heavy maven just to find a couple of strings. I use it in a lot of deployment jobs which themselves don't run maven, but rather wget things for deployment or update metadata about future deployments. Basically all the plugin does is a single HTTP GET of the maven-metadata.xml file, parses it and presents the information inside in a dropdown (or has some simple logic to select one of those versions automatically) and does some simple string concatenations to generate a few env vars. It would be a lot of work for me to read and parse settings.xml files, or to integrate a maven reactor and I wouldn't want to do it anyway, because at the time I wrote this plugin there were others who already did that. You can try this plugin instead if you like: https://wiki.jenkins-ci.org/display/JENKINS/Maven+Repository+Client I myself haven't used that plugin, but it seems from the description it will do what you want.
          oliver_2013 Oliver Fabry added a comment -

          could you confirm the behavior, that after the first click on "build" with an empty list, the plugin authenticates and shows the artifacts?

          oliver_2013 Oliver Fabry added a comment - could you confirm the behavior, that after the first click on "build" with an empty list, the plugin authenticates and shows the artifacts?
          gesh Gesh Markov added a comment -

          I don't think that should happen. It should either consistently fail or consistently work.

          I assume you can read Java - here's the code that connects to your nexus:
          https://github.com/jenkinsci/maven-metadata-plugin/blob/master/src/main/lombok/eu/markov/jenkins/plugin/mvnmeta/MavenMetadataParameterDefinition.java#L196

          It is literally those 15 lines that do all the magic of getting all artifact versions from a maven repository and I don't see how they would authenticate in one job run and not in the other. I construct the Basic Auth header in there.

          gesh Gesh Markov added a comment - I don't think that should happen. It should either consistently fail or consistently work. I assume you can read Java - here's the code that connects to your nexus: https://github.com/jenkinsci/maven-metadata-plugin/blob/master/src/main/lombok/eu/markov/jenkins/plugin/mvnmeta/MavenMetadataParameterDefinition.java#L196 It is literally those 15 lines that do all the magic of getting all artifact versions from a maven repository and I don't see how they would authenticate in one job run and not in the other. I construct the Basic Auth header in there.
          gesh Gesh Markov added a comment -

          As explained in the comments above this functionality will not be added easily and will defeat the purpose of keeping this a very light-weight plugin.

          Please investigate the other available maven plugins.

          gesh Gesh Markov added a comment - As explained in the comments above this functionality will not be added easily and will defeat the purpose of keeping this a very light-weight plugin. Please investigate the other available maven plugins.
          gesh Gesh Markov made changes -
          Fix Version/s current [ 10162 ]
          Assignee Gesh Markov [ gesh ]
          Resolution Not A Defect [ 7 ]
          Status Open [ 1 ] Resolved [ 5 ]
          oliver_2013 Oliver Fabry added a comment -

          Thanks for the quick support!

          Yes, from the Java point of view, the Nexus URL will be given to the java.net.URL class 1:1. It doesn't make sense at all, that after a first click on "build" the 401 disappears and the artifacts are shown. Might it be possible, that Jenkins modifies known urls in backend?

          oliver_2013 Oliver Fabry added a comment - Thanks for the quick support! Yes, from the Java point of view, the Nexus URL will be given to the java.net.URL class 1:1. It doesn't make sense at all, that after a first click on "build" the 401 disappears and the artifacts are shown. Might it be possible, that Jenkins modifies known urls in backend?
          gesh Gesh Markov added a comment -

          I doubt that too. would be quite an invasive thing to do.

          however there is a CookieManager as of java 1.6. And even though I have never used it I believe purely from reading the javadoc that it is being used for HttpUrlConnections by default. http://docs.oracle.com/javase/6/docs/api/index.html?java/net/CookieManager.html

          Now if Jenkins somewhere else uses pure HttpUrlConnections and provides the authentication and nexus gives them a cookie back that could be reused by my connections without my implementing a single line of code, just based on the fact that all plugins run in the same JVM as jenkins and all others plugins.

          Take this as a pure speculation, based on no facts other than reading between the lines of Java's documentation.

          gesh Gesh Markov added a comment - I doubt that too. would be quite an invasive thing to do. however there is a CookieManager as of java 1.6. And even though I have never used it I believe purely from reading the javadoc that it is being used for HttpUrlConnections by default. http://docs.oracle.com/javase/6/docs/api/index.html?java/net/CookieManager.html Now if Jenkins somewhere else uses pure HttpUrlConnections and provides the authentication and nexus gives them a cookie back that could be reused by my connections without my implementing a single line of code, just based on the fact that all plugins run in the same JVM as jenkins and all others plugins. Take this as a pure speculation, based on no facts other than reading between the lines of Java's documentation.
          oliver_2013 Oliver Fabry added a comment -

          ok, thanks a lot!

          oliver_2013 Oliver Fabry added a comment - ok, thanks a lot!
          marcrohlfs Marc Rohlfs made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 148897 ] JNJira + In-Review [ 206600 ]

          People

            Unassigned Unassigned
            oliver_2013 Oliver Fabry
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: