Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
Jenkins installed from http://pkg.jenkins-ci.org/debian/ on Ubuntu Maverick, v1.0 of plugin installed
Description
When running Jenkins behind apache and terminating https in apache, openid login always fails return_to verification.
I'm almost certain that because the "return_to" in the URL the OP forwards the browser to is a https URL but jenkins calls getRequestURL which returns a http in this case.
Attachments
Activity
Tom Boettcher
added a comment - There are also related issues here when the hostname/port associated with Jenkins' URL (typically pointing to Apache) don't match those associated with the Jenkins container. For instance, I have Apache running on port 80 and Tomcat running on 8080, but I'd rather not 'publish' the 8080 address whenever Jenkins links to itself. I solved this issue in the interim by using an AJP connector between Tomcat and Apache so that the URLs will match, but it would be nice to have a solution that doesn't require me to alter my deployment.
Examining the code, it looks like the receivingURL is being pulled from the request[1]. Changing this to the URL that was sent as returnTo (Hudson.getInstance().getRootUrl()+ finishUrl) would likely solve the problem. In my opinion the openid4java javadoc is a bit misleading here because you really want to verify that the returnTo matches what you sent, not where you happen to be deployed.
Tom Boettcher
added a comment - There are also related issues here when the hostname/port associated with Jenkins' URL (typically pointing to Apache) don't match those associated with the Jenkins container. For instance, I have Apache running on port 80 and Tomcat running on 8080, but I'd rather not 'publish' the 8080 address whenever Jenkins links to itself. I solved this issue in the interim by using an AJP connector between Tomcat and Apache so that the URLs will match, but it would be nice to have a solution that doesn't require me to alter my deployment.
Examining the code, it looks like the receivingURL is being pulled from the request [1] . Changing this to the URL that was sent as returnTo (Hudson.getInstance().getRootUrl()+ finishUrl) would likely solve the problem. In my opinion the openid4java javadoc is a bit misleading here because you really want to verify that the returnTo matches what you sent, not where you happen to be deployed.
[1] https://github.com/jenkinsci/openid-plugin/blob/master/src/main/java/hudson/plugins/openid/OpenIdSession.java#L93 Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
src/main/java/hudson/plugins/openid/OpenIdSession.java
http://jenkins-ci.org/commit/core/ddbf0c6cc050d8dfb72dc80418ccfb68aaac9bb5
Log:
[FIXED JENKINS-8755] Fixed a bug in the reverse proxy setup.
mwhudson
added a comment - The referenced commit seems to have disappeared, so reopening. What happened? It doesn't seem to have been rebased into another commit.
mwhudson
added a comment - The referenced commit seems to have disappeared, so reopening. What happened? It doesn't seem to have been rebased into another commit. The daemon is buggy and puts an incorrect link. The fix made it into 1.1
Oops, it's not jenkins that calls getRequestURL but rather openid4java.
My view of an ideal fix would either be a --generateHttpsUrls or some such command line flag that would cause getRequestURL to generate URLs starting with https:// or to support the X-Forwarded-Proto header, but I think both of these involve changing winstone.