rocker-org / rocker-versioned

Run current & prior versions of R using docker
https://hub.docker.com/r/rocker/r-ver
GNU General Public License v2.0
297 stars 169 forks source link

skip auth #99

Closed cboettig closed 6 years ago

cboettig commented 6 years ago

Do not insist on a password if authentication is turned off. (Follow-up on #303)

@dinvlad Can you take a look at this? I think this creates the behavior you have recommended. I've added an example rserver.conf to map, and when I test as follows:

docker build -t rstudio rstudio
docker run --rm -p 8787:8787 -v $(pwd)/rstudio/rserver.conf:/etc/rstudio/rserver.conf rstudio

This does bypass the error requested that enforces you to change the password and RStudio server comes up successfully with this in my testing. However, I might be doing something wrong with the rserver.conf script since with this I'm still asked for a username and password once I connect, and no password works (though the container still has rstudio set as the default password). I haven't used the auth-none option before to skip login, so maybe I'm missing something obvious here. Thanks!

dinvlad commented 6 years ago

Thanks, the issue is that you must also set the USER env variable for it to work (it's a limitation of RStudio itself, afaik).

cboettig commented 6 years ago

@dinvlad thanks, that sounds promising.

But I think a USER env var should already be defined(?): https://github.com/rocker-org/rocker-versioned/blob/70033e857ad8e5f4c52fafd69adca9d4a7d0913f/rstudio/userconf.sh#L4

cboettig commented 6 years ago

@dinvlad Okay, thanks, I see your point; if I do

docker run 
  --rm -p 8787:8787
  -e USER=rstudio 
  -v $(pwd)/rstudio/rserver.conf:/etc/rstudio/rserver.conf 
  rstudio

it works like a charm. Nice. (I guess my above script is just setting USER env var in the context of the bash script; of course it needs to be set for the session instead).

I'll go ahead and port this across the version stack and merge. Thanks again for this suggestion. I may add this trick to our documentation; though hopefully it won't get us back to bad practice (since it's not the default and not trivial to get to work, I think we'll be okay with the appropriate warnings).

dinvlad commented 6 years ago

Awesome, thanks! It would be nice to have it pass USER to the session as well, but not sure that's a priority for us. Thanks for the quick fix! Is there a timeline for image builds on GCR? :)

cboettig commented 6 years ago

@dinvlad latest and devel build nightly on docker-hub, so should pick this up in the next 24 hrs. tagged versions build monthly unless I tickle them.

I'm pondering whether it would make sense to enable this behavior as a separate env var, something like -e USE_INSECURE_LOGIN=true, rather than telling folks to map a rserver.conf and set -e USER. Might tempt users towards insecure options, but at least it would be very explicitly opt-in instead of a default that used an insecure password. Thoughts? Would that work for your setup?

dinvlad commented 6 years ago

That would make sense! Or we can name it DISABLE_AUTH or similar. I'd keep the ability to override USER if needed though (for a friendlier terminal prompt, for example).