Register JupyterHub as xdg-open handler

JupyterHub
1

If a command running in the terminal needs to open a browser tab (such as to complete an OAuth flow), it usually uses xdg-open to open the URL. This does not work in a terminal running in JupyterHub because the user is not directly exposed to a graphical desktop. Is there a way to register JupyterHub as a handler of xdg-open, so that the URL is opened clientside?

For example, if I am using JupyterLab through JupyterHub, I open the terminal and enter xdg-open https://jupyter.org, I get this output:

$ xdg-open https://jupyter.org
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening 'https://jupyter.org'
2

I think you could do it by writing a JupyterLab extension (JupyterHub shouldn’t be relevant, the issue will occur regardless of how you start a remote notebook). The UI component (JavaScript) would wait for the backend to send a URL, and open a new tab with that URL. The backend (server) component would wait for a trigger from a xdg-open helper, and pass that to the front-end.

3

This is actually a good point. I noticed that this worked fine locally (when running JupyterLab), but not when running remotely (I was using JupyterHub). But any JupyterLab instance where the client and the server are not running the same environment, not just one launched from JupyterHub, should have the same issue. In fact, a locally running JupyterHub instance should not have this issue either.