Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running jupyter lab behind a reverse proxy with rewrite rule #13764

Closed
chiragjn opened this issue Jan 13, 2023 · 6 comments
Closed

Running jupyter lab behind a reverse proxy with rewrite rule #13764

chiragjn opened this issue Jan 13, 2023 · 6 comments
Labels
enhancement status:Needs Info status:Needs Triage Applied to new issues that need triage

Comments

@chiragjn
Copy link

chiragjn commented Jan 13, 2023

Problem

I have jupyter lab running via docker ( jupyter/minimal-notebook:python-3.9.13) with default settings and I am accessing it via a reverse proxy on https://<host>/jupyterlab/. This reverse proxy is out of my control and it works via a rewrite rule i.e. it maps
https://<host>/jupyterlab/... to http://<k8s-jupyter-service>:8888/....

As such I would want the jupyterlab frontend (server APIs are working fine) to understand that all URLs will be relative to /jupyterlab/ instead of /

I already understand that setting --NotebookApp.base_url='/jupyterlab/' along with a simple proxy pass rule instead of a rewrite rule can get everything working but the reverse proxy rules are not in my control

I tried setting --NotebookApp.base_url='' to get relative URLs in the UI but the documentation states

NotebookApp.base_urlUnicode
Default: '/'
The base URL for the notebook server.
Leading and trailing slashes can be omitted, and will automatically be added.

So --NotebookApp.base_url='' is equivalent to --NotebookApp.base_url='/' which is the default.

Proposed Solution

  1. Not adding leading/trailing slash to --NotebookApp.base_url when value is explicitly set to empty string. However, I am not sure what else can break with such relative URLs
  2. Some base_url flag that only affects rendered URLs in frontend

Additional context

@jupyterlab-probot jupyterlab-probot bot added the status:Needs Triage Applied to new issues that need triage label Jan 13, 2023
@JasonWeill
Copy link
Contributor

Hey @chiragjn , thanks for filing this issue!

Have you taken a look at Jupyter Enterprise Gateway to see if it offers the options that you need?

This might be an issue better suited for Jupyter Server, which interprets URLs and is included with JupyterLab. If enterprise gateway doesn't suit your needs, you might want to check the server issues list and open a new issue in Jupyter Server if none already exists.

@JasonWeill
Copy link
Contributor

Hey @chiragjn — can you please follow up on the questions from last week? Thanks!

@chiragjn
Copy link
Author

chiragjn commented Jan 27, 2023

Have you taken a look at Jupyter Enterprise Gateway to see if it offers the options that you need?

Hello, I haven't had a chance to take a look at it yet, I'll check it out sometime next week

This might be an issue better suited for Jupyter Server, which interprets URLs and is included with JupyterLab.

In my opinion, it is not about interpreting on the server side but rather what value of base_url is passed for href in the UI templates
https://github.com/search?q=repo%3Ajupyterlab%2Fjupyterlab%20%22base_url%22&type=code

because this cannot be set to empty string '', I can't make it work with a proxy doing re-writes instead of proxy pass.

I am leaving this message in a hurry, I'll be back with a potential solution in the jupyter codebase later

@bollwyvl
Copy link
Contributor

bollwyvl commented Feb 2, 2023

Yep, it definitely needs a /.

As the owner of the docker container, is there any way you can control the base URL dynamically?

Some loci are:

  • overload html templates
  • overload the page_config
  • customize the application itself with a custom launcher

It's also worth looking into launching jupyter_server (configured with e.g. ServerApp) instead of notebook's NotebookApp

@JasonWeill
Copy link
Contributor

@chiragjn Any update after the comments that @bollwyvl left on this issue last week?

@JasonWeill
Copy link
Contributor

Closing this issue because of no new comments in the thread in a couple of weeks. @chiragjn if you have any additional questions, please reopen this issue or open a new one. Thanks!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement status:Needs Info status:Needs Triage Applied to new issues that need triage
Projects
None yet
Development

No branches or pull requests

3 participants