Maven 2 & 3
  1. Maven 2 & 3
  2. MNG-4792

Preemptive authentication doesn't work

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.1
    • Fix Version/s: 3.0.4
    • Labels:
      None
    • Environment:
      Sun Java 1.6.0_21, Windows 7
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      It seems preemptive authentication in Maven using httpclient wagon provider doesn't work. With configuration taken form [1] Maven knock to repository (tested with Artifactory 2.2.5) as anonymous user.

      <server>
      <id>repo-id</id>
      <username>user</username>
      <password>pass</password>
      <configuration>
      <wagonProvider>httpclient</wagonProvider>
      <httpConfiguration>
      <put>
      <params>
      <param>
      <name>http.authentication.preemptive</name>
      <value>%b,true</value>
      </param>
      </params>
      </put>
      </httpConfiguration>
      </configuration>
      </server>

      Confirmed by independent party also with Maven 2.2.1. I can sniff http traffic if needed.

      [1] - http://maven.apache.org/guides/mini/guide-http-settings.html

        Issue Links

          Activity

          Hide
          Tarjei Skorgenes added a comment - - edited

          Having hit the same problem as you I've come to the conclusion that there are multiple layers of problems here that hinders preemptive authentication from working:

          1) The configuration listed in [1] is never injected into the HttpMethodConfiguration-objects created by Plexus during configuration of HttpWagon. This is caused by the fact that the params-field in HttpMethodConfiguration is of type Properties and PropertiesConverter does not recognize the param-element. Replacing param with property fixes this part of the problem:

          <configuration>
            <wagonProvider>httpclient</wagonProvider>
            <httpConfiguration>
              <put>
                <params>
                  <property>
                    <name>http.authentication.preemptive</name>
                    <value>%b,true</value>
                  </property>
                </params>
              </put>
            </httpConfiguration>
          </configuration>
          

          2) Once properly configured Http Client ignores the preemptive-parameter completely. This is caused by the fact that the check for preemptive authentication in HTTP Client's HttpMethodDirector (line 158) is not performed on the PutMethod-object. The check is done one the HttpClientParams-object and this one has not been configured by HttpWagon to include any information about preemptive-auth.

          Show
          Tarjei Skorgenes added a comment - - edited Having hit the same problem as you I've come to the conclusion that there are multiple layers of problems here that hinders preemptive authentication from working: 1) The configuration listed in [1] is never injected into the HttpMethodConfiguration-objects created by Plexus during configuration of HttpWagon. This is caused by the fact that the params-field in HttpMethodConfiguration is of type Properties and PropertiesConverter does not recognize the param-element. Replacing param with property fixes this part of the problem: <configuration> <wagonProvider> httpclient </wagonProvider> <httpConfiguration> <put> <params> <property> <name> http.authentication.preemptive </name> <value> %b,true </value> </property> </params> </put> </httpConfiguration> </configuration> 2) Once properly configured Http Client ignores the preemptive-parameter completely. This is caused by the fact that the check for preemptive authentication in HTTP Client's HttpMethodDirector (line 158) is not performed on the PutMethod-object. The check is done one the HttpClientParams-object and this one has not been configured by HttpWagon to include any information about preemptive-auth.
          Hide
          Chris Tanger added a comment - - edited

          I'm also experiencing this issue with maven 2.2.1 with a Nexus server on the back. I have sniffed the http communications and the preemptive authentication configuration is indeed being ignored.

          Furthermore it appears that the expect 100-continue functionality isn't working properly either. Protocol inspection reveals that even when 100-continue is sent in the header the payload is still sent. Naturally this leads to a bad checksum computation on the server since the first request is denied with 401 since preemptive authentication doesn't work.

          Note: We are using a username and maven encrypted password in the server section of settings.xml.

          Here is an excerpt with the password altered of course.

          <server>
          <id>nexus-server</id>
          <!-- configure windows domain username and encrypted password here
          Don't forget you need to setup a settings-security.xml file too in the same
          directory for password decryption purposes.
          -->
          <username>ctanger</username>
          <!-- This may not be a valid base64 string since it was altered -->
          <password>

          {CJ9S6SY2mSAH3w5CheexecNxNxd/nqZ3Wkef1a1a5Kg=}

          </password>

          <configuration>
          <wagonProvider>httpclient</wagonProvider>
          <httpConfiguration>
          <put>
          <params>
          <param>
          <name>http.authentication.preemptive</name>
          <value>%b,true</value>
          </param>
          </params>
          </put>
          </httpConfiguration>
          </configuration>
          </server>

          Show
          Chris Tanger added a comment - - edited I'm also experiencing this issue with maven 2.2.1 with a Nexus server on the back. I have sniffed the http communications and the preemptive authentication configuration is indeed being ignored. Furthermore it appears that the expect 100-continue functionality isn't working properly either. Protocol inspection reveals that even when 100-continue is sent in the header the payload is still sent. Naturally this leads to a bad checksum computation on the server since the first request is denied with 401 since preemptive authentication doesn't work. Note: We are using a username and maven encrypted password in the server section of settings.xml. Here is an excerpt with the password altered of course. <server> <id>nexus-server</id> <!-- configure windows domain username and encrypted password here Don't forget you need to setup a settings-security.xml file too in the same directory for password decryption purposes. --> <username>ctanger</username> <!-- This may not be a valid base64 string since it was altered --> <password> {CJ9S6SY2mSAH3w5CheexecNxNxd/nqZ3Wkef1a1a5Kg=} </password> <configuration> <wagonProvider>httpclient</wagonProvider> <httpConfiguration> <put> <params> <param> <name>http.authentication.preemptive</name> <value>%b,true</value> </param> </params> </put> </httpConfiguration> </configuration> </server>
          Hide
          Olivier Lamy added a comment -

          will be fixed with a new default wagon http client in core

          Show
          Olivier Lamy added a comment - will be fixed with a new default wagon http client in core
          Hide
          Richard Eckart de Castilho added a comment -

          We hit the problem that Maven does not download files from a public Artifactory with partially private repositories as well. It turns out that disabling the option "Hide Existence of Unauthorized Resources" in the Security General Configuration of Artifactory also resolves the problem. Maven will send username and password AFTER Artifactory has first denied access.

          Show
          Richard Eckart de Castilho added a comment - We hit the problem that Maven does not download files from a public Artifactory with partially private repositories as well. It turns out that disabling the option "Hide Existence of Unauthorized Resources" in the Security General Configuration of Artifactory also resolves the problem. Maven will send username and password AFTER Artifactory has first denied access.
          Hide
          Lukasz Szelag added a comment -

          I was just wondering if there is a fix available for Maven 2.2.1. I'm facing the same issue when connecting to Archiva repository, and credentials are not passed by Maven. Thanks.

          Show
          Lukasz Szelag added a comment - I was just wondering if there is a fix available for Maven 2.2.1. I'm facing the same issue when connecting to Archiva repository, and credentials are not passed by Maven. Thanks.
          Hide
          Brett Porter added a comment -

          Lukasz - we frequently use Maven 2.2.1 to connect to private Archiva repos - feel free to ask for help on users@archiva.apache.org.

          With regard to specifically enabling pre-emptive authentication on Maven 2.2.1, I believe it is possible to use the newer httpclient wagon with Maven 2.2.1 through an <extension> element, but I haven't confirmed that.

          Show
          Brett Porter added a comment - Lukasz - we frequently use Maven 2.2.1 to connect to private Archiva repos - feel free to ask for help on users@archiva.apache.org. With regard to specifically enabling pre-emptive authentication on Maven 2.2.1, I believe it is possible to use the newer httpclient wagon with Maven 2.2.1 through an <extension> element, but I haven't confirmed that.
          Hide
          Lukasz Szelag added a comment -

          Brett, the only way for me to have Maven 2.2.1 and Archiva 1.3.5 work together, is to grant the Archiva guest user read access to my repositories. Can you provide an example showing how to configure httpclient? Thanks.

          Show
          Lukasz Szelag added a comment - Brett, the only way for me to have Maven 2.2.1 and Archiva 1.3.5 work together, is to grant the Archiva guest user read access to my repositories. Can you provide an example showing how to configure httpclient? Thanks.
          Hide
          Brett Porter added a comment -

          Lukasz, can you open an Archiva ticket with more details on that? It's certainly possible, but I don't want to fill this ticket with troubleshooting on a different project.

          Show
          Brett Porter added a comment - Lukasz, can you open an Archiva ticket with more details on that? It's certainly possible, but I don't want to fill this ticket with troubleshooting on a different project.

            People

            • Assignee:
              Olivier Lamy
              Reporter:
              Marcin Zajaczkowski
            • Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: