Login endpoint issue when launching Ragna on JupyterHub(NEbari)

[dharhas]

Bug description

When I launch "ragna ui" from the command line on JupyterHub/Nebari with say:

BOKEH_ALLOW_WS_ORIGIN=nebari.quansight.dev ragna ui

Ragna is deployed with JupyterHub Server Proxy to the url:

https://nebari.quansight.dev/user/dharhas@quansight.com/proxy/31477/

This works but the the login page gets redirected to

https://nebari.quansight.dev/auth and shows a 404.

gets redirected to

https://nebari.quansight.dev/auth

manually changing the auth url to https://nebari.quansight.dev/user/dharhas@quansight.com/proxy/31477/auth

lets me login and then I can use ragna.

How to reproduce the bug?

launch a terminal on Jupyterhub/ragna and launch ragna ui

Versions and dependencies used

ragna - 0.1.3
python - 3.11.7
os - linux

Anything else?

No response

[pmeier]

I see that we are missing forward slashes for the auth and logout endpoints:

ragna/ragna/deploy/_ui/app.py

Lines 109 to 115 in 38f75f6

	all_pages = {
	"/": self.index_page,
	"auth": self.auth_page,
	"logout": self.logout_page,
	"/health": self.health_page,
	}
	titles = {"/": "Home"}

@pierrotsmnrd Do you remember if this was intentional?

I'm not saying that this is the issue here, but this the only thing that caught my eye while looking into it.

[pierrotsmnrd]

It was not intentional. I don't know if this has an impact or not. worth trying.

[pmeier]

@aktech confirmed that #276 indeed fixed the issue. However, we have for more instances of hardcoded paths for the login mechanism:

• ragna/ragna/deploy/_ui/app.py

  Line 66 in ea9ffeb

  return pn.pane.HTML("""<script>window.location.href = '/auth';</script>""")

• ragna/ragna/deploy/_ui/app.py

  Line 76 in ea9ffeb

  """<script>window.location.href = '/logout'; </script> """

• ragna/ragna/deploy/_ui/app.py

  Line 92 in ea9ffeb

  return pn.pane.HTML("""<script>window.location.href = '/'; </script> """)

• ragna/ragna/deploy/_ui/logout_page.py

  Line 22 in ea9ffeb

  window.location.href = '/';

They also need be relative. This most likely has to happen in JS.

[pmeier]

@aktech This is solved with the PRs you have send, correct?

[aktech]

I have not tested it yet. I am testing is right now.

[aktech]

The login endpoint issue is fixed (which is what this issue is about), I am able to login via the proxy url, which takes me to the /auth.

After login the UI will look for http://127.0.0.1:31476/document (when you upload a doc), which can be fixed with creating ui and api separately, something along these lines: nebari-dev/jhub-apps#147 I'll give that a try to confirm if that works (I am fairly confident it should).

[aktech]

I just tried running two separate processes explicitly one for API and another for UI

ragna api

ragna ui --no-open-browser --no-start-api

With this ragna.toml:

# change to match your directory and same for all others below
local_root = "/home/akumar@quansight.com/.cache/ragna"
authentication = "ragna.deploy.RagnaDemoAuthentication"
document = "ragna.core.LocalDocument"
source_storages = [
    "ragna.source_storages.RagnaDemoSourceStorage",
]
assistants = [
    "ragna.assistants.RagnaDemoAssistant",
]

[api]
hostname = "127.0.0.1"
port = "31476"

# change this url to match the url of the created ragna api app url
url = "https://nebari.quansight.dev/user/akumar@quansight.com/proxy/31476"
origins = ["https://nebari.quansight.dev"]
database_url = "sqlite:////home/akumar@quansight.com/.cache/ragna/ragna.db"

[ui]
hostname = "127.0.0.1"
port = 31477
origins = [
    "http://127.0.0.1:31477",
]

Below is the error (as API is not accessible to UI without authentication and it does a 302 redirect to hub authentication)

