Since upgrading from Jenkins 1.552 to 1.556 I see the following error when I attempt to login to Jenkins:

      HTTP ERROR 404
      Problem accessing /jenkins/;jsessionid=1vdumbbfrnzw1ikx0jl5mqi6q. Reason:

      Not Found

      I can successfully login by deleting the Jenkins cookie in my browser (IE9) but the problem reoccurs later.

      I am using the latest ActiveDirectory plugin.

        1. system_info.docx
          70 kB
          Pawel Grzegrzolka
        2. system_info.docx
          70 kB
          Pawel Grzegrzolka

          [JENKINS-22358] Jenkins 1.556 gives 'Error 404 Not Found'

          David Aldrich added a comment -

          Also, after I have managed to login, I cannot change view. If I select a different view I am required to login again but my credentials are refused.

          David Aldrich added a comment - Also, after I have managed to login, I cannot change view. If I select a different view I am required to login again but my credentials are refused.

          David Aldrich added a comment -

          The problem also appears in FireFox. I managed to clear it by restarting the browser.

          David Aldrich added a comment - The problem also appears in FireFox. I managed to clear it by restarting the browser.

          Cody Schafer added a comment - - edited

          I'm seeing this with Jenkins ver. 1.561 proxied like: varnish <-> nginx <-> jenkins. I'm not using active directory (probably not relevant, but I'm using the PAM auth system)

          Cody Schafer added a comment - - edited I'm seeing this with Jenkins ver. 1.561 proxied like: varnish <-> nginx <-> jenkins. I'm not using active directory (probably not relevant, but I'm using the PAM auth system)

          Daniel Beck added a comment -

          Does it happen in other browsers as well? What servlet container are you using? How does the rest of your infrastructure (see Cody's comment) look like?

          Daniel Beck added a comment - Does it happen in other browsers as well? What servlet container are you using? How does the rest of your infrastructure (see Cody's comment) look like?

          Daniel Beck added a comment -

          Ping!

          Daniel Beck added a comment - Ping!

          Daniel Beck added a comment -

          No response to comment asking for additional information in months, so resolving as Incomplete.

          Daniel Beck added a comment - No response to comment asking for additional information in months, so resolving as Incomplete.

          I have the same issue with Jenkins 1.583.
          Tried with IE 10 and Firefox (32). Both have the same issue.
          Network setup doesn't matter since the same issue occurs on the localhost.
          I'm using RoleBasedAuthorizationStrategy.

          Pawel Grzegrzolka added a comment - I have the same issue with Jenkins 1.583. Tried with IE 10 and Firefox (32). Both have the same issue. Network setup doesn't matter since the same issue occurs on the localhost. I'm using RoleBasedAuthorizationStrategy.

          I've just noticed that secured connection (SSL) doesn't have this issue. Jetty complains only when trying to connect via http.

          Pawel Grzegrzolka added a comment - I've just noticed that secured connection (SSL) doesn't have this issue. Jetty complains only when trying to connect via http.

          Daniel Beck added a comment - - edited

          What container is Jenkins running in? Could you provide the contents of the /systemInfo page of Jenkins? What is the URL the 'login' link points to, does it contain this suffix?

          Daniel Beck added a comment - - edited What container is Jenkins running in? Could you provide the contents of the /systemInfo page of Jenkins? What is the URL the 'login' link points to, does it contain this suffix?

          Pawel Grzegrzolka added a comment - - edited

          I'm using pure Jenkins service - which uses Jetty by default.
          Please find attached systeminfo.
          Login page is http://hostname:8080/login?from=%F, since 'log in' button points to the http://hostname:8080/;jsessionid=jxe4566niq5m10476zliw7ge (with a random crap at the end).

          Pawel Grzegrzolka added a comment - - edited I'm using pure Jenkins service - which uses Jetty by default. Please find attached systeminfo. Login page is http://hostname:8080/login?from=%F , since 'log in' button points to the http://hostname:8080/;jsessionid=jxe4566niq5m10476zliw7ge (with a random crap at the end).

          I also got the same issue today on ubuntu 14.04 lts

          Problem accessing /jenkins/;jsessionid=1ki1cxht216p5l2y6foppljd9. Reason:

          Not Found

          Hristo Indzhov added a comment - I also got the same issue today on ubuntu 14.04 lts Problem accessing /jenkins/;jsessionid=1ki1cxht216p5l2y6foppljd9. Reason: Not Found

          Daniel Beck added a comment -

          It's not clear what the circumstances are for this problem to occur. I'd like to investigate this, but I have no idea how to reproduce the problem.

          • Jenkins version
          • OS and version
          • How was Jenkins installed?
          • Container and version, if not using the native installer
          • What's the context path (e.g. / or /jenkins), and what's the URL that fails?
          • What's the authentication realm (where are the users coming from, Jenkins User Database, LDAP, PAM, ...)
          • What's the authorization strategy (e.g. matrix auth, logged in users can do anything, ...), and what permissions does anonymous have?
          • Which client OS and web browser (+ versions of each)?
          • What are the exact steps to reproduce this problem in a new browser session (no cookies etc.). Be as precise and exhaustive in these instructions as you can (imagine explaining it to your technologically impaired parents/grandparents/spouse).

          If you're attaching files, please keep it to PDF, RTF, or plain text.

          Daniel Beck added a comment - It's not clear what the circumstances are for this problem to occur. I'd like to investigate this, but I have no idea how to reproduce the problem. Jenkins version OS and version How was Jenkins installed? Container and version, if not using the native installer What's the context path (e.g. / or /jenkins), and what's the URL that fails? What's the authentication realm (where are the users coming from, Jenkins User Database, LDAP, PAM, ...) What's the authorization strategy (e.g. matrix auth, logged in users can do anything, ...), and what permissions does anonymous have? Which client OS and web browser (+ versions of each)? What are the exact steps to reproduce this problem in a new browser session (no cookies etc.). Be as precise and exhaustive in these instructions as you can (imagine explaining it to your technologically impaired parents/grandparents/spouse). If you're attaching files, please keep it to PDF, RTF, or plain text.

          Manni added a comment - - edited

          Ran into the same problem today. For a while, 1.583 worked ok for us, then this morning our sessions were gone and logging in again didn't work. Downgrading to 1.582 fixed this.

          Browsers used were Chrome and Opera.
          We are using the "Project-based Matrix Authorization Strategy"
          Jenkins is installed as an rpm via yum from the jenkins rpm repository.
          We are accessing jenkins via "/tools/jenkins"
          The jenkins logfiles shows absolutely nothing.

          Manni added a comment - - edited Ran into the same problem today. For a while, 1.583 worked ok for us, then this morning our sessions were gone and logging in again didn't work. Downgrading to 1.582 fixed this. Browsers used were Chrome and Opera. We are using the "Project-based Matrix Authorization Strategy" Jenkins is installed as an rpm via yum from the jenkins rpm repository. We are accessing jenkins via "/tools/jenkins" The jenkins logfiles shows absolutely nothing.

          Pawel Grzegrzolka added a comment - - edited

          Jenkins version

          1.583

          OS and version

          Windows Server 2013

          How was Jenkins installed?

          as a service

          Container and version, if not using the native installer

          native one

          What's the context path (e.g. / or /jenkins), and what's the URL that fails?

          http://hostname:8080/

          What's the authentication realm (where are the users coming from, Jenkins User Database, LDAP, PAM, ...)
          What's the authorization strategy (e.g. matrix auth, logged in users can do anything, ...), and what permissions does anonymous have?

          Matrix Authorization Strategy Plugin

          Which client OS and web browser (+ versions of each)?

          Win 7 (IE 10 and Firefox (32)) + Windows 2013;

          Pawel Grzegrzolka added a comment - - edited Jenkins version 1.583 OS and version Windows Server 2013 How was Jenkins installed? as a service Container and version, if not using the native installer native one What's the context path (e.g. / or /jenkins), and what's the URL that fails? http://hostname:8080/ What's the authentication realm (where are the users coming from, Jenkins User Database, LDAP, PAM, ...) What's the authorization strategy (e.g. matrix auth, logged in users can do anything, ...), and what permissions does anonymous have? Matrix Authorization Strategy Plugin Which client OS and web browser (+ versions of each)? Win 7 (IE 10 and Firefox (32)) + Windows 2013;

          Liam Reimers added a comment - - edited

          I'm hitting this one, too, after upgrading to 1.583.

          • Jenkins version
            1.583 (Upgraded from 1.559)
          • OS and version
            Mac OS X 10.9.2
          • How was Jenkins installed?
            From the official installer package; automatic upgrade from 1.559 via the Jenkins web UI.
          • Container and version, if not using the native installer
            Native installer
          • What's the context path (e.g. / or /jenkins), and what's the URL that fails?
            /jenkins, URL that fails is /jenkins/;jsessionid=1qfdq9lhzfvtw10h62t8khybgl (Redirected after login)
          • What's the authentication realm (where are the users coming from, Jenkins User Database, LDAP, PAM, ...)
            LDAP
          • What's the authorization strategy (e.g. matrix auth, logged in users can do anything, ...), and what permissions does anonymous have?
            Matrix; anonymous have no permissions.
          • Which client OS and web browser (+ versions of each)?
            Client OS is Mac OS X 10.9.5, using Safari 7.1
          • What are the exact steps to reproduce this problem in a new browser session (no cookies etc.). Be as precise and exhaustive in these instructions as you can (imagine explaining it to your technologically impaired parents/grandparents/spouse).
            1. Load Jenkins login page in an unauthenticated browser session
            2. Log in with valid credentials
            3. See problem

          This can be worked around by removing the ";jsessionid=1qfdq9lhzfvtw10h62t8khybg" part of the URL that hits 404 after login.

          Liam Reimers added a comment - - edited I'm hitting this one, too, after upgrading to 1.583. Jenkins version 1.583 (Upgraded from 1.559) OS and version Mac OS X 10.9.2 How was Jenkins installed? From the official installer package; automatic upgrade from 1.559 via the Jenkins web UI. Container and version, if not using the native installer Native installer What's the context path (e.g. / or /jenkins), and what's the URL that fails? /jenkins, URL that fails is /jenkins/;jsessionid=1qfdq9lhzfvtw10h62t8khybgl (Redirected after login) What's the authentication realm (where are the users coming from, Jenkins User Database, LDAP, PAM, ...) LDAP What's the authorization strategy (e.g. matrix auth, logged in users can do anything, ...), and what permissions does anonymous have? Matrix; anonymous have no permissions. Which client OS and web browser (+ versions of each)? Client OS is Mac OS X 10.9.5, using Safari 7.1 What are the exact steps to reproduce this problem in a new browser session (no cookies etc.). Be as precise and exhaustive in these instructions as you can (imagine explaining it to your technologically impaired parents/grandparents/spouse). 1. Load Jenkins login page in an unauthenticated browser session 2. Log in with valid credentials 3. See problem This can be worked around by removing the ";jsessionid=1qfdq9lhzfvtw10h62t8khybg" part of the URL that hits 404 after login.

          Daniel Beck added a comment -

          I was able to reproduce this by disabling cookies in my browser for the Jenkins host. You're not wearing tin foil hats, are you?

          Daniel Beck added a comment - I was able to reproduce this by disabling cookies in my browser for the Jenkins host. You're not wearing tin foil hats, are you?

          Liam Reimers added a comment -

          While it's interesting that disabling cookies causes the issue to produce itself, neither I nor my users are disabling cookies in the browser. This issue is real and very frustrating, and the question you posed minimizes that fact.

          Liam Reimers added a comment - While it's interesting that disabling cookies causes the issue to produce itself, neither I nor my users are disabling cookies in the browser. This issue is real and very frustrating, and the question you posed minimizes that fact.

          evernat added a comment -

          Hi liam,
          If I were you, I would appreciate Daniel's kind help and humor.

          For people still using IE as a browser, do not put invalid character in the hostname of Jenkins (underscore or space for example), otherwise cookies will not work and you will lose your hair on why.

          evernat added a comment - Hi liam , If I were you, I would appreciate Daniel's kind help and humor. For people still using IE as a browser, do not put invalid character in the hostname of Jenkins (underscore or space for example), otherwise cookies will not work and you will lose your hair on why.

          I don't yet fully understand the issue, but I don't think we ever want the session ID to show up in the URL. It's like invitation for a session hijacking attack.

          I don't know if there's any part of servlet spec that mandates such a behaviour, but if Winstone is somehow doing that, we need it to stop doing that. And hopefully that'll solve the problem?

          Kohsuke Kawaguchi added a comment - I don't yet fully understand the issue, but I don't think we ever want the session ID to show up in the URL. It's like invitation for a session hijacking attack. I don't know if there's any part of servlet spec that mandates such a behaviour, but if Winstone is somehow doing that, we need it to stop doing that. And hopefully that'll solve the problem?

          Liam Reimers added a comment -

          Please let me know if there is any additional information I can provide to help diagnose and resolve this problem.

          Liam Reimers added a comment - Please let me know if there is any additional information I can provide to help diagnose and resolve this problem.

          Discussion in Tomcat configuration under disableURLRewriting suggests that the servlet spec is mandating this behaviour. Hopefully Jetty offers an option to kill it like Tomcat does.

          Kohsuke Kawaguchi added a comment - Discussion in Tomcat configuration under disableURLRewriting suggests that the servlet spec is mandating this behaviour. Hopefully Jetty offers an option to kill it like Tomcat does.

          Kohsuke Kawaguchi added a comment - - edited

          The addition of session ID in URL happens through HttpServletResponse.encodeURL. Javadoc states that clearly. But not sure where in Jenkins we call this method.

          Kohsuke Kawaguchi added a comment - - edited The addition of session ID in URL happens through HttpServletResponse.encodeURL . Javadoc states that clearly. But not sure where in Jenkins we call this method.

          Still don't know exactly when the servlet spec does this (and who is supposed to be responsible for removing this from URL when the request is received), but when the login succeeds, it is added by AbstractProcessingFilter.successfulAuthentication() method in Acegi that's calling sendRedirect which in turns calls response.encodeRedirectURL that adds this unwanted session ID.

          Kohsuke Kawaguchi added a comment - Still don't know exactly when the servlet spec does this (and who is supposed to be responsible for removing this from URL when the request is received), but when the login succeeds, it is added by AbstractProcessingFilter.successfulAuthentication() method in Acegi that's calling sendRedirect which in turns calls response.encodeRedirectURL that adds this unwanted session ID.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          src/java/winstone/HostConfiguration.java
          http://jenkins-ci.org/commit/winstone/3caa3efc843785d73c66bcb203240708afb587bb
          Log:
          JENKINS-22358

          Do not put session ID in the URL, which is like asking for the session
          hijacking attack.

          While it is unclear how JENKINS-22358 happens when several reporters
          claim they have not disabled cookies, the failure mode clearly indicates
          the session ID is added to the URL, so disabling that altogether at the
          container level should resolve the problem.

          With this change, if the cookie is not enabled, a login will succeed
          but one can never login, because as soon as the user logs in, the
          browser promptly forgets that session and will appear as a new user.

          In the future perhaps it would be desirable to detect the browser that
          doesn't support cookie, and warn the user accordingly.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/java/winstone/HostConfiguration.java http://jenkins-ci.org/commit/winstone/3caa3efc843785d73c66bcb203240708afb587bb Log: JENKINS-22358 Do not put session ID in the URL, which is like asking for the session hijacking attack. While it is unclear how JENKINS-22358 happens when several reporters claim they have not disabled cookies, the failure mode clearly indicates the session ID is added to the URL, so disabling that altogether at the container level should resolve the problem. With this change, if the cookie is not enabled, a login will succeed but one can never login, because as soon as the user logs in, the browser promptly forgets that session and will appear as a new user. In the future perhaps it would be desirable to detect the browser that doesn't support cookie, and warn the user accordingly.

          Manni added a comment -

          I have a feeling that this is triggered when the jenkins url contains a port number.

          I just tried accessing my jenkins instance through a SSH tunnel (something that used to work until we upgraded to 1.583) and promptly ran into the problem. Logging in using our normal, intra-net, URL works just fine.

          HTTP/1.1 302 Found
          Set-Cookie: JSESSIONID.3a3afa59=1osdlnih6c42p1kkmc0uhgrmmz;Path=/tools/jenkins;Secure;HttpOnly
          Expires: Thu, 01 Jan 1970 00:00:00 GMT
          Location: http://127.0.0.2:8080/tools/jenkins/;jsessionid=1osdlnih6c42p1kkmc0uhgrmmz
          Content-Length: 0
          Server: Jetty(8.y.z-SNAPSHOT)
          

          Manni added a comment - I have a feeling that this is triggered when the jenkins url contains a port number. I just tried accessing my jenkins instance through a SSH tunnel (something that used to work until we upgraded to 1.583) and promptly ran into the problem. Logging in using our normal, intra-net, URL works just fine. HTTP/1.1 302 Found Set-Cookie: JSESSIONID.3a3afa59=1osdlnih6c42p1kkmc0uhgrmmz;Path=/tools/jenkins;Secure;HttpOnly Expires: Thu, 01 Jan 1970 00:00:00 GMT Location: http: //127.0.0.2:8080/tools/jenkins/;jsessionid=1osdlnih6c42p1kkmc0uhgrmmz Content-Length: 0 Server: Jetty(8.y.z-SNAPSHOT)

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          war/pom.xml
          http://jenkins-ci.org/commit/jenkins/3addbabf8afae39022440d63216a360233dabc80
          Log:
          [FIXED JENKINS-22358]

          Integrated the newer version of Winstone

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html war/pom.xml http://jenkins-ci.org/commit/jenkins/3addbabf8afae39022440d63216a360233dabc80 Log: [FIXED JENKINS-22358] Integrated the newer version of Winstone

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3737
          [FIXED JENKINS-22358] (Revision 3addbabf8afae39022440d63216a360233dabc80)

          Result = SUCCESS
          kohsuke : 3addbabf8afae39022440d63216a360233dabc80
          Files :

          • war/pom.xml
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #3737 [FIXED JENKINS-22358] (Revision 3addbabf8afae39022440d63216a360233dabc80) Result = SUCCESS kohsuke : 3addbabf8afae39022440d63216a360233dabc80 Files : war/pom.xml changelog.html

          Daniel Beck added a comment -

          Having a port is the default, so it should occur much more often if that alone were the reason.

          Daniel Beck added a comment - Having a port is the default, so it should occur much more often if that alone were the reason.

          Damien Nozay added a comment -

          It may be related to https://github.com/jenkinsci/jenkins/commit/79c905e6d0b03b075eef5339b73a6e8c55acd620

          If you logged in with https:// and had a cookie with secure flag
          then if you visit the same link with http:// instead, you cannot use the cookie.

          Damien Nozay added a comment - It may be related to https://github.com/jenkinsci/jenkins/commit/79c905e6d0b03b075eef5339b73a6e8c55acd620 If you logged in with https:// and had a cookie with secure flag then if you visit the same link with http:// instead, you cannot use the cookie.

          Liam Reimers added a comment -

          Damien: That jives - I see that the 404 is an http: page, and when I replace that with https: (and remove the jsessionid cruft) it works as expected.

          Liam Reimers added a comment - Damien: That jives - I see that the 404 is an http: page, and when I replace that with https: (and remove the jsessionid cruft) it works as expected.

          John Barnes added a comment -

          This issue seems to have reappeared. We're using v.1.626 and have also reproduced this issue with the latest LTS 1.609.2 as well.

          Behavior:
          1. Login with valid credentials,
          2. 404 "Not found" page displays,
          3. Remove session ID URL parameter and hit enter,
          4. Jenkins home displays for the credentialed user.

          This behavior is the same whether we invoke Jenkins through our Nginx reverse proxy (http://192.168.41.1/jenkins) or bypass the proxy and go directly to Jenkins running on http://192.168.41.1:8080/jenkins.

          Environment:
          AWS Ubuntu 14.04 EC2 instance
          VPN access only (192.168.41.1 Nat'd to the instance's private IP)
          Jenkins 1.626
          WildFly 9.0.1.Final
          Nginx 1.4.6 (on port 80 with reverse proxy to Jenkins running on WildFly 8080)
          Oracle Java build 1.8.0_60-b27

          John Barnes added a comment - This issue seems to have reappeared. We're using v.1.626 and have also reproduced this issue with the latest LTS 1.609.2 as well. Behavior: 1. Login with valid credentials, 2. 404 "Not found" page displays, 3. Remove session ID URL parameter and hit enter, 4. Jenkins home displays for the credentialed user. This behavior is the same whether we invoke Jenkins through our Nginx reverse proxy ( http://192.168.41.1/jenkins ) or bypass the proxy and go directly to Jenkins running on http://192.168.41.1:8080/jenkins . Environment: AWS Ubuntu 14.04 EC2 instance VPN access only (192.168.41.1 Nat'd to the instance's private IP) Jenkins 1.626 WildFly 9.0.1.Final Nginx 1.4.6 (on port 80 with reverse proxy to Jenkins running on WildFly 8080) Oracle Java build 1.8.0_60-b27

          This happens also on JBoss EAP7 as htpps sessions in URL are enabled by default.
          I submitted a pull request to disable the jsessionid in deployments of Jenkins on jboss.

          https://github.com/jenkinsci/jenkins/pull/2003

          Francesco Pagetti added a comment - This happens also on JBoss EAP7 as htpps sessions in URL are enabled by default. I submitted a pull request to disable the jsessionid in deployments of Jenkins on jboss. https://github.com/jenkinsci/jenkins/pull/2003

          Oleg Nenashev added a comment -

          Added a link to https://issues.jboss.org/browse/WFLY-4782 with extra details

          Oleg Nenashev added a comment - Added a link to https://issues.jboss.org/browse/WFLY-4782 with extra details

          Code changed in jenkins
          User: pagio81
          Path:
          war/src/main/webapp/WEB-INF/jboss-web.xml
          http://jenkins-ci.org/commit/jenkins/2f6b3d581617438a6efe0b910989ddaa9669eaa3
          Log:
          JENKINS-22358 - Disable JSESSIONID in URL on JBoss (#2003)

          More details: https://issues.jboss.org/browse/WFLY-4782

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: pagio81 Path: war/src/main/webapp/WEB-INF/jboss-web.xml http://jenkins-ci.org/commit/jenkins/2f6b3d581617438a6efe0b910989ddaa9669eaa3 Log: JENKINS-22358 - Disable JSESSIONID in URL on JBoss (#2003) More details: https://issues.jboss.org/browse/WFLY-4782

            Unassigned Unassigned
            davida2009 David Aldrich
            Votes:
            6 Vote for this issue
            Watchers:
            18 Start watching this issue

              Created:
              Updated: