Hi! I was wondering if there is any configuration ...
# help
a
Hi! I was wondering if there is any configuration option to set the root path for the UI web server? Specifically, I'm attempting to include a lakeFS instance in a Binder environment and expose it through jupyter-server-proxy. This allows users to access the lakeFS instance through a URL like
/[root_path]/proxy/8000
. However, the UI tries to fetch assets from
/assets/...
or to access the API at
/api
, which leads to 404 errors (due to the missing root path prefix in the URLs).
i
Hey Adrian, nice to meet! What root path do you mean? do you mean the lakeFS server URL?
This allows users to access the lakeFS instance through a URL like
/[root_path]/proxy/8000
What do you mean by access? UI access or API access? i’m not sure what’s that path you provided?
or to access the API at
/api
, which leads to 404 errors (due to the missing root path prefix in the URL
What component returns the 404? can you elaborate more on your setup, issue and what are you trying to achieve?
a
Sure thing, sorry for being a bit vague! Basically, the setup is a reverse HTTP proxy in front of the lakeFS instance, which proxies requests to
/.../proxy/8000/
to lakeFS. Requests to any other path prefix are forwarded to the underlying application server (JupyterHub in this case). The 404 errors are returned by JupyterHub for requests the lakeFS UI makes to fetch its JavaScript assets (e.g.,
/assets/index.js
) Was I was looking for is a way to configure the lakeFS server to add a given prefix to all URLs accessed from the frontend (or derive it from the request URL, maybe?). E.g., let's say I set this config value to
/root/path/proxy/8000
, the frontend would load its assets from
/root/path/proxy/8000/assets/8000
and access the backend lakeFS API under
/root/path/proxy/8000/api/...
. Does that make sense?
i
Thanks for clarifying. What you’re describing is not possible, the server does not support changing the API prefixes. Instead it feels to me like that usage on the reverse-proxy side is not optimal for that use case and I would look for a solution on that level that will not modify the path rather proxy based on the host of the domain itself. Using path’s based routing is possible but would require additional modifications to the request itself. In Nginx for example you could do something like (pseudo)
if path_prefix = /root/api then rewrite_path("/api") forward request
a
That's what I was assuming, thanks for clarifying. I agree that the setup isn't ideal, it is mostly driven by architectural constraints outside of my control for this scenario. I'll try and see if I can find any other way to do path-based request rewriting. Thanks again!
i
YW 🙌