Error Traceback

$ ragna ui --no-open-browser --no-start-api
Launching server at http://127.0.0.1:31477
Uncaught exception GET / (127.0.0.1)
HTTPServerRequest(protocol='http', host='nebari.quansight.dev', method='GET', uri='/', version='HTTP/1.1', remote_ip='127.0.0.1')
Traceback (most recent call last):
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/tornado/web.py", line 1790, in _execute
    result = await result
             ^^^^^^^^^^^^
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/panel/io/server.py", line 588, in get
    session = await self.get_session()
              ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/panel/io/server.py", line 477, in get_session
    session = await super().get_session()
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/bokeh/server/views/session_handler.py", line 145, in get_session
    session = await self.application_context.create_session_if_needed(session_id, self.request, token)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/bokeh/server/contexts.py", line 240, in create_session_if_needed
    self._application.initialize_document(doc)
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/panel/io/server.py", line 413, in initialize_document
    super().initialize_document(doc)
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/bokeh/application/application.py", line 190, in initialize_document
    h.modify_document(doc)
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/bokeh/application/handlers/function.py", line 140, in modify_document
    self._func(doc)
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/panel/io/server.py", line 152, in _eval_panel
    panel = panel()
            ^^^^^^^
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/ragna/deploy/_ui/app.py", line 73, in index_page
    api_wrapper = ApiWrapper(
                  ^^^^^^^^^^^
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/ragna/deploy/_ui/api_wrapper.py", line 39, in __init__
    raise e
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/ragna/deploy/_ui/api_wrapper.py", line 32, in __init__
    ).raise_for_status()
      ^^^^^^^^^^^^^^^^^^
  File "/home/conda/akumar@quansight.com/de7fbfe4-1711448219-624-ragna-only/lib/python3.11/site-packages/httpx/_models.py", line 761, in raise_for_status
    raise HTTPStatusError(message, request=request, response=self)
httpx.HTTPStatusError: Redirect response '302 Found' for url 'https://nebari.quansight.dev/user/akumar@quansight.com/proxy/31476/components'
Redirect location: '/hub/api/oauth2/authorize?client_id=jupyterhub-user-akumar%2540quansight.com&redirect_uri=%2Fuser%2Fakumar%40quansight.com%2Foauth_callback&response_type=code&state=<SANITIZED>'

It didn't work as the API deployed via jupyter server proxy is supposed to be publicly accessible as the UI calls the API internally instead of on the browser as explained in here: nebari-dev/jhub-apps#147 (comment) (TLDR: UI hits the hub authentication before the API authentication).

I didn't see a way to expose the API publicly in the Jupyter Server Proxy @dharhas do you know if that's possible?

[dharhas]

@aktech we don't want the API to be publicly accessible right? it should still be behind auth but the hope would be that internally launched tools should be able to see each other.

pinging @krassowski in case he has any ideas.

[aktech]

@aktech we don't want the API to be publicly accessible right? it should still be behind auth but the hope would be that internally launched tools should be able to see each other.

Yes, there are two levels of authentication here:

• JupyterHub level
• Ragna level

We only want to get rid of the first one, the second one will still exist, which means the API won't be public.

[krassowski]

I think it is not possible to selectively disable auth in jupyter-server-proxy. One could hack it around by monkeypatching the tornado internals but I would not go that way as this is a security critical component we don't want to accidentally break.

If that was launched from jhub-apps you could presumably pass the JupyterHub auth token/cookie in the request to pass through the JupyterHub-level auth, right? Or is there a conflict because both Ragna and JupyterHub name the tokens the same way?

[krassowski]

In a sense, this looks like ragna should be a service with a service token (so that we are not passing the user auth token).

[dharhas]

Maybe the jhub-apps can launch the ragna backend as a 'service' and then the ragna frontend can be a regular app?

[dharhas]

A more general question is how does a user deploy rest api's that they want other apps on the platform to be able to use.