-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Powered by SuggestiMate
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.
- system_info.docx
- 70 kB
- Pawel Grzegrzolka
- system_info.docx
- 70 kB
- Pawel Grzegrzolka
[JENKINS-22358] Jenkins 1.556 gives 'Error 404 Not Found'
The problem also appears in FireFox. I managed to clear it by restarting the browser.
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)
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?
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.
I've just noticed that secured connection (SSL) doesn't have this issue. Jetty complains only when trying to connect via http.
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?
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
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.
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.
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?
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;
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.
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?
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.
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?
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.
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.
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.
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
Integrated in jenkins_main_trunk #3737
[FIXED JENKINS-22358] (Revision 3addbabf8afae39022440d63216a360233dabc80)
Result = SUCCESS
kohsuke : 3addbabf8afae39022440d63216a360233dabc80
Files :
- war/pom.xml
- changelog.html
Having a port is the default, so it should occur much more often if that alone were the reason.
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: 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.
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.
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
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.