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

Try to access to a private URL returns a 404 instead of a 401

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • hudson 1.387 + Apache/modjk

      This problem exists for a very long time and even if it isn't blocker it is annoying.
      You can easily reproduce it by creating a job in an hudson instance (using the security matrix) and you don't give access to it to anonymous.
      Logout and try to access to the project URL

      This is annoying because teams are receiving emails from hudson saying to have a look at the url of the build failure and they are faced to a 404 ...

      A 501 error (with the login page ?) should be really better in term of ergonomics

          [JENKINS-8214] Try to access to a private URL returns a 404 instead of a 401

          Arnaud Héritier created issue -

          I think the conflicting school of thought here is that if it returns 401, it reveals the information that the project exists, which is a problem for some people.

          Perhaps 404 page should suggest a login?

          Or we can always add a system property that secretly controls the behaviour...

          Kohsuke Kawaguchi added a comment - I think the conflicting school of thought here is that if it returns 401, it reveals the information that the project exists, which is a problem for some people. Perhaps 404 page should suggest a login? Or we can always add a system property that secretly controls the behaviour...

          I agree about the conflict of point of view.
          Even if it's weird to have a login in the 404 it could help if we explain to our users the behavior.
          A parameter (hudson config or system property) to control the behavior is the best solution.
          Even if I understand the 404 solution, my Hudson server isn't part of Secret US Embassy resources ( ) thus I prefer to provide an ergonomics solution (401+login page) to my users

          Arnaud Héritier added a comment - I agree about the conflict of point of view. Even if it's weird to have a login in the 404 it could help if we explain to our users the behavior. A parameter (hudson config or system property) to control the behavior is the best solution. Even if I understand the 404 solution, my Hudson server isn't part of Secret US Embassy resources ( ) thus I prefer to provide an ergonomics solution (401+login page) to my users

          Harry G. added a comment -

          My practical experience is also rather annoying, because users regularly complain that they got an invalid URL via E-Mail.

          I would not display any http status at all in these cases.
          My proposal:

          • not logged in: display a message like "You need to log in" together with the login fields and redirect afterwards
          • logged in: display a message like "You have no access to this page"
            This is IMHO how many other webapps do it.

          Harry G. added a comment - My practical experience is also rather annoying, because users regularly complain that they got an invalid URL via E-Mail. I would not display any http status at all in these cases. My proposal: not logged in: display a message like "You need to log in" together with the login fields and redirect afterwards logged in: display a message like "You have no access to this page" This is IMHO how many other webapps do it.

          Harry G. added a comment -

          Regarding Kohsukes comment
          > if it returns 401, it reveals the information that the project exists, which is a problem for some people.
          the non existing URLs should also redirect to the loghin page, so that nothing will be revealed.

          If this is still not a feasable solution for all users, a config checkbox like "redirect invalid URLs to login page when not logged in" could help.

          Harry G. added a comment - Regarding Kohsukes comment > if it returns 401, it reveals the information that the project exists, which is a problem for some people. the non existing URLs should also redirect to the loghin page, so that nothing will be revealed. If this is still not a feasable solution for all users, a config checkbox like "redirect invalid URLs to login page when not logged in" could help.

          cforce added a comment -

          cforce added a comment - https://issues.jenkins-ci.org/browse/JENKINS-8930?focusedCommentId=148959#comment-148959 is a dupe

          cforce added a comment - - edited

          If i access uri on jenkins beyond vase url, eg https://bhaus.gruppe.de/jenkins/job/MyJOB/ i get HTTP 404 .
          If i call https://bhaus.gruppe.de/jenkins/ and authenficate with user /pwd ( in my case project matrix against ldap realm) and the call https://bhaus.gruppe.de/jenkins/job/MyJOB/ it works!

          My esceptation would be that if not authenficated the user get redirected to login mask and the redirectd to entered url after successfull authefication.
          I think its a War file web.xml. configuration issue.

          This behaviour is very annoying, esepcially we use a redmine plugin for jenkins which states link in the issue tracker, which beeing clicked lead to 404 because use isn't authorized the first time in the browser session.
          We have no SSO although redmine and jenkins are both backed by ldap server, a new login is needed per session.

          This problems is old now and again i vote to fix this very soon.
          Tx for contribution and help!

          cforce added a comment - - edited If i access uri on jenkins beyond vase url, eg https://bhaus.gruppe.de/jenkins/job/MyJOB/ i get HTTP 404 . If i call https://bhaus.gruppe.de/jenkins/ and authenficate with user /pwd ( in my case project matrix against ldap realm) and the call https://bhaus.gruppe.de/jenkins/job/MyJOB/ it works! My esceptation would be that if not authenficated the user get redirected to login mask and the redirectd to entered url after successfull authefication. I think its a War file web.xml. configuration issue. This behaviour is very annoying, esepcially we use a redmine plugin for jenkins which states link in the issue tracker, which beeing clicked lead to 404 because use isn't authorized the first time in the browser session. We have no SSO although redmine and jenkins are both backed by ldap server, a new login is needed per session. This problems is old now and again i vote to fix this very soon. Tx for contribution and help!
          OHTAKE Tomohiro made changes -
          Link New: This issue is related to JENKINS-4740 [ JENKINS-4740 ]
          Andrew Bayer made changes -
          Link New: This issue is duplicated by JENKINS-10869 [ JENKINS-10869 ]

          I think this is still an outstanding issue. Not sure if it's just a web.xml issue - you can specify a error handler for 404's but that won't solve the issue of not being able to get to the job in question. The login handler will likely need to be modified to accept redirecting to the job url in the email.

          Youssuf ElKalay added a comment - I think this is still an outstanding issue. Not sure if it's just a web.xml issue - you can specify a error handler for 404's but that won't solve the issue of not being able to get to the job in question. The login handler will likely need to be modified to accept redirecting to the job url in the email.

            Unassigned Unassigned
            aheritier Arnaud Héritier
            Votes:
            9 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: