This is a general PSA because I’ve seen a few different JupyterHub deployments get burned by this recently. The goal of this post is just to tie together a few issues, provide cross-links, and maybe help point folks in the right direction.
The rsession proxy project is what makes it possible for people to run RStudio on a JupyterHub. This is used by JupyterHub and Binder.
The problem with updating RStudio
However, the latest version of RStudio introduced a bug that that breaks the redirection, as documented in this issue:
opened 09:21PM - 10 Feb 21 UTC
closed 07:27PM - 30 Nov 21 UTC
bug
As mentioned in #95.
If the HTTP header X-Forwarded-Proto is being set, such … as by a proxy, rstudio-server will redirect users to /auth-sign-in?appUri=%2F rather than the full {base_url}/auth-sign-in?appUri=%2F. This will usually cause a 404. You can observe this behavior on mybinder.org for example, whereas it probably is not present on localhost.
I created https://github.com/rstudio/rstudio/issues/8888, however I don't see anything in rstudio's code that would cause this behavior. Perhaps we're not invoking rserver with the right combination of options.
When presented with the 404, a user can manually work around the problem by inserting the base path in front of the auth-sign-in path. For example on a jupyterhub, the user could change /auth-sign-in?appUri=%2F to /user/the-user-name/rstudio/auth-sign-in?appUri=%2F. Once corrected, rserver will properly authenticate the user and the user will be redirected to {base_url}/rstudio. Obviously we don't want the user to have to do this, but this observation helps to describe the problem.
If we remove the header from the HTTP request, the Location header returned by rstudio server uses http protocol and has the correct path. So this might not be appropriate on https sites. If we intercede and set the value of the header to https instead of https,http, the header value uses https:// rather than http://.
The argument against filtering out the header is that if rserver ever requires https, not having the header could lead to a redirect loop. I found a [nice explanation](https://community.pivotal.io/s/article/Purpose-of-the-X-Forwarded-Proto-HTTP-Header?language=en_US) of this.
@manics also [described](https://github.com/jupyterhub/jupyter-rsession-proxy/issues/95#issuecomment-730652754) past experience with the header.
We might be able to workaround this issue by setting our url to /rstudio/auth-sign-in?appUri=%2F instead of /rstudio. If you've already been authenticated by rserver, then this just takes the user back to /rstudio/. I'd have to experiment but I think it'd work just fine.
and discussed re: Binder here:
opened 09:21PM - 20 May 21 UTC
bug
### Bug description
Pinning the R version to 4.0 using `runtime.txt` on `mybi… nder.org` does not work – I get R 4.1 instead.
#### Expected behaviour
I expect R version 4.0.5 ("Shake and Throw"):
```
> R.version.string
[1] "R version 4.0.5 (2021-03-31)"
```
#### Actual behaviour
I get R version 4.1.0 ("Camp Pontanezen"):
```
> R.version.string
[1] "R version 4.1.0 (2021-05-18)"
```
### How to reproduce
1. Set up a repository with the following [`runtime.txt`](https://gitlab.com/fkohrt/RMarkdown-sandbox/-/blob/f5d8582b/binder/runtime.txt):
```runtime.txt
r-4.0-2021-05-19
```
2. [](https://gke.mybinder.org/v2/gl/fkohrt%2FRMarkdown-sandbox/f5d8582b?urlpath=rstudio)
### Your personal set up
I am using the `mybinder.org` service.
Versions:
- `jupyterhub --version`: `1.3.0`
- `python --version`: `Python 3.7.10`
<details><summary>Full environment</summary>
```
aiohttp==3.7.4.post0
alembic @ file:///home/conda/feedstock_root/build_artifacts/alembic_1613901514078/work
anyio @ file:///home/conda/feedstock_root/build_artifacts/anyio_1612745536224/work/dist
argon2-cffi @ file:///home/conda/feedstock_root/build_artifacts/argon2-cffi_1602546578258/work
async-generator==1.10
async-timeout==3.0.1
attrs @ file:///home/conda/feedstock_root/build_artifacts/attrs_1605083924122/work
Babel @ file:///home/conda/feedstock_root/build_artifacts/babel_1605182336601/work
backcall @ file:///home/conda/feedstock_root/build_artifacts/backcall_1592338393461/work
backports.functools-lru-cache==1.6.1
bleach @ file:///home/conda/feedstock_root/build_artifacts/bleach_1612213472466/work
blinker==1.4
brotlipy==0.7.0
certifi==2020.12.5
certipy==0.1.3
cffi @ file:///home/conda/feedstock_root/build_artifacts/cffi_1613413867554/work
chardet @ file:///home/conda/feedstock_root/build_artifacts/chardet_1610093487176/work
cryptography @ file:///home/conda/feedstock_root/build_artifacts/cryptography_1612993734132/work
decorator==4.4.2
defusedxml==0.6.0
entrypoints @ file:///home/conda/feedstock_root/build_artifacts/entrypoints_1602701733603/work/dist/entrypoints-0.3-py2.py3-none-any.whl
idna @ file:///home/conda/feedstock_root/build_artifacts/idna_1593328102638/work
importlib-metadata @ file:///home/conda/feedstock_root/build_artifacts/importlib-metadata_1610355166636/work
ipykernel @ file:///home/conda/feedstock_root/build_artifacts/ipykernel_1613852948592/work/dist/ipykernel-5.5.0-py3-none-any.whl
ipython @ file:///home/conda/feedstock_root/build_artifacts/ipython_1612487002309/work
ipython-genutils==0.2.0
ipywidgets @ file:///home/conda/feedstock_root/build_artifacts/ipywidgets_1609995587151/work
jedi @ file:///home/conda/feedstock_root/build_artifacts/jedi_1610146791823/work
Jinja2 @ file:///home/conda/feedstock_root/build_artifacts/jinja2_1612119311452/work
json5 @ file:///home/conda/feedstock_root/build_artifacts/json5_1600692310011/work
jsonschema==3.2.0
jupyter-client @ file:///home/conda/feedstock_root/build_artifacts/jupyter_client_1610375432619/work
jupyter-core @ file:///home/conda/feedstock_root/build_artifacts/jupyter_core_1612125257337/work
jupyter-offlinenotebook @ file:///home/conda/feedstock_root/build_artifacts/jupyter-offlinenotebook_1610833110941/work
jupyter-resource-usage @ file:///home/conda/feedstock_root/build_artifacts/jupyter-resource-usage_1608550684149/work
jupyter-rsession-proxy @ https://github.com/jupyterhub/jupyter-rsession-proxy/archive/d5efed5455870556fc414f30871d0feca675a4b4.zip
jupyter-server @ file:///home/conda/feedstock_root/build_artifacts/jupyter_server_1613709403212/work
jupyter-server-proxy==1.4.0
jupyter-shiny-proxy @ https://github.com/ryanlovett/jupyter-shiny-proxy/archive/47557dc47e2aeeab490eb5f3eeae414cdde4a6a9.zip
jupyter-telemetry @ file:///home/conda/feedstock_root/build_artifacts/jupyter_telemetry_1605173804246/work
jupyterhub @ file:///home/conda/feedstock_root/build_artifacts/jupyterhub-feedstock_1607688225833/work
jupyterlab @ file:///home/conda/feedstock_root/build_artifacts/jupyterlab_1612296988614/work
jupyterlab-pygments @ file:///home/conda/feedstock_root/build_artifacts/jupyterlab_pygments_1601375948261/work
jupyterlab-server @ file:///home/conda/feedstock_root/build_artifacts/jupyterlab_server_1613760084674/work
jupyterlab-widgets @ file:///home/conda/feedstock_root/build_artifacts/jupyterlab_widgets_1609173350931/work
Mako @ file:///home/conda/feedstock_root/build_artifacts/mako_1610659158978/work
MarkupSafe @ file:///home/conda/feedstock_root/build_artifacts/markupsafe_1610127564475/work
mistune @ file:///home/conda/feedstock_root/build_artifacts/mistune_1610112870915/work
multidict==5.1.0
nbclassic @ file:///home/conda/feedstock_root/build_artifacts/nbclassic_1610352513187/work
nbclient @ file:///home/conda/feedstock_root/build_artifacts/nbclient_1612903843315/work
nbconvert @ file:///home/conda/feedstock_root/build_artifacts/nbconvert_1605401831777/work
nbformat @ file:///home/conda/feedstock_root/build_artifacts/nbformat_1611005694671/work
nbgitpuller==0.9.0
nest-asyncio @ file:///home/conda/feedstock_root/build_artifacts/nest-asyncio_1605195931949/work
notebook @ file:///home/conda/feedstock_root/build_artifacts/notebook_1610575319689/work
nteract-on-jupyter==2.1.3
oauthlib==3.0.1
packaging @ file:///home/conda/feedstock_root/build_artifacts/packaging_1612459636436/work
pamela==1.0.0
pandocfilters==1.4.2
parso @ file:///home/conda/feedstock_root/build_artifacts/parso_1607618318316/work
pexpect==4.8.0
pickleshare @ file:///home/conda/feedstock_root/build_artifacts/pickleshare_1602535628301/work
prometheus-client @ file:///home/conda/feedstock_root/build_artifacts/prometheus_client_1605543085815/work
prompt-toolkit @ file:///home/conda/feedstock_root/build_artifacts/prompt-toolkit_1613068548426/work
psutil @ file:///home/conda/feedstock_root/build_artifacts/psutil_1610127094245/work
ptyprocess @ file:///home/conda/feedstock_root/build_artifacts/ptyprocess_1609419310487/work/dist/ptyprocess-0.7.0-py2.py3-none-any.whl
pycparser @ file:///home/conda/feedstock_root/build_artifacts/pycparser_1593275161868/work
pycurl==7.43.0.6
Pygments @ file:///home/conda/feedstock_root/build_artifacts/pygments_1613412098605/work
PyJWT @ file:///home/conda/feedstock_root/build_artifacts/pyjwt_1610910308735/work
pyOpenSSL @ file:///home/conda/feedstock_root/build_artifacts/pyopenssl_1608055815057/work
pyparsing==2.4.7
pyrsistent @ file:///home/conda/feedstock_root/build_artifacts/pyrsistent_1610146801408/work
PySocks @ file:///home/conda/feedstock_root/build_artifacts/pysocks_1610291444829/work
python-dateutil==2.8.1
python-editor==1.0.4
python-json-logger @ file:///home/conda/feedstock_root/build_artifacts/python-json-logger_1602545356084/work
pytz @ file:///home/conda/feedstock_root/build_artifacts/pytz_1612179539967/work
pyzmq @ file:///home/conda/feedstock_root/build_artifacts/pyzmq_1613478743724/work
requests @ file:///home/conda/feedstock_root/build_artifacts/requests_1608156231189/work
ruamel.yaml @ file:///home/conda/feedstock_root/build_artifacts/ruamel.yaml_1610291373612/work
ruamel.yaml.clib @ file:///home/conda/feedstock_root/build_artifacts/ruamel.yaml.clib_1610146839777/work
Send2Trash==1.5.0
simpervisor==0.4
six @ file:///home/conda/feedstock_root/build_artifacts/six_1590081179328/work
sniffio @ file:///home/conda/feedstock_root/build_artifacts/sniffio_1610318316464/work
SQLAlchemy @ file:///home/conda/feedstock_root/build_artifacts/sqlalchemy_1612225082967/work
terminado @ file:///home/conda/feedstock_root/build_artifacts/terminado_1609794176029/work
testpath==0.4.4
tornado @ file:///home/conda/feedstock_root/build_artifacts/tornado_1610094704591/work
traitlets @ file:///home/conda/feedstock_root/build_artifacts/traitlets_1602771532708/work
typing-extensions @ file:///home/conda/feedstock_root/build_artifacts/typing_extensions_1602702424206/work
urllib3 @ file:///home/conda/feedstock_root/build_artifacts/urllib3_1611695416663/work
wcwidth @ file:///home/conda/feedstock_root/build_artifacts/wcwidth_1600965781394/work
webencodings==0.5.1
widgetsnbextension @ file:///home/conda/feedstock_root/build_artifacts/widgetsnbextension_1603129364725/work
yarl==1.6.3
zipp @ file:///home/conda/feedstock_root/build_artifacts/zipp_1603668650351/work
```
</details>
### Related information
Explicitly demanding R 4.1 using the following [`runtime.txt`](https://gitlab.com/fkohrt/RMarkdown-sandbox/-/blob/825db203/binder/runtime.txt)…
```runtime.txt
r-4.1-2021-05-20
```
…does not work (which [makes sense](https://github.com/jupyterhub/repo2docker/blob/b66caf6/repo2docker/buildpacks/r.py#L61-L96)):
```
Error during build: Version '4.1' of R is not supported.
```
Try here: [](https://gke.mybinder.org/v2/gl/fkohrt%2FRMarkdown-sandbox/825db203?urlpath=rstudio)
This bug is documented in this RStudio issue:
opened 03:41AM - 04 Feb 21 UTC
bug
qa repro
authentication
backlog
I'm using rserver in a jupyterhub single user environment with jupyter-server-pr… oxy and a [patched jupyer-rsession-proxy](https://github.com/ryanlovett/jupyter-rsession-proxy/tree/www_root_path) with --www-root-path support. If X-Forwarded-Proto is set in the http headers, when a user visits the proxied path to rstudio for the first time, rserver will set the Location header to /auth-sign-in?appUri=%2F, even if www-root-path is set.
### System details
RStudio Edition : Server
RStudio Version : 1.4.1522
OS Version : Ubuntu 20.04
R Version : 4.0.3
### Steps to reproduce the problem
0. Have a proxy which happens to set X-Forwarded-Proto. This is present on mybinder.org for example. In my case I have an ssl terminating nginx proxy in front of jupyterhub that is setting it.
1. Invoke rserver in a user environment on a jupyterhub, e.g. `rserver --auth-none=1 --www-frame-origin=same --www-port=56789 --www-verify-user-agent=0 --database-config-file=/tmp/tmp_nt578pw --www-root-path=/user/me/proxy/56789/`
2. Visit {hub_url}/user/me/proxy/56789/
3. The user is redirected to {hub_url}/auth-sign-in?appUrk=%2F which produces a 404.
If one issues a curl request to {hub_url}/user/me/proxy/56789/ with all of the same headers except for X-Forwarded-Proto, the user is properly redirected the first time they visit the path to rstudio.
### Describe the problem in detail
With --www-root-path set to `/user/so-and-so/proxy/{some_port_num}/`, the user gets redirected to /auth-sign-in?appUri=%2F and not {www_root_path}/auth-sign-in?appUri=%2F. The former causes a 404.
### Describe the behavior you expected
The user is redirected to {hub_url}/{www_root_path}/auth-sign-in?appUri=%2F or just /{www_root_path}/auth-sign-in?appUri=%2F.
<!--
Please keep the below portion in your issue, and check `[x]` the applicable boxes.
-->
- [x] I have read the guide for [submitting good bug reports](https://github.com/rstudio/rstudio/wiki/Writing-Good-Bug-Reports).
- [x] I have installed the latest version of RStudio, and confirmed that the issue still persists.
- [x] If I am reporting a RStudio crash, I have included a [diagnostics report](https://support.rstudio.com/hc/en-us/articles/200321257-Running-a-Diagnostics-Report).
- [x] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
but thus far it seems like it won’t be a priority for them to fix for some time.
The problem with updating R 4.1
If you pin RStudio to 4.0, and continue updating the base R version, you’ll get an error about visualizations not working in RStudio and the visualizations won’t work. See this issue for one example of this problem:
opened 11:04AM - 21 May 21 UTC
### Bug description
[RStudio v1.2.5001](https://github.com/jupyterhub/repo2do… cker/blob/81e1e39/repo2docker/buildpacks/_r_base.py#L7-L10) does not support the R graphics engine v14 that comes with R v4.1.0 ("Camp Pontanezen") (see [release notes](https://stat.ethz.ch/pipermail/r-announce/2021/000670.html)).
#### Expected behaviour
No warning message.
#### Actual behaviour
```
Warning message:
R graphics engine version 14 is not supported by this version of RStudio. The Plots tab will be disabled until a newer version of RStudio is installed.
```
### How to reproduce
1. [](https://gke.mybinder.org/v2/gl/fkohrt%2FRMarkdown-sandbox/f5d8582b?urlpath=rstudio) ([source repo](https://gitlab.com/fkohrt/RMarkdown-sandbox/-/tree/f5d8582b))
2. Enter `R.version.string` (leading `R version 4.1.0 (2021-05-18)`)
3. Get warning message
### Your personal set up
Using `mybinder.org`.
### Related information
See also rstudio/rstudio#8383.
What to do
Right now, there is no workaround that I know of for getting RStudio 4.1 to work on JupyterHub until [rserver auth redirect doesn't use www root path when X-Forwarded-Proto is set · Issue #8888 · rstudio/rstudio · GitHub ] is resolved.
Your best bet is to pin R to v 4.0, that way an old version of RStudio works properly.
This issue discusses this in some detail, but it’s unclear to me what is the right path forward there: Pinning R 4.0 with runtime.txt on mybinder.org not working as expected · Issue #1077 · jupyterhub/repo2docker · GitHub
Do you know any other workarounds?
I know that’s not ideal - if anybody knows of another workaround for either JupyterHub or Binder please do share! We should update this thread if there’s a better solution that comes up.
1 Like
Hi @choldgraf thanks for raising this issue. In broad terms: I agree with your suggestion to use older versions of R for now, that seems to work for our newly updated Binder instance of the open source book Geocomputation with R: Binder
To see how I got this working again, see the .binder file of the associated repo.
Key to that approach is putting the following in environment.yml
which uses the ‘r-conda’ version of R which is behind the latest version of R it seems:
name: geocompr
channels:
- conda-forge
- bioconda
- r
dependencies:
- r-base
A couple of questions:
Is that stable and any ideas when ‘r-base’ in that set-up will switch?
Could using a different graphics driver solve the issue? I’m thinking of ragg
1 Like
Here’s the code. Any comments on this welcome, I’m not sure if the ‘start’ file is needed… geocompr/.binder at main · Robinlovelace/geocompr · GitHub
jupyter-rsession-proxy version 2.0 fixes this! So latest RStudio now works again with jupyterhub. See A template repository for running latest RStudio + R on mybinder.org / your JupyterHub for an example.
You’ll need to make sure you’re on R 4.1, and jupyter-rsession-proxy >= 2.0.
Massive thanks to @ryanlovett and maresb for making this happen!
3 Likes
Amazing - thanks to all the folks that helped make this happen
Hello, I am getting a problem that could be related with this, I am using jupyterhub on kubernetes and when I build an image using older R version, it works correctly: I login to jupyterhub, a jupyterlab instance is launched and I can from there launch Rstudio and it appears in another tab as expected.
But when I try building an image with R 4.1 or greater, when I select Rstudio from the options on jupyterlab launch menu, it redirects to “https://access/user/\ <my username>/rstudio/auth-sign-in?appUri=%2F” and page not found error appears on the browser.
I checked and I am using jupyter-rsession-proxy version 2.0.1 on the single user image, this is from the jupyterlab terminal:
luciano@jupyter:~$ pip show jupyter-rsession-proxy
Name: jupyter-rsession-proxy
Version: 2.0.1
Summary: Jupyter extension to proxy RStudio
Home-page: https://github.com/jupyterhub/jupyter-rsession-proxy
Author: Ryan Lovett & Yuvi Panda
Author-email: UNKNOWN
License: UNKNOWN
Location: /srv/conda/envs/notebook/lib/python3.7/site-packages
Requires: jupyter-server-proxy
Required-by:
Probably I am missing something, but I cant find the issue.
If someone knows what I am doing wrong, maybe can help me
Thanks in advance!
Luciano
1 Like
Sorry, Its not solved, in my case
Having the same issue here. Using a daily build since JupyterLab images are on jammy
: Ubuntu 22 .