Hosting zipkin UI through a proxy #1452

Open
raiRaiyan opened this Issue Dec 22, 2016 · 8 comments

Projects

None yet

3 participants

@raiRaiyan

The zipkin ui that is hosted when a java zipkin server is launched is accessible only through the hostname of the machine where the ui is hosted.
Like http://localhost:9411/

If the request to the ui is proxied through a gateway, the UI becomes inaccessible.
Like http://abcd.com/zipkin/

The problem seems to be the app.js bundle file for the ui is not requested relatively. The request is something like http://abcd.com/app.js/, whereas this request should also be proxied http://abcd.com/zipkin/app.js

Looking into it, I figured that publicPath in webpack.config file is specified as /, which makes the requests non relative.

Even after changing that, all the jquery requests that the ui makes to retreive the data is not proxied.
Can this be changed, maybe accept a basePath property in config.json of the ui, which will allow the ui to be proxied? Or is there already a way to do this?

@adriancole
Contributor
@raiRaiyan raiRaiyan closed this Dec 22, 2016
@raiRaiyan raiRaiyan reopened this Dec 22, 2016
@raiRaiyan

@adriancole The ui itself is not accessible when proxied. The index.html requests for a file /app.js non relatively.

@adriancole
Contributor

oh right.. you are talking about proxying, and also hosting under a different path.

can you please find the existing issue on this and close this as a dupe?

@eirslett
Contributor

Ok, here is the solution we can implement (it was discussed before) Always serve the zipkin ui under a context path, like /zipkin/. Any requests that don't start with that URL will automatically be forwarded. That means there will be no special handling when using a proxy.

@adriancole
Contributor

@eirslett seems right, since iirc most are asking for that specific path anyway :) We'd have to whitelist quite a few things, like the api config health checks, etc. Maybe we forward the root itself or is a whitelist ok?

@eirslett
Contributor

/api/ can be duplicate-served under /zipkin/api/ for a while, I guess not all http clients people use handle 302? But all browsers will.

@adriancole
Contributor
adriancole commented Dec 22, 2016 edited

@eirslett what if we did it the other way.. we change the content to use paths of /zipkin, and mount the UI assets both under /zipkin and also under root. Might be naive, but could that solve the migration problem as well? cc @abesto

@eirslett
Contributor

The problem is with crossroads, which doesn't know what to serve (which route) if it doesn't know about the context path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment