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

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?

timja commented 10 years ago

Ping!

timja commented 10 years ago

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

timja commented 10 years ago

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.

timja commented 10 years ago

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

timja commented 10 years ago

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?

timja commented 10 years ago

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).

timja commented 10 years ago

thevilscot:

I also got the same issue today on ubuntu 14.04 lts

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

Not Found

timja commented 10 years ago

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.

timja commented 10 years ago

manni:

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.

timja commented 10 years ago

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;

timja commented 10 years ago

liam:

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.

timja commented 10 years ago

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?

timja commented 10 years ago

liam:

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.

timja commented 10 years ago

evernat:

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.

timja commented 10 years ago

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?

timja commented 10 years ago

liam:

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

timja commented 10 years ago

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.

timja commented 10 years ago

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.

timja commented 10 years ago

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.

timja commented 10 years ago

scm_issue_link:

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.

timja commented 10 years ago

manni:

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)

timja commented 10 years ago

scm_issue_link:

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

timja commented 10 years ago

dogfood:

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

Result = SUCCESS
kohsuke : 3addbabf8afae39022440d63216a360233dabc80
Files :

war/pom.xml
changelog.html

timja commented 10 years ago