-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Powered by SuggestiMate
Some links (e.g. in console output lnks "Building remotely on slaveXYZ") don't preserve protocol and have hardcoded HTTP even if the page is opened via HTTPS. This can be considered as a security risk (e.g. user doesn't notice change of the protocol and later on can open another console output with sensitive data and the data would be sent over unsecure HTTP in this case)
- is duplicated by
-
JENKINS-16511 Jenkins behind a proxy sends JNLP agents incorrect URL
-
- Resolved
-
-
JENKINS-16613 Windows slave fails to start via JNLP (wrong URL scheme + fails to redirect)
-
- Resolved
-
-
JENKINS-16626 Remote access API does not deal with a jenkins server only available through https
-
- Resolved
-
-
JENKINS-16656 slave agent fails to start: slave-agent.jnlp uses http while jenkins url is https
-
- Resolved
-
- is related to
-
JENKINS-16802 Using Apache proxysettings breaks several GUI functions
-
- Resolved
-
[JENKINS-16368] Hardcoded protocol in some links
Might also be worth thinking about using network-path references http://stackoverflow.com/questions/3583103/network-path-reference-uri-scheme-relative-urls
@kutzi I think you mean just simple absolute URIs like /computer/slaveXYZ; a network-path reference would be to a different server using the same protocol (//elsewhere.net/something), which is not needed for anything in Jenkins AFAIK.
Actually, I was thinking about network-path reference as this bug - as I understand it - is that in some places Jenkins#getRootUrl() is used to construct intra-Jenkins links. Indeed, using absolute URIs in this case would be the even better solution.
I find it quite strange that the value of getRootUrl doesn't always return the same - configured - value, but - based on the 'current' request - something different. But that was already so before this fix, so it doesn't actually worsen the situation.
Looking at it again, it actually does worsen the situation, as previously I was either getting the configured value or getRootUrlFromRequest() - which is also (kind of) mentioned in the Javadoc.
Now I have 3 different return values, based on the context.
The Javadoc could be edited, but I think it is necessary to reconsider the fix, which is just a workaround for missing logic in ConsoleNote.
My understanding of the bug is that we are talking about links within a single Jenkins master. E.g. https://server/job/stuff/1/console should link to https://computer/someslave not http://computer/someslave even if Jenkins “thinks” it is running as http://computer/. Therefore the link must be a complete URL, so hacking Jenkins.rootUrl is necessary (or the Jenkins admin needs to set the root URL to https://computer/ and accept HTTP -> HTTPS redirection as being the lesser evil).
The issue here is that AbstractBuildExecution.run calls ModelHyperlinkNote.encodeTo("/computer/someslave", …), and HyperlinkNote.annotate translates /computer/someslave to http://server/computer/someslave (before the current fix). It does this because it has no other way of determining an absolute URI: you could be running Jenkins with a web app context path like http://computer/ci/, or you could be running Jenkins behind a reverse proxy that maps http://localhost:8080/ to http://mycorp.com/ci/, etc., so /computer/someslave cannot be guaranteed to resolve to anything useful. Nor can //computer/someslave, so network-path references are irrelevant.
The best fix (IMO) would be to produce a relative URI, ../../../computer/someslave in this case, which will not only preserve scheme but would work correctly even in the face of an incorrect Jenkins.rootUrl setting. The difficulty is that HyperlinkNote.annotate now needs to take its Object context and determine its URL relative to the context root; and there seems to be no standard interface for this. For example, Run.getUrl does not implement any method. Perhaps such an interface could be introduced retroactively, in which case contexts assignable to this interface could result in relative URIs (with absolute URLs being used as a fallback).
We could have a new method in Jenkins which returns the rootUrl without protocol, so ModelHyperlinkNote could use absolute URIs, like you mentioned.
Or am I misunderstanding the issue?
Forget it. I think you already answered this with the proxy example.
Agree that this seems like a workaround. Moreover the fix doesn't seem to be complete as HTTPS might terminate in the reverse proxy, so Stapler.getCurrentRequest().getScheme() would return 'http'
So the only 'correct' way to operate Jenkins under https seems to simply configure the rootUrl to start with https. Otherwise it's IMO simply a configuration error.
Good point. If a reverse proxy is being used to add HTTPS support—a pretty common setup—then 460e508 might in fact be a major regression. Should https://github.com/jenkinsci/jenkins/pull/671 be backed out (other than the baseline tests in JenkinsGetRootUrlTest)?
Oh wow, as I was writing my HTTPS proxy bug report, you guys were talking about this very thing!
OK, that is a serious regression so I am going to back out the change immediately, pending a better solution (or clearer description of the tradeoffs of the current solution).
Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/java/jenkins/model/Jenkins.java
core/src/test/java/jenkins/model/JenkinsGetRootUrlTest.java
http://jenkins-ci.org/commit/jenkins/40dcfcb18178aa1cd2e73688492b4c4578be6968
Log:
JENKINS-16368 Reverted faulty fix.
–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group, send email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I agree, it's a regression.
As far as I can say the root url is sent via mail or rss, so I think relative urls wont do.
Integrated in jenkins_main_trunk #2224
JENKINS-16368 Reverted faulty fix. (Revision 40dcfcb18178aa1cd2e73688492b4c4578be6968)
Result = SUCCESS
Jesse Glick : 40dcfcb18178aa1cd2e73688492b4c4578be6968
Files :
- changelog.html
- core/src/test/java/jenkins/model/JenkinsGetRootUrlTest.java
- core/src/main/java/jenkins/model/Jenkins.java
The root URL is indeed used in some mail messages, RSS, etc., but this is a different use case from what was originally filed—these cases are not using ConsoleAnnotator, and there is in general no current Stapler request anyway. (Maybe for RSS, definitely not for mail.) For such miscellaneous cases, where Jenkins must of necessity emit a complete URL, the administrator must configure the Jenkins root URL manually.
The question is whether in generated pages containing internal links, especially console logs, we can use relative URLs to ensure that the link targets are correct even if the Jenkins root URL was not correctly configured.
I'd argue that the root URL must always be configured correctly. There's already a big warning on the global config page if you don't. Maybe we can still improve the documentation a bit to make the situation clearer for users.
And then I'd close this a not-a-bug.
Perhaps this would be less destructive https://github.com/jenkinsci/jenkins/pull/682.
It uses /job/stuff/1/console instead of https://server/job/stuff/1/console.
Not sure about #682. It introduces yet another way of creating URLs in Jenkins, adding to a confusing mix (and not helping Jelly pages which still have only ${rootURL}.) It is unnecessary if Jenkins.rootUrl is correctly configured, and inferior to emitting relative links if it is not. (#682 will still produce 404s if you have a reverse proxy which changes the effective context path but have not configured rootUrl.) If it is necessary to handle an unconfigured rootUrl—which is debatable—then we ought to do it right, I think.
Hi,
imposing URL scheme from Jenkins root URL doesn't seem as a completely correct approach. Use URL like /computer seems to me as a better approach (that's why I use it in disk-usage [1]) - not completely sure if it breaks when there's a reverse proxy which changes root context, need to set it up and pay with it for a while (AFAIK our admins use such setup in some cases without problems you described)
[1] https://github.com/jenkinsci/disk-usage-plugin/commit/5c0f68cc0f839918ca811bedaba37c4c031a0535
@vjuranek I think your comment about disk-usage is misleading, because you are in that case returning a path which is resolved against the Jenkins context path by infrastructure, not a URL directly emitted to HTML.
sorry, you are right, it's different case.
As for reverse proxy changing context root - it seems you are right, in such case the links are broken. However, doing so would break things anyway, it's even mentioned in [1] that context root cannot be changed.
[1] https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache
AFAIK proxying with a different context path ought to work so long as you configure {[rootUrl}} correctly to the publicly visible URL. Maybe @Kohsuke can say why he wrote https://wiki.jenkins-ci.org/pages/diffpagesbyversion.action?pageId=9043974&selectedPageVersions=10&selectedPageVersions=9 and whether that was specific to some detail of mod_proxy.
Is there going to be a hotfix for this issue? My JNLP clients literally cannot connect and I can't do any iOS builds right now. And I can't (easily) rollback my Jenkins version.
@jcook793: if you cannot wait for the next regular Jenkins build then I would recommend building from trunk sources.
Configuring Jenkins URL in a way kutzi proposed earlier (//elsewhere.net/something) seems to work correctly, i.e. links are HTTP on HTTP and HTTPS on HTTPS, so under assumption that such setup doesn't break anything else (which I haven't discovered yet) I agree to close as it as not a bug.
@vjuranek: I'm sure that might break some things - like when you try to use the root url in e-mails.
Network-path references will only work in the context of a current request - AFAIK
BTW: I didn't really propose to use this for the root URL. I just pointed out that this might be a solution in some way.
@kurzi: right, sorry (sorry to all, I replied in hurry and didn't read the discussion very carefully, also broken email were mentioned earlier in the discussion )
@jglick: as for broken reverse proxy, if I'm not mistaken, rootUrl for jelly pages (used e.g. in layout.jelly) is setup in Functions#initPageVariables() [1] and not from configured Jenkins URL
[1] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/Functions.java#L167
Huh. Well if the current Stapler request is used to create a server-absolute URL then definitely reverse proxies would be broken unless the context path happens to match on each side. Not sure why this does not use Jenkins.rootUrl when defined. (Or use ../ multiplied by the depth of the current URI relative to the context root.) There seem to be several contradictory ways of resolving URLs and no clear guidance on which should be preferred and why. Maybe @Kohsuke can explain it all.
I have the 'same' issue as in this bug (and bug 16511)
I access my jenkins through a reverse apache httpd proxy, enforcing https on the apache side and using http on the jenkins side.
since 1.500 my rss is broken.
My 'Jenkins URL' is configured correctly with the https link
@fhuberts: the fix for HTTPS reverse proxies will I think be in 1.501. (The RC branch process is a little subtle so I am never entirely sure where a given change is going to first appear until the release is cut!)
I wrote https://wiki.jenkins-ci.org/display/JENKINS/Hyperlinks+in+HTML that hopefully describes the current design of this in Jenkins.
From that stand point,
- I disagree with the initial fix (but this was backed out, so I'm good)
- I also disagree with pull request #682, because it violates Rule #1: no absolute URLs in hyperlinks
- The proper fix is to update HyperlinkNote so that it does not emit the absolute URL, and rather just use the context path from the current request (it shall fall back to the absolute URL if the code is without the thread-local request, such as when it's used for email-ext plugin)
I'll make the fix accordingly.
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
war/pom.xml
http://jenkins-ci.org/commit/jenkins/ded37a2b626419fcef6e9ae425331c275d827b48
Log:
JENKINS-16368 "mvn hudson-dev:run" to run with context path
This helps us catch a typical error of not using ${rootURL} or
getContextPath() where needed.
–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
plugins/pom.xml
http://jenkins-ci.org/commit/jenkins/17d2df75ffdcf49d6026f67e250747481cf39c28
Log:
JENKINS-16368 "mvn hpi:run" to use non-empty context path.
For a reason similar to ded37a2b626419fcef6e9ae425331c275d827b48,
better to run with non empty context path.
–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Integrated in jenkins_main_trunk #2316
JENKINS-16368 "mvn hudson-dev:run" to run with context path (Revision ded37a2b626419fcef6e9ae425331c275d827b48)
Result = UNSTABLE
kohsuke : ded37a2b626419fcef6e9ae425331c275d827b48
Files :
- war/pom.xml
Integrated in jenkins_main_trunk #2317
JENKINS-16368 "mvn hpi:run" to use non-empty context path. (Revision 17d2df75ffdcf49d6026f67e250747481cf39c28)
Result = SUCCESS
kohsuke : 17d2df75ffdcf49d6026f67e250747481cf39c28
Files :
- plugins/pom.xml
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/src/main/java/hudson/Functions.java
core/src/main/java/hudson/console/HyperlinkNote.java
core/src/main/java/jenkins/model/Jenkins.java
http://jenkins-ci.org/commit/jenkins/9447289c87522d96d54228e817c5aa3cd04744c6
Log:
[FIXED JENKINS-16368]
HyperlinkNote shouldn't emit the absolute URL.
Compare: https://github.com/jenkinsci/jenkins/compare/902edc38aa26...9447289c8752
–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Integrated in jenkins_main_trunk #2320
[FIXED JENKINS-16368] (Revision 9447289c87522d96d54228e817c5aa3cd04744c6)
Result = SUCCESS
kohsuke : 9447289c87522d96d54228e817c5aa3cd04744c6
Files :
- core/src/main/java/hudson/console/HyperlinkNote.java
- changelog.html
- core/src/main/java/hudson/Functions.java
- core/src/main/java/jenkins/model/Jenkins.java
Fixed in https://github.com/jenkinsci/jenkins/commit/460e508155187918e8c0f4fd0bb66a99cfe78527