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

XMLWordPrintable

    • 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)

       

       

       

        1. image-2025-02-13-12-09-27-739.png
          image-2025-02-13-12-09-27-739.png
          16 kB
        2. image-2025-02-13-12-08-50-212.png
          image-2025-02-13-12-08-50-212.png
          5 kB
        3. image-2025-02-13-12-08-18-947.png
          image-2025-02-13-12-08-18-947.png
          3 kB
        4. image-2025-02-13-12-03-48-640.png
          image-2025-02-13-12-03-48-640.png
          22 kB
        5. image-2025-02-13-12-02-10-784.png
          image-2025-02-13-12-02-10-784.png
          22 kB
        6. image-2025-02-13-12-01-23-199.png
          image-2025-02-13-12-01-23-199.png
          21 kB
        7. image-2025-02-13-12-00-28-967.png
          image-2025-02-13-12-00-28-967.png
          14 kB

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

          Jean-Marc Desprez created issue -
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-73129 [ JENKINS-73129 ]
          Pedro Bueno made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Pedro Bueno made changes -
          Status Original: In Progress [ 3 ] New: Open [ 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.
          Emilio Escobar made changes -
          Remote Link New: This issue links to "Jetty issue #12809 (Web Link)" [ 30545 ]

          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).

          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 made changes -
          Assignee New: rsandell [ rsandell ]
          rsandell made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          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?

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

              Created:
              Updated: