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

Redirect to login page on all 404s without discover permission

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: security
    • Labels:
      None
    • Similar Issues:

      Description

      Jenkins currently supports a discover permission, which when granted to the anonymous user, means if you visit a job and you don't have permission to see it, it will redirect you to the login page. Without this, the page just 404s, as if the job didn't exist. But what if you don't want to grant anonymous discover permission? The user experience when you're not logged in and you visit a job that you know exists, eg by clicking a link in GitHub or an email, is terrible, there's not even a link to click log in on the 404 page, you have to manually edit the URL bar to go to a page that does exist, click log in, log in, then click back in your browser until you get back to the screen that you wanted to view, and then click refresh to re-request that page.

      Behaving the same way is if the job was not found is a good security practice, however returning 404 in both circumstances is not the only way to implement this security practice, in fact in my opinion it's a terrible way, given the terrible experience it yields. A better implementation would be, if the user is not logged in, redirect to the login page in both circumstances. Then, if the user does log in, the user can be redirected back to the page they tried to access, and either a 404 page can be rendered (this would happen both if it didn't exist, or if the user didn't have read permission on the job), or the job can be rendered if they do have permission. This way, an anonymous user is still unable to discover the existence of a project, since the same behaviour occurs in either situation, but users clicking links from emails/github etc who aren't logged in are not frustrated by the current terrible experience.

      This I think is also a more semantic approach - if you 404 when the user doesn't have permission to view the project, you're lying to the user. If you redirect to login (effectively 401), you're saying "you're not allowed to find out whether this exists or not", which is exactly the intent, you don't have discover permission, so before you get a 404 to be told that it doesn't exist, you have to log in.

        Attachments

          Activity

          Hide
          danielbeck Daniel Beck added a comment -

          The behavior as described only applies to instances that grant Overall/Read to anonymous, right? Otherwise, there will always be a login screen, no matter what URL is accessed.

          And here's the problem – anonymous with some permissions is a legitimate user, so needs to be treated as such – which includes denying existence of resources that account isn't allowed to view. In fact, there's no way for Jenkins to know whether any given URL would be valid without trying to access it as as SYSTEM. Which could have side effects.

          In fact, I'm sure that the Discover permission exists exactly to prevent the problem you're describing. (There's no point in granting non-anonymous users Discover permission that I'm aware of.) And if you don't want to do that, then you get the denial of existence.

          Would a custom 404 response, that always offered to log in anonymous users, help? I.e. irrespective of whether the requested URL can be handled or would be 404 for every logged in user.

          Show
          danielbeck Daniel Beck added a comment - The behavior as described only applies to instances that grant Overall/Read to anonymous, right? Otherwise, there will always be a login screen, no matter what URL is accessed. And here's the problem – anonymous with some permissions is a legitimate user, so needs to be treated as such – which includes denying existence of resources that account isn't allowed to view. In fact, there's no way for Jenkins to know whether any given URL would be valid without trying to access it as as SYSTEM. Which could have side effects. In fact, I'm sure that the Discover permission exists exactly to prevent the problem you're describing. (There's no point in granting non-anonymous users Discover permission that I'm aware of.) And if you don't want to do that, then you get the denial of existence. Would a custom 404 response, that always offered to log in anonymous users, help? I.e. irrespective of whether the requested URL can be handled or would be 404 for every logged in user.
          Hide
          jroper James Roper added a comment -

          > Would a custom 404 response, that always offered to log in anonymous users, help? I.e. irrespective of whether the requested URL can be handled or would be 404 for every logged in user.

          If you reread my issue description, you'll see that's essentially what I'm proposing - show the a login page in both cases. The only difference is in the implementation detail, you're saying in both cases the response code will be 404 with a login page rendered, I'm saying in both cases the response code will be a redirect to the login page. From a user experience perspective, they're the same, and from a security perspective, neither gives out any more or less information to people that shouldn't have that information.

          Show
          jroper James Roper added a comment - > Would a custom 404 response, that always offered to log in anonymous users, help? I.e. irrespective of whether the requested URL can be handled or would be 404 for every logged in user. If you reread my issue description, you'll see that's essentially what I'm proposing - show the a login page in both cases. The only difference is in the implementation detail, you're saying in both cases the response code will be 404 with a login page rendered, I'm saying in both cases the response code will be a redirect to the login page. From a user experience perspective, they're the same, and from a security perspective, neither gives out any more or less information to people that shouldn't have that information.

            People

            • Assignee:
              Unassigned
              Reporter:
              jroper James Roper
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: