-
Bug
-
Resolution: Cannot Reproduce
-
Major
-
None
-
Jenkins 1.496 and Build Failure Analyzer 1.4.0
-
Powered by SuggestiMate
I use a reverse proxy on my jenkins with a security management and icons are no more displayed from 1.4.0 version.
Plugin does not use the reverse proxy for create image url : http://computer_name:8080//plugin/build-failure-analyzer/images/48x48/information.png.
- duplicates
-
JENKINS-15948 Analyzer Icons aren't displayed if Jenkins isn't installed at root context.
-
- Reopened
-
[JENKINS-16868] Icons are not displayed with a reverse proxy
In fact, this url works : http://reverse-proxy//plugin/build-failure-analyzer/images/48x48/information.png but url image is http://computer_name:8080//plugin/build-failure-analyzer/images/48x48/information.png and anonymous have no right on this url for security management.
Ok, I hoped the slashes would have something to do with it but it seems to be 2 different problems then.
The plugin uses getRootUrlFromRequest() ( http://javadoc.jenkins-ci.org/jenkins/model/Jenkins.html#getRootUrl() ) for getting image base url but I read in jenkins api documentation this method is not compatible with reverse proxy whereas I believe getRootUrl() ( http://javadoc.jenkins-ci.org/jenkins/model/Jenkins.html#getRootUrlFromRequest() ) works with a reverse proxy.
By using getRootUrl, we got problems with users using a context path which isn't the root. We will look into the problem and see if we can find something which works for everyone.
I came up with solution that works for most cases. The one case it won't work is when you are running behind a reverse proxy and don't fill out the Jenkins URL in settings. getRootUrl() uses getRootUrlFromRequest() as a fallback if the field is left blank, but since it doesn't work behind reverse proxy we won't be able to find out the rootUR. Make sure to fill out the field
I will try to release the fix as soon as I can.
we dont use reverse proxy and after upgrade we have this image url:
http://computer_name/jenkins/jenkins/plugin/build-failure-analyzer/images/16x16/information.png
but should be:
http://computer_name/jenkins/plugin/build-failure-analyzer/images/16x16/information.png
Maybe this will help?
https://wiki.jenkins-ci.org/display/JENKINS/Hyperlinks+in+HTML
Unfortunately I still see this issue in v1.5.0. My configuration is as follows:
1) jenkins is behind an Apache reverse proxy:
ProxyPass /jenkins http://127.0.0.1:8080/jenkins ProxyPassReverse /jenkins http://127.0.0.1:8080/jenkins ProxyPassReverse /jenkins http://servername/jenkins
2) Jenkins URL looks like "https://servername/jenkins/" in the settings page
3) Bad image URL being generated looks like "https://servername/jenkins/jenkins/plugin/build-failure-analyzer/images/48x48/information.png (Notice the extra "/jenkins" in there.
4) If I browse to "https://servername/jenkins/plugin/build-failure-analyzer/images/48x48/information.png" it works fine.
I have the same behavior that Matt is experiencing.
My apache reverse proxy is configured as:
ProxyPass /jenkins/ http://TSTJENK001.xxxx.com:8080/jenkins/ nocanon
ProxyPassReverse /jenkins/ http://TSTJENK001.xxxx.com:8080/jenkins/
Why do all of the Images have absolute paths as opposed to relative paths like the rest of the images in the page?
Still a problem with the latest version and no reverse proxy. My jenkins installation is at
http://<ip-address>:8080/jenkins
and the image URL that is requested is
http://<ip-address>:8080/jenkins/jenkin/plugin/build-failure-analyzer/images/48x48/information.png
Note the "jenkins/jenkins" in the URL.
I'm experiencing the same issue with the latest version.
Not very smart but I used the following apache configuration to temporally solve the problem until a patch is released:
ProxyPass /jenkins/jenkins/ http://localhost:7080/jenkins/ nocanon
ProxyPassReverse /jenkins/jenkins/ http://localhost:7080/jenkins/
ProxyPass /jenkins/ http://localhost:7080/jenkins/ nocanon
ProxyPassReverse /jenkins/ http://localhost:7080/jenkins/
See these comments from Stephen Connolly:
Jenkins.getRootUrlFromRequest() is the one you almost always want to use from code that ends up in a .jelly page. The other one: Jenkins.getRootUrl() is the one to use when dealing with stuff outside of a HTTP request.
If you use them the wrong way around then you end up with secure content warnings or else failed requests as the session will not be maintained across the different host names. Usually this is not a "big deal" as users tend to access via the correct URL in the first place... but it can become a big deal when there is an outage that you are trying to resolve"
In the case of a reverse proxy, using the Mailer information for the URL is fine but you end up appending "contextPath" to the URL which should already be part of the
Mailer.descriptor().getUrl()
It looks like the necessary research has been done in JENKINS-15948 but the change is not being integrated.
I am also experiencing the double /jenkins/ path and my Jenkins is installed at http://leeroy.centtech.com/jenkins/ this is of course breaking the images. Is there a interim fix for this?
I used this mod_rewrite rule to add in the mapping for /jenkins/jenkins
RewriteRule ^/jenkins/jenkins/(.*)$ http://TSTJENK001.xxxx:8080/jenkins/$1 [P]
I think we should start using the icon-shim plugin for all the icons so all those problems can be shoved over there.
It turns out when setting the Jenkins location (in the settings) correctly it all works. I didn't realize that's where the base URL would come from but it seems to be working at the moment.
Jenkins should display a warning on /manage if that URL is wrong, pointing you to https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+says+my+reverse+proxy+setup+is+broken
I am running into the same issue as I need to access the host via SSH port forwarding. Possibly naive question: why does this work for all the other plug ins, just BFA seems to have a problem?
Thanks a lot for all the work,
Michael
I am using it (1.16) in the same configuration without problems so I assume this was fixed.
Does it work for you if you remove the double slash before plugin in the url?