Validate running lens under a reverse proxy #2519

codefromthecrypt · 2019-04-19T07:26:14Z

#1946 implemented reverse proxy configuration, where zipkin was mounted alongside other services. This was addressed by an env variable ZIPKIN_UI_BASEPATH described below:

path prefix placed into the tag in the UI HTML; useful when running behind a reverse proxy. Default "/zipkin"

We need to read that variable from /config.json in lens, then ping @wdittmer @abesto to verify later (unless one of them wants to help implement!)

The text was updated successfully, but these errors were encountered:

jcchavezs · 2019-04-19T08:53:16Z

Maybe a browser test would be good here? I think we have some expertise in my company I could borrow.

shakuzen · 2019-05-20T07:19:07Z

I think we have some expertise in my company I could borrow.

@jcchavezs just checking back to see if you or someone from your company would be able to help resolve this (it's one of the issues blocking switching the default UI to Lens).

jorgheymans · 2019-09-19T17:50:51Z

I tested this with mod_proxy and a local httpd running on 8080

ProxyPass "/myzipkin"  "http://localhost:9411/zipkin"
ProxyPassReverse "/myzipkin"  "http://localhost:9411/zipkin"

Started zipkin-server using java -jar target/zipkin-server-2.16.3-SNAPSHOT-exec.jar --zipkin.ui.basepath=/myzipkin

Then accessing http://localhost:8080/myzipkin ends up loading lens correctly but the browser url becomes http://localhost:8080/zipkin/ which does not seem desired.

codefromthecrypt · 2019-09-19T22:37:34Z

great. Thanks @jorgheymans. this is progress

@tacigar

For well over a year, we've been working on Lens, most notably @tacigar. In fact a year ago, we added a "Try Lens" button and addressed a lot of feedback from that, again largely thanks to @tacigar. It isn't fair to hold the project hostage until some notion of perfection happens. It is also unfair for people to pick certain issues to block on, yet not volunteer to help. It is of my opinion we stop holding ourselves hostage to a maintenance pit and remove the burden and confusion of two UIs. This concedes the following just won't work until someone volunteers to fix them. Waiting a year hasn't done it, so waiting more won't either. * ZIPKIN_UI_BASEPATH for reverse proxy #2519 * ZIPKIN_UI_LOGS_URL #2491 * /config.json config overrides #2969 * Chinese language support #2970

@tacigar

For well over a year, we've been working on Lens, most notably @tacigar. In fact a year ago, we added a "Try Lens" button and addressed a lot of feedback from that, again largely thanks to @tacigar. It isn't fair to hold the project hostage until some notion of perfection happens. It is also unfair for people to pick certain issues to block on, yet not volunteer to help. It is of my opinion we stop holding ourselves hostage to a maintenance pit and remove the burden and confusion of two UIs. This concedes the following just won't work until someone volunteers to fix them. Waiting a year hasn't done it, so waiting more won't either. * ZIPKIN_UI_BASEPATH for reverse proxy #2519 * ZIPKIN_UI_LOGS_URL #2491 * /config.json config overrides #2969 * Chinese language support #2970

anuraaga · 2020-02-22T08:31:29Z

I'm looking at this issue. I know in #1946 we added a mechanism for injecting the base path from the server to read in the client. But wondering, does anyone remember if there was any gotcha from just trying to extract the base path from the current window.location?

I think a URL that renders zipkin-lens can only look like one of these patterns

So simple processing of window.location.href can find that the base path is https://fooserver.com/mysite/myzipkin/

One corner case is if a user enters there own 404 URL like this

https://fooserver.com/mysite/myzipkin/foobar/

With just parsing of the URL, we would end up treating this as a base path (the URL to the discover page) of https://fooserver.com/mysite/myzipkin/foobar/. Ideally, the reverse proxy itself throw the 404 for this, but in case it doesn't, we'd still be able to do it though if we treat a 404 for BASE_PATH/config.json as a 404 page. This doesn't seem too high priority to me though since we're already not very good, lens displays a blank confusing page if a request of an unknown path does make it through (e.g., when using the dev server) so any handling of bad URLs would be an improvement regardless of base path handling.

Interpreting the base path would allow users to proxy without even worrying about setting a property. And it simplifies our dev server too by removing the dev-only API_BASE environment variable.

Let me know if you have any concerns about such an approach. /cc @abesto

jcchavezs · 2020-02-22T09:09:53Z

I don't think there was any gotcha before, tho we did not use react (it was not a SPA either) so it is worth to keep an eye on it (are we using react-router?). Any thoughts on this @pchiwan? (Resolving basepath from window.location vs setting one on beforehand)

…

On Sat, 22 Feb 2020, 09:31 Anuraag Agrawal, ***@***.***> wrote: I'm looking at this issue. I know in #1946 <#1946> we added a mechanism for injecting the base path from the server to read in the client. But wondering, does anyone remember if there was any gotcha from just trying to extract the base path from the current window.location? I think a URL that renders zipkin-lens can only look like one of these patterns - https://fooserver.com/mysite/myzipkin/ - https://fooserver.com/mysite/myzipkin/dependency - https://fooserver.com/mysite/myzipkin/traces/39048234098234 - https://fooserver.com/mysite/myzipkin/traceViewer So simple processing of window.location.href can find that the base path is https://fooserver.com/mysite/myzipkin/ One corner case is if a user enters there own 404 URL like this - https://fooserver.com/mysite/myzipkin/foobar/ With just parsing of the URL, we would end up treating this as a base path (the URL to the discover page) of https://fooserver.com/mysite/myzipkin/foobar/. Ideally, the reverse proxy itself throw the 404 for this, but in case it doesn't, we'd still be able to do it though if we treat a 404 for BASE_PATH/config.json as a 404 page. This doesn't seem too high priority to me though since we're already not very good, lens displays a blank confusing page if a request of an unknown path does make it through (e.g., when using the dev server) so any handling of bad URLs would be an improvement regardless of base path handling. Interpreting the base path would allow users to proxy without even worrying about setting a property. And it simplifies our dev server too by removing the dev-only API_BASE environment variable. Let me know if you have any concerns about such an approach. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2519?email_source=notifications&email_token=AAXOYATXWA7MYJQOSQZHQK3REDPGFA5CNFSM4HHCPL2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMU2QHQ#issuecomment-589932574>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXOYAVGSHLXOIOBAOILO53REDPGFANCNFSM4HHCPL2A> .

anuraaga · 2020-02-22T09:14:49Z

Yup lens uses react-router. I'm hoping to extract the base path from window.location and pass it to react-router using the basename prop (as well as using it to configure API calls)

jcchavezs · 2020-02-22T09:29:12Z

I see. The reason I asked was because when I googled "Using window.location" Google autocompleted "with react" and many results are related to "react-router".

…

On Sat, 22 Feb 2020, 10:14 Anuraag Agrawal, ***@***.***> wrote: Yup lens uses react-router. I'm hoping to extract the base path from window.location and pass it to react-route using the basename prop (as well as using it to configure API calls) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2519?email_source=notifications&email_token=AAXOYAXUGSC6ANPU5GHA2CLREDUIVA5CNFSM4HHCPL2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMU3JFA#issuecomment-589935764>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXOYAUBJVKP7EROE2P5NO3REDUIVANCNFSM4HHCPL2A> .

codefromthecrypt added enhancement ui Zipkin UI labels Apr 19, 2019

codefromthecrypt mentioned this issue Feb 4, 2020

Makes Lens default, removing the dependency on the classic UI #2971

Merged

anuraaga mentioned this issue Feb 15, 2020

Read config.json in zipkin-lens and use it to set default query lookb… #2979

Merged

This was referenced Feb 22, 2020

Infer Zipkin base path based on current URL. #2982

Closed

Read base tag in zipkin-lens to allow reverse proxies. #2987

Merged

codefromthecrypt closed this as completed in #2987 Feb 26, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Validate running lens under a reverse proxy #2519

Validate running lens under a reverse proxy #2519

codefromthecrypt commented Apr 19, 2019

jcchavezs commented Apr 19, 2019 via email •

edited

Loading

shakuzen commented May 20, 2019

jorgheymans commented Sep 19, 2019

codefromthecrypt commented Sep 19, 2019

anuraaga commented Feb 22, 2020 •

edited

Loading

jcchavezs commented Feb 22, 2020 via email

anuraaga commented Feb 22, 2020 •

edited

Loading

jcchavezs commented Feb 22, 2020 via email

Validate running lens under a reverse proxy #2519

Validate running lens under a reverse proxy #2519

Comments

codefromthecrypt commented Apr 19, 2019

jcchavezs commented Apr 19, 2019 via email • edited Loading

shakuzen commented May 20, 2019

jorgheymans commented Sep 19, 2019

codefromthecrypt commented Sep 19, 2019

anuraaga commented Feb 22, 2020 • edited Loading

jcchavezs commented Feb 22, 2020 via email

anuraaga commented Feb 22, 2020 • edited Loading

jcchavezs commented Feb 22, 2020 via email

jcchavezs commented Apr 19, 2019 via email •

edited

Loading

anuraaga commented Feb 22, 2020 •

edited

Loading

anuraaga commented Feb 22, 2020 •

edited

Loading