We are trying to use dask-labextension in proxy mode (ie, putting /proxy/8787 in the labextension search bar) within Open OnDemand. Labextension tabs should display graphs etc (and do in the case we use ssh portforwarding instead of the ondemand interface).
Labextension opens tabs in the workspace, but they remain blank and the browser console shows 403 errors opening websockets
How to reproduce
See dask/dask-labextension#176 - basically start a dask cluster, point the labextension at it and attempt to open one of the tabs (within Open OnDemand, or some other reverse proxy system where the Host header won’t match the origin).
Your personal set up
We are running jupyterlab instances through Open OnDemand, using a pip installed venv on Centos 8. OnDemand generates a config.py which includes c.NotebookApp.allow_origin = ‘*’ and c.NotebookApp.disable_check_xsrf = True
I’ve dug into the code quite a bit, and as far as I can tell the problem is that jupyter_server_proxy/websocket.py doesn’t override the check_origin WebSocketHandler method in the WebSocketHandlerMixin class. As a result, it falls back to the method in the base tornado class, which strictly checks that the Host header and the origin match. Because of the OnDemand reverse proxy setup we are using that won’t be the case.
For non-websocket traffic I think this ultimately gets handled by notebook/base/handlers.py IPythonHandler class (or possibly jupyter_server/base/handlers.py JupyterHandler), which overrides check_origin and simply returns True if allow_origin is set to ‘*’.
When I override the check_origin method in WebSocketHandlerMixin to always return True, the labextension works as expected. I expect that just cloning the code from notebook/base/handlers.py would work fine, but I’ve no idea if that would open up nasty security issues or something.
( I raised this as jupyterhub/jupyter-server-proxy#248 a little while back but I gather that isn’t the place to raise support issues).