Redirect client to auth-sign-in when not authenticated

[ryanlovett]

We need to be aware of when the user is not authenticated and then redirect them to /rstudio/auth-sign-in on their behalf. Otherwise rstudio will send the user to the wrong URL, a top-level /auth-sign-in, which in a hub/binder environment is the hub/binder server and will wind up as a 404. In order to do this, we need to subclass SuperviseAndProxyHandler so that we can override the GET method.

We recently worked around this by modifying the launcher path, however the server maybe be started by other means, such as with nbgitpuller, and that doesn't use the clickable launcher.

[ryanlovett]

Regressions wrt/ jupyter-server-proxy's entrypoints:

• no jupyterlab support

[dhirschfeld]

I'm keen to get this in so I can try it out with our infra. Are there any blockers to getting this merged?

[ryanlovett]

@dhirschfeld I need to figure out how to publish this on npmjs, or wherever labextensions hang out. This is so that a command like jupyter labextension install @jupyterlab/rsession-proxy will work. I've tested this PR out on binder in https://github.com/ryanlovett/binder-rsession/tree/subclass by installing from source

npm install
npm run build
jupyter labextension link .

and that works fine. I don't really know anything about typescript or the lab dev tools, so I hope the packaging process doesn't reveal any problems.

Once I figure out the labextension publishing, I think I need to ask the folks who manage the jupyterlab org/project/umbrella at npmjs to adopt it. They may require that publishing be tied to CI, I dunno. If I manage to publish it, even if initially not under an official Jupyter heading, I can ask you and some other folks to try it out.

[dhirschfeld]

At least with the JL3 you can deploy an extension as a pre-built (federated) extension so you don't have to publish to npm unless you want to support JL2. With JL3 you can simply pip/conda install an extension without a separate jupyter lab build step! :tada:

Unfortunately I don't know any of the details of how to package a JL extension but a good place to start would probably be the official cookiecutter:

• https://jupyterlab.readthedocs.io/en/stable/extension/extension_tutorial.html#packaging-your-extension
• https://github.com/jupyterlab/extension-cookiecutter-ts/blob/3.0/%7B%7Bcookiecutter.python_name%7D%7D/setup.py#L75-L85

[ryanlovett]

Oh, great tip, thanks! I'll try this out.

[ryanlovett]

@dhirschfeld It seems that this PR already works when one runs pip install, probably because I had copied jupyter-server-proxy's JL3 support.

See https://github.com/ryanlovett/binder-rsession/blob/subclass/Dockerfile, and try lab from within https://mybinder.org/v2/gh/ryanlovett/binder-rsession/subclass.

[JamesSample]

Brilliant! 🎉 This is now working for me on Google Cloud (currently using JupyterLab 3.0.16, R-Studio 1.4.1717 and R 4.1.0).

Installed using

RUN pip install jupyter_packaging

WORKDIR /tmp
ENV SHA a07aa77
RUN git clone https://github.com/ryanlovett/jupyter-rsession-proxy
WORKDIR /tmp/jupyter-rsession-proxy
RUN git checkout $SHA
RUN pip install . 

As in the Dockerfile linked above.

Many thanks @ryanlovett for getting this sorted 👍 Your efforts are very much appreciated!

[ryanlovett]

@yuvipanda Fixed, thanks! Shall I merge and push out a new release?

[yuvipanda]

@ryanlovett let's deploy this on the berkeley hubs for a bit before making a release?

[ryanlovett]

So this works on binder when there is no user-id cookie set, but it does not work on a hub when the cookie is set but invalid. I think there will need to be another approach. @yuvipanda suggested jupyterhub/jupyter-server-proxy#209 as a possible way of rewriting rstudio server's redirection.

[JamesSample]

Interesting. For what it's worth, this seems to have fixed the problem for me running on JupyterHub (no 404s reported by any users since installing from your branch yesterday afternoon). This is JupyterHub 1.3 and version 0.11.1 of the Helm chart.

[ryanlovett]

Thanks for that feedback @JamesSample. Had people successfully used rstudio on that hub previously, thereby causing a user-id cookie to be set in their browser? If not, it would explain why they are now successful. With this PR, if rstudio server ever deems that the cookie is set but invalid, it would also cause a 404.

[meeseeksmachine]

This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/psa-latest-rstudio-will-not-work-with-jupyterhub-or-binder-use-r-version-4-0/10957/4

[sauloal]

This worked for me:

RUN pip install jupyter-server-proxy
RUN pip install jupyter-rsession-proxy
RUN pip install jupyter-shiny-proxy

RUN jupyter labextension install @jupyterlab/server-proxy

ENV RSESSION_PROXY_RSTUDIO_1_4=1

USER root

RUN apt update && \
    apt install -y apt-utils && \
    apt install -y gdebi-core && \
\
    wget https://download2.rstudio.org/server/bionic/amd64/rstudio-server-2021.09.0-351-amd64.deb -O /tmp/rstudio-server.deb && \
    gdebi -n /tmp/rstudio-server.deb && \
    rm /tmp/rstudio-server.deb && \
\
    wget https://download3.rstudio.org/ubuntu-14.04/x86_64/shiny-server-1.5.17.973-amd64.deb -O /tmp/shiny-server.deb && \
    gdebi -n /tmp/shiny-server.deb && \
    rm /tmp/shiny-server.deb && \
\
    apt clean all && \
    rm -rf /var/lib/apt/lists/*

RUN usermod -a -G rstudio-server ${NB_USER}

USER root

RUN echo "server-user=$NB_USER" >> /etc/rstudio/rserver.conf \
&&  rm -rf /var/log/rstudio-server \
&&  rm -rf /var/lib/rstudio-server \
&&  rm -rf /tmp/rstudio-rsession \
&&  rm -rf /tmp/rstudio-rserver

USER ${NB_UID}

[juliusvonkohout]

@ryanlovett https://github.com/jupyterhub/jupyter-server-proxy/pull/209 does this mean that a solution is close? Or is this the way to go forward https://github.com/jupyterhub/jupyter-rsession-proxy/pull/108 ?

[ryanlovett]

@juliusvonkohout I believe that rewriting rstudio's response is a good solution and PRs https://github.com/jupyterhub/jupyter-server-proxy/pull/300 and https://github.com/jupyterhub/jupyter-rsession-proxy/pull/108 work (so a solution is close!), however https://github.com/jupyterhub/jupyter-server-proxy/pull/301 is also being discussed.

We intend to have something working in place for the start of our Spring semester in mid-January.

[yuvipanda]

Closing in favor of https://github.com/jupyterhub/jupyter-rsession-proxy/pull/110