No support for Jaeger behind a reverse proxy

[delaman]

Jaeger does not run behind a reverse proxy due to how the css and js is being loaded.

<link href="/static/css/main.123456789.css" rel="stylesheet">

This can be corrected with something like

<link href="./static/css/main.123456789.css" rel="stylesheet">

Similarly with the js file.

Thanks

[yurishkuro]

@delaman This blog post shows running Jaeger UI behind a proxy without the changes you suggested. How is your setup different?

@jpkrohling did your blog post get published too?

My concern with adding ./ prefix is that I am not sure how well it would work when the URL contains other segments, like the trace view https://jaeger.domain.com/trace/4380652658ee - the browser will try to load static files from /trace/static/css/ because ./ would be relative to /trace/

[jpkrohling]

Yes, it's published here: http://www.hawkular.org/blog/2017/07/jaeger-with-security-proxy.html , but not sure my approach would solve this.

[delaman]

My reverse proxy setup has a baseurl that is not "/" it is something like "/xyz". This is why jaeger does not work with my setup. Again the only two issues is the loading of two static files namely the .js file and the .css file.

@yurishkuro is the "/trace" routing handled by angular?

[yurishkuro]

Routing is handled by React.

cc @tiffon

[tiffon]

@delaman, the UI is built on top of Facebook's Create React App. One of the implications is static assets are added to the HTML file dynamically (docs) — note the <script> tag is not in the HTML file.

Initial reading suggests modifying the script tag to use relative imports would entail breaking with Create React App. (Turns out this is not accurate.) Also, I believe @yurishkuro is right in that the static assets for any non-root page would refer to the wrong path.

Have you confirmed the issue is limited to the static assets? For instance, what response do you get from the following (assuming /xyz is the prefix on the URL):

• /xyz/api/traces (should be 400 with empty JSON object)
• /xyz/search (should be 200 with index.html served)

Also, depending on the reverse proxy you're using, can you configure rewrite rules to strip the /xyz before passing the request downstream?

[delaman]

/xyz/api/traces traces does give a 400
/xyz/search does give a 200

My reverse proxy is striping out the xyz This is how the main index page is being loaded. If I don't remove the /xyz with the reverse proxy than I do not even get the failed main.css and the failed main.js errors.

[tiffon]

@delaman, got it, thanks.

Further searching revealed a homepage setting in Create React App. If set to /xyz it will adjust the static asset URLs.

But, with that change, the front-end routing will likely always show a not found page, and the ajax requests to load data are based on / so would return 404s if the app got that far.

Side note: The homepage config option is a build-time configuration value; it's baked into the HTML when the static assets are bundled. The main way to leverage it would be to generate a custom build based on your URL prefix and refer the query service to your generated build via the --query.static-files cli option of the jaeger-query command.

One approach to address the issue you've raised is to base front-end routing and ajax requests on the package.json#homepage setting. That would have the downside of still requiring a custom build based on the homepage setting.

On the other hand, we can look into changing the URL patterns to something along the lines of /trace?id=some-id. While not elegant, it would circumvent the need for custom UI builds to handle URL prefixes.

Something that came to mind as a short-term solution is a rewrite rule based on the referer header, but the front-end routing issue would still crop up.

[tiffon]

@delaman Wanted to share an update.

After discussing the issue with the team, we're thinking the approach of changing the URL patterns is not going to be feasible for the long-term.

On the other hand, an open PR (#53) adjusts front-end routing and AJAX calls so they are compatible with the homepage setting in package.json. Once it's merged, you should be able to create a custom build with homepage set to /xyz (or whatever your prefix is) and you should be good to go.

I have confirmed it works, but I was using a sort of haphazard nginx.conf to test it out.

[yurishkuro]

@tiffon do we have instructions somewhere on what people need to do to make use of the change from #53?