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

infinite redirect loop when proxying with security enabled

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • core
    • None
    • ubuntu 10.04, apache 2.2, hudson 1.372, 1.373

      Hi,

      Given all available tutorials, I've easily succeeded in configuring an apache proxy as a front end to our standalone hudson installation (btw, thanks for the debian package). I've used 2 approaches: mod_proxy/http and mod_jk/ajp13.
      So, we have:
      https://gateway.company.com/hudson ----> http://server.company.local:8042/hudson
      or
      https://gateway.company.com/hudson ----> ajp://server.company.local:8009/hudson
      Both work, with same (good) results.

      Now I have to pass (valid) apache credentials to hudson so that it can honor the "Project-based Matrix Authorization Strategy". So, I've chosen "Delegate to servlet container" as Security Realm.

      It starts well: (please see attached winstone.log)
      1. https://gateway.company.com/hudson/manage is transparently redirected to http://server.company.local:8042/hudson/manage
      2. j_username and j_password are passed to Winstone. (clear text)
      3. "Passed authentication check"
      4. "Response: HTTP/1.1 302 Found"
      5. redirection to "/hudson/secured?"
      6. https://gateway.company.com/hudson/secured is transparently redirected to http://server.company.local:8042/hudson/secured
      7. goto 2.
      ... after a few loops, my browser (Firefox) complaints that "The page isn't redirecting properly" with "This problem can sometimes be caused by disabling or refusing to accept cookies".

      A few ideas:
      1. Should I/how to instruct apache that the security negotiation shouldn't be visible from the client side?
      2. Is there a problem around then /j_security_check mechanism? Especially, why is there "Header: Location: /hudson/secured?" instead of "Header: Location: /hudson/secured/manage"? hudson.security.BasicAuthenticationFilter doc says "/abc/def -> /secured/abc/def -> /abc/def".
      3. As Firefox suggests, is there something wrong with cookies?

      Best regards,
      Régis

          [JENKINS-7278] infinite redirect loop when proxying with security enabled

          Régis Desgroppes created issue -
          Régis Desgroppes made changes -
          Description Original: Hi,

          Given all available tutorials, I've easily succeeded in configuring an apache proxy as a front end to our standalone hudson installation (btw, thanks for the debian package). I've used 2 approaches: mod_proxy/http and mod_jk/ajp13.
          So, we have:
              https://gateway.company.com/hudson ----> http://server.company.local:8042/hudson
          or
              https://gateway.company.com/hudson ----> ajp://server.company.local:8009/hudson
          Both work, with same (good) results.

          Now I have to pass (valid) apache credentials to hudson so that it can honor the "Project-based Matrix Authorization Strategy". So, I've chosen "Delegate to servlet container" as Security Realm.

          It starts well: (please see attached winstone.log)
          1. https://gateway.company.com/hudson/manage is transparently redirected to http://server.company.com/hudson/manage
          2. j_username and j_password are passed to Winstone. (clear text)
          3. "Passed authentication check"
          4. "Response: HTTP/1.1 302 Found"
          ... then my browser (Firefox) cries that "The page isn't redirecting properly" with "This problem can sometimes be caused by disabling or refusing to accept cookies".

          A few ideas:
          1. Should I/how to instruct apache that the security negotiation shouldn't be visible from the client side?
          2. Is there a problem around then /j_security_check mechanism? Especially, why is there "Header: Location: /hudson/secured?" instead of "Header: Location: /hudson/secured/manage"? hudson.security.BasicAuthenticationFilter doc says "/abc/def -> /secured/abc/def -> /abc/def".
          3. As Firefox suggests, is there something wrong with cookies?

          Best regards,
          Régis
          New: Hi,

          Given all available tutorials, I've easily succeeded in configuring an apache proxy as a front end to our standalone hudson installation (btw, thanks for the debian package). I've used 2 approaches: mod_proxy/http and mod_jk/ajp13.
          So, we have:
              https://gateway.company.com/hudson ----> http://server.company.local:8042/hudson
          or
              https://gateway.company.com/hudson ----> ajp://server.company.local:8009/hudson
          Both work, with same (good) results.

          Now I have to pass (valid) apache credentials to hudson so that it can honor the "Project-based Matrix Authorization Strategy". So, I've chosen "Delegate to servlet container" as Security Realm.

          It starts well: (please see attached winstone.log)
          1. https://gateway.company.com/hudson/manage is transparently redirected to http://server.company.local:8042/hudson/manage
          2. j_username and j_password are passed to Winstone. (clear text)
          3. "Passed authentication check"
          4. "Response: HTTP/1.1 302 Found"
          5. redirection to "/hudson/secured?"
          6. https://gateway.company.com/hudson/secured is transparently redirected to http://server.company.local:8042/hudson/secured
          7. goto 2.
          ... after a few loops, my browser (Firefox) complaints that "The page isn't redirecting properly" with "This problem can sometimes be caused by disabling or refusing to accept cookies".

          A few ideas:
          1. Should I/how to instruct apache that the security negotiation shouldn't be visible from the client side?
          2. Is there a problem around then /j_security_check mechanism? Especially, why is there "Header: Location: /hudson/secured?" instead of "Header: Location: /hudson/secured/manage"? hudson.security.BasicAuthenticationFilter doc says "/abc/def -> /secured/abc/def -> /abc/def".
          3. As Firefox suggests, is there something wrong with cookies?

          Best regards,
          Régis
          Régis Desgroppes made changes -
          Link New: This issue depends on JENKINS-6738 [ JENKINS-6738 ]
          Kohsuke Kawaguchi made changes -
          Component/s Original: infrastructure [ 15687 ]

          Obsolete.

          Régis Desgroppes added a comment - Obsolete.
          Régis Desgroppes made changes -
          Resolution New: Won't Fix [ 2 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          Régis Desgroppes made changes -
          Status Original: Resolved [ 5 ] New: Closed [ 6 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 137377 ] New: JNJira + In-Review [ 204479 ]

            Unassigned Unassigned
            rdesgroppes Régis Desgroppes
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: