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

Jenkins Resource Root URL not working (404) with Project-based matrix auth

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Critical Critical
    • None

      Running Jenkins on dedicated machine, with SSL provided by Haproxy.

      Jenkins runs inside internal network, with URL https://jenkins.company.com , https://jenkins-static.company.com is set up to point to the same machine.

      Haproxy settings as from jenkins tutorial (disabling haproxy and switching to direct HTTP does not solve the issue).

      When setting up Resource Root URL using "Manage Jenkins >> System", all artifacts URL are converted to https://jenkins-static.company.com/static-files/TOKEN/FILE_PATH but trying to open the link always leads to "Oops!" 404 page.

      I was unable to find any related information in the logs, but maybe I do not know where to look.

      I have no idea what might be wrong, maybe GitLab OAuth plugin results in invalid user names and then tokens?

          [JENKINS-73720] Jenkins Resource Root URL not working (404) with Project-based matrix auth

          I've found possible culprit - to make Resource URL work I had to add "Job/Read" permission to "Authenticated Users" in global settings for Project-based Matrix Authorization Strategy. But this breaks the security of my Jenkins instance, so this solution can't be applied.

          Konrad Grochowski added a comment - I've found possible culprit - to make Resource URL work I had to add "Job/Read" permission to "Authenticated Users" in global settings for Project-based Matrix Authorization Strategy. But this breaks the security of my Jenkins instance, so this solution can't be applied.

          More findings - if instead of "Job/Read" I set only "Job/Discover" I get 403 instead of 404

          Konrad Grochowski added a comment - More findings - if instead of "Job/Read" I set only "Job/Discover" I get 403 instead of 404

          Seems this was by intention (JENKINS-72636). The 2.462.3 adds a option to workaround it. Knowing the reason I could fix it by adding

             RequestHeader unset Authorization
          

          to our Apache reverse proxy config.

          Andreas Mandel added a comment - Seems this was by intention ( JENKINS-72636 ). The 2.462.3 adds a option to workaround it. Knowing the reason I could fix it by adding RequestHeader unset Authorization to our Apache reverse proxy config.

          I've tried setting jenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true 

           

          but it did not help

          I'll try with reverse proxy config

          Konrad Grochowski added a comment - I've tried setting jenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true     but it did not help I'll try with reverse proxy config

          Konrad Grochowski added a comment - - edited

          I've added

          Environment="JAVA_OPTS=-Djenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true"
          

          to Jenkins service config and

          http-request del-header Authorization if { req.hdr(Host) jenkins-static.XYZ.com }
          

          to haproxy config, but no change in the behaviour

           

          Konrad Grochowski added a comment - - edited I've added Environment="JAVA_OPTS=-Djenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true" to Jenkins service config and http-request del-header Authorization if { req.hdr(Host) jenkins-static.XYZ.com } to haproxy config, but no change in the behaviour  

          hcorg - might be you face a different issue then? Not sure if that got clear, for jenkins.security.ResourceDomainRootAction.allowAuthenticatedUse to work you need to be on Jenkins 2.462.3 (or a recent weekly)

          Andreas Mandel added a comment - hcorg - might be you face a different issue then? Not sure if that got clear, for jenkins.security.ResourceDomainRootAction.allowAuthenticatedUse to work you need to be on Jenkins 2.462.3 (or a recent weekly)

          I'm running weekly updates, so I'm on 2.479 right now.

          and to be clear:

          this is the change I need to make to Resource URL to work. But it breaks security of my instance (not everyone should even see some projects)

          Konrad Grochowski added a comment - I'm running weekly updates, so I'm on 2.479 right now. and to be clear: this is the change I need to make to Resource URL to work. But it breaks security of my instance (not everyone should even see some projects)

          Daniel Beck added a comment - - edited

          hcorg 

          It is possible that your security realm does not add groups when a thread assumes a user's identity (which is what the resource root URL code does internally). If permissions are currently granted to groups (as the screenshot indicates), try granting permissions to affected users. If that addresses the problem, file an issue about lack of support for groups in ACL#impersonate with your security realm plugin.

          Daniel Beck added a comment - - edited hcorg   It is possible that your security realm does not add groups when a thread assumes a user's identity (which is what the resource root URL code does internally). If permissions are currently granted to groups (as the screenshot indicates), try granting permissions to affected users. If that addresses the problem, file an issue about lack of support for groups in ACL#impersonate with your security realm plugin.

          danielbeck - I confirm, explicitly adding Job/Read for a user (on the given job level) allowed for access. So indeed - this seems to be a problem of GitLab OAuth plugin. I've filled JENKINS-74735, but I lack the knowledge to describe the issue in details.

          Konrad Grochowski added a comment - danielbeck - I confirm, explicitly adding Job/Read for a user (on the given job level) allowed for access. So indeed - this seems to be a problem of GitLab OAuth plugin. I've filled JENKINS-74735 , but I lack the knowledge to describe the issue in details.

          Daniel Beck added a comment -

          Closing this one then as there's no bug in matrix-auth or core.

          I also added a test in https://github.com/jenkinsci/jenkins/pull/9906 to confirm this is working in principle.

          Daniel Beck added a comment - Closing this one then as there's no bug in matrix-auth or core. I also added a test in https://github.com/jenkinsci/jenkins/pull/9906 to confirm this is working in principle.

            Unassigned Unassigned
            hcorg Konrad Grochowski
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: