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

User pages for users with '\' in the user name fail after upgrading to 2.479.1

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core
    • None

      Note that this ticket is somehow related to JENKINS-73129

      How to reproduce

      Given a Jenkins configured to use LDAP as Security Realm.

      Given a user with a `\` in the username.

      What is the behavior

      The user is allowed to sign-in:


      But the user page gives this error:

      And the drop down menu is broken

      What is the expected behavior

      Here is the expected behavior (Jenkins 2.461)

       

       

       

          [JENKINS-75278] User pages for users with '\' in the user name fail after upgrading to 2.479.1

          Basil Crow added a comment -

          We consistently use UriCompliance.LEGACY in

          jenkins-test-harness/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java:        config.setUriCompliance(UriCompliance.LEGACY);
          jenkins-test-harness/src/main/java/org/jvnet/hudson/test/JenkinsRule.java:        config.setUriCompliance(UriCompliance.LEGACY);
          maven-hpi-plugin/src/main/java/org/jenkinsci/maven/plugins/hpi/RunMojo.java:        hc.setUriCompliance(UriCompliance.LEGACY);
          stapler/core/src/test/java/org/kohsuke/stapler/test/JettyTestCase.java:        hc.setUriCompliance(UriCompliance.LEGACY);
          winstone/src/main/java/winstone/Http2ConnectorFactory.java:            https_config.setUriCompliance(UriCompliance.LEGACY);
          winstone/src/main/java/winstone/ServerConnectorBuilder.java:        hc.setUriCompliance(UriCompliance.LEGACY);
          

          which is documented as follows:

          LEGACY compliance mode that models Jetty-9.4 behavior

          Yet this compliance mode contains https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/http/UriCompliance.Violation.html#SUSPICIOUS_PATH_CHARACTERS as described in https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0.html#uri-path-canonicalization which does not actually model legacy Jetty behavior (as claimed in the documentation); rather, the behavior is more strict than the legacy Jetty behavior. Suggest reporting this issue to the Jetty developers.

          Basil Crow added a comment - We consistently use UriCompliance.LEGACY in jenkins-test-harness/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java: config.setUriCompliance(UriCompliance.LEGACY); jenkins-test-harness/src/main/java/org/jvnet/hudson/test/JenkinsRule.java: config.setUriCompliance(UriCompliance.LEGACY); maven-hpi-plugin/src/main/java/org/jenkinsci/maven/plugins/hpi/RunMojo.java: hc.setUriCompliance(UriCompliance.LEGACY); stapler/core/src/test/java/org/kohsuke/stapler/test/JettyTestCase.java: hc.setUriCompliance(UriCompliance.LEGACY); winstone/src/main/java/winstone/Http2ConnectorFactory.java: https_config.setUriCompliance(UriCompliance.LEGACY); winstone/src/main/java/winstone/ServerConnectorBuilder.java: hc.setUriCompliance(UriCompliance.LEGACY); which is documented as follows: LEGACY compliance mode that models Jetty-9.4 behavior Yet this compliance mode contains https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/http/UriCompliance.Violation.html#SUSPICIOUS_PATH_CHARACTERS as described in https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0.html#uri-path-canonicalization which does not actually model legacy Jetty behavior (as claimed in the documentation); rather, the behavior is more strict than the legacy Jetty behavior. Suggest reporting this issue to the Jetty developers.

          Basil Crow added a comment -

          Basil Crow added a comment - Pending https://github.com/jetty/jetty.project/issues/12809 suggest replacing the occurrences of UriCompliance.LEGACY mentioned above with UriCompliance.LEGACY.with("custom", UriCompliance.Violation.SUSPICIOUS_PATH_CHARACTERS) as in https://github.com/jetty/jetty-examples/blob/ff76268f75d7cc39945b0bf97059381bb5f27cc9/embedded/ee10-servlet-ambiguous-paths/src/main/java/examples/EmbedMe.java#L38 (and adding setDecodeAmbiguousURIs(true) as in https://github.com/jetty/jetty-examples/blob/ff76268f75d7cc39945b0bf97059381bb5f27cc9/embedded/ee10-servlet-ambiguous-paths/src/main/java/examples/EmbedMe.java#L49 ).

          rsandell added a comment -

          Hmm

          setDecodeAmbiguousURIs(true) seems to only be available in jetty servlet ee10 while winstone seems to be using ee9?

          rsandell added a comment - Hmm setDecodeAmbiguousURIs(true) seems to only be available in jetty servlet ee10 while winstone seems to be using ee9?

          Basil Crow added a comment -

          Yeah, the call to setDecodeAmbiguousURIs can simple be omitted on EE 9, or perhaps included commented-out with a comment to uncomment it when we migrate from EE 9 to EE 10. I've already prototyped that migration and plan to work on it more in the coming weeks (right now I need to reimplement WebSocket, which isn't working at all on EE 10).

          Basil Crow added a comment - Yeah, the call to setDecodeAmbiguousURIs can simple be omitted on EE 9, or perhaps included commented-out with a comment to uncomment it when we migrate from EE 9 to EE 10. I've already prototyped that migration and plan to work on it more in the coming weeks (right now I need to reimplement WebSocket, which isn't working at all on EE 10).

            rsandell rsandell
            jmdesprez Jean-Marc Desprez
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: