You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been running this example successfully since ShinyProxy 2.6.0 with LDAP authentication (Microsoft Active Directory) and container-volumes mapping. It is also working fine with ShinyProxy 3.0.1. However, after I upgraded to ShinyProxy 3.1.0 and 3.1.1, this example failed to work. ShinyProxy can still authenticate with LDAP and spin up the RStudio-ide container but the new web page is blank. I can 'docker exec -it ... bash' into the RStudio-ide container and verify that DISABLE_AUTH=true, USER=proxyUserId from LDAP, WWW_ROOT_PATH=proxy.getRuntimeValue('SHINYPROXY_PUBLIC_PATH'). rserver process is up and running by rstudio-server, but there is no process for rsession.
For the same ShinyProxy configuration, the RStudio-ide example is working with ShinyProxy 2.6.0 and 3.0.1 and LDAP authentication. With ShinyProxy 3.1.0/3.1.1, I found that this example only works with LDAP authentication when there is no container-volumes mapping. When there is container-volumes mapping, it only works when ShinyProxy authentication mode is none or simple. My guess is there some new security check in ShinyProxy 3.1.0/3.1.1 that prevents the rserver process in the RStudio-ide container from launching an rsession process to serve the LDAP-authenticated user in the mapped volume.
The text was updated successfully, but these errors were encountered:
thien-bui-coherent
changed the title
RStudio/rsession is not launched when using LDAP
RStudio/rsession is not launched when using LDAP and container-volumes mapping
Oct 23, 2024
Hi, I cannot reproduce the problem in the way you describe.
For me volume mounts work fine, also when using LDAP. It's important that the volume is owned by uid 1000, especially when it's mounted as /home/rstudio. Otherwise the rstudio user inside the container, will not have access to it and startup of rstudio fails.
I actually use this mapping:
container-volumes: ["/remote/home/#{proxy.userId}/rstudiowork:/home/#{proxy.UserId}"]
The uid of proxy.userId is from LDAP and definitely not 1000.
This mapping works fine with ShinyProxy 2.6.0 and 3.0.2. It fails with 3.1.0 and 3.1.1.
Is there a way to disable this security enhancement in 3.1.x?
Is there a way to obtain the uid and gid from LDAP, i.e. #{proxy.UserUId}, #{proxy.UserGId}? so that I can pass them into the RStudio container and have it creating the user's account with matching uid/gid?
I've been running this example successfully since ShinyProxy 2.6.0 with LDAP authentication (Microsoft Active Directory) and container-volumes mapping. It is also working fine with ShinyProxy 3.0.1. However, after I upgraded to ShinyProxy 3.1.0 and 3.1.1, this example failed to work. ShinyProxy can still authenticate with LDAP and spin up the RStudio-ide container but the new web page is blank. I can 'docker exec -it ... bash' into the RStudio-ide container and verify that DISABLE_AUTH=true, USER=proxyUserId from LDAP, WWW_ROOT_PATH=proxy.getRuntimeValue('SHINYPROXY_PUBLIC_PATH'). rserver process is up and running by rstudio-server, but there is no process for rsession.
For the same ShinyProxy configuration, the RStudio-ide example is working with ShinyProxy 2.6.0 and 3.0.1 and LDAP authentication. With ShinyProxy 3.1.0/3.1.1, I found that this example only works with LDAP authentication when there is no container-volumes mapping. When there is container-volumes mapping, it only works when ShinyProxy authentication mode is none or simple. My guess is there some new security check in ShinyProxy 3.1.0/3.1.1 that prevents the rserver process in the RStudio-ide container from launching an rsession process to serve the LDAP-authenticated user in the mapped volume.
The text was updated successfully, but these errors were encountered: