Background:
In our lab we host range of projects from public open source to sensitive private customer projects. Because our Jenkins install works with all of them, we have never got around to making it externally accessible. We hacked up a reverse proxy to expose a single project via our public web server recently. The public reverse proxy is allow listing only the …/job/opensource-job-name/ URLs. Issues: The public website organization does not have the same base url structure as the “Jenkins URL” value. As such generated links in this public mirror have the wrong prefix. E.g. Jenkins URL=https://internal.excample.com/a/b/ and the public mirror is at https://www.example.com/c/d/e/ . This results in 404 errors. Potential solution approach: A patch or plugin to allow a more dynamic calculation of JENKINS_URL could allow the presentation of the same Jenkins information from two different points of view. In the Jenkins Location section a new checkbox would appear, “allow HTTP Header override”. When checked it would override the JENKINS_URL value if the header was injected by the reverse proxy and the default at all other times (e.g. scheduled job email links). The help text would instruct that all reverse proxies should strip or explicitly set the header and the Jenkins server should be firewalled against access by non-proxies. Benefits: * Mirroring of (selected) Jenkins content becomes more flexible. * Different security domains/realms can have different filtered accesses I am happy to write the patch, but it may be beyond my current understanding of the Jenkins internals. Thoughts? -Jason -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/085701d6cb07%24c9002d90%245b0088b0%24%40pdinc.us.
