[JENKINS-16368] Hardcoded protocol in some links

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)

Originally reported by vjuranek, imported from: Hardcoded protocol in some links

assignee: kohsuke
status: Resolved
priority: Major
component(s): core
resolution: Fixed
resolved: 2013-03-01T01:35:06+00:00
votes: 5
watchers: 13
imported: 2025-11-24

Raw content of original issue

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)

vjuranek:

Original comment link
Raw content of original comment:
```
Fixed in 460e508
```

Fixed in 460e508

kutzi:

Original comment link

Raw content of original comment:

Might also be worth thinking about using network-path references http://stackoverflow.com/questions/3583103/network-path-reference-uri-scheme-relative-urls

jglick:

Original comment link

Raw content of original comment:

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

kutzi:

Original comment link

Raw content of original comment:

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.

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.

kutzi:

Original comment link

Raw content of original comment:

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.

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.

jglick:

Original comment link

Raw content of original comment:

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

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

kutzi:

Original comment link

Raw content of original comment:

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

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

kutzi:

Original comment link

Raw content of original comment:

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.

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.

jglick:

Original comment link

Raw content of original comment:

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 Use request protocol for configured Jenkins url #671 be backed out (other than the baseline tests in JenkinsGetRootUrlTest)?

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 #671 be backed out (other than the baseline tests in JenkinsGetRootUrlTest)?

jcook793:

Original comment link

Raw content of original comment:

Oh wow, as I was writing my HTTPS proxy bug report, you guys were talking about this very thing!

jglick:

Original comment link

Raw content of original comment:

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

scm_issue_link:

Original comment link

Raw content of original comment:

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.

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.

olivergondza:

Original comment link

Raw content of original comment:

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.

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.

dogfood:

Original comment link

Raw content of original comment:

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

Integrated in jenkins_main_trunk #2224
~~JENKINS-16368~~ Reverted faulty fix. (Revision 40dcfcb)

Result = SUCCESS
Jesse Glick : 40dcfcb18178aa1cd2e73688492b4c4578be6968
Files :

changelog.html
core/src/test/java/jenkins/model/JenkinsGetRootUrlTest.java
core/src/main/java/jenkins/model/Jenkins.java

jglick:

Original comment link

Raw content of original comment:

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.

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.

scm_issue_link:

Original comment link

Raw content of original comment:

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: 902edc3...9447289

– 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:
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: 902edc3...9447289

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

dogfood:

Original comment link

Raw content of original comment:

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

Integrated in jenkins_main_trunk #2320
[FIXED JENKINS-16368] (Revision 9447289)

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

[Original is_duplicated_by from Jira: JENKINS-16511]

[Original is_duplicated_by from Jira: JENKINS-16613]

[Original is_duplicated_by from Jira: JENKINS-16626]

[Original is_duplicated_by from Jira: JENKINS-16656]

[Original relates_to from Jira: JENKINS-16802]

Navigation Menu

Repository navigation

[JENKINS-16368] Hardcoded protocol in some links #13219

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[JENKINS-16368] Hardcoded protocol in some links #13219

Description

Activity

jenkins-infra-bot commented on Jan 15, 2013

jenkins-infra-bot commented on Jan 27, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

jenkins-infra-bot commented on Jan 28, 2013

22 remaining items

jenkins-infra-bot commented on Mar 1, 2013

jenkins-infra-bot commented on Mar 1, 2013

jenkins-infra-bot commented on Nov 24, 2025

jenkins-infra-bot commented on Nov 24, 2025

jenkins-infra-bot commented on Nov 24, 2025

jenkins-infra-bot commented on Nov 24, 2025

jenkins-infra-bot commented on Nov 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions