Open nathanweeks opened 5 years ago
Similarly, could an option be added to disable the HTTP Basic authentication in the rclone web ui? The Open OnDemand web portal already uses basic auth, and the additional authorization header from the rclone web ui appears to be conflicting with the authorization header for OOD.
Similarly, could an option be added to disable the HTTP Basic authentication in the rclone web ui? The Open OnDemand web portal already uses basic auth, and the additional authorization header from the rclone web ui appears to be conflicting with the authorization header for OOD.
Yes. We can add an option to disable the HTTP authentication. Rclone rcd already supports --rc-no-auth flag to achieve that, it just needs to be enabled in the web ui as well.
Is it currently possible to authenticate solely via POST? I'd like to make the rclone web UI available on our HPC cluster as an Open OnDemand Interactive App. The user will already be authenticated via the Open OnDemand when they launch an interactive app, and shouldn't have to authenticate again with a different username / password.
An approach used for an RStudio Server OOD interactive app is to generate a temporary password (which the user never sees) and set an environment variable that RStudio Server will use to determine the password when it launches. The user is presented a form with this password in a hidden field; when the user clicks the "Connect" button in this form, they are logged in without needing to authenticate again. Similarly for Jupyter Lab (except in this example, the temporary password is written to a config file).
It would be great if a similar approach could be used for the rclone web UI.
I think using your custom authentication, instead of the one provided by rclone will solve your problem. What do you think?
I think using your custom authentication, instead of the one provided by rclone will solve your problem. What do you think?
By default, the Open OnDemand portal uses HTTP Basic auth. But the interactive apps that are launched on a cluster compute node by a resource manager may be accessible to anyone who has SSH access to the cluster login node (using SSH port forwarding). So there should be some additional authentication mechanism to protect unauthorized access to the the rclone web UI (not HTTP Basic auth, unless it can be made to play nice with Open OnDemand's HTTP basic auth, which looks difficult?)
Currently, when I build an rclone Docker image from the nascent rclone Dockerfile and run it; e.g.:
docker run -it --rm -p 8080:8080 rclone:16e7da2 rcd --rc-web-gui --rc-addr :8080 --rc-user myuser --rc-pass mypass
I'm first greeted by an HTTP basic authentication dialog box, and then after entering myuser/mypass, I'm greeted by a web-form-based authentication that then prompts me to enter the same credentials, click "verify", and then click "Login". I'm not a web front-end developer, and might be way off, but I'd guess this form is sending the user name & password via POST, and setting a cookie with a session ID? If so, could form be "overridden" to allow authentication via POST from an Open OnDemand view connection form using well-defined POST variables like the aforementioned RStudio Server example?
FWIW, since rclone seems to be commonly used in HPC environments, and Open OnDemand seems to be an increasingly-popular platform for running graphical & web-based applications on HPC clusters, I think this would be a really cool use case. In some cases, it might be an alternative to Globus.
Is it currently possible to authenticate solely via POST? I'd like to make the rclone web UI available on our HPC cluster as an Open OnDemand Interactive App. The user will already be authenticated via the Open OnDemand when they launch an interactive app, and shouldn't have to authenticate again with a different username / password.
An approach used for an RStudio Server OOD interactive app is to generate a temporary password (which the user never sees) and set an environment variable that RStudio Server will use to determine the password when it launches. The user is presented a form with this password in a hidden field; when the user clicks the "Connect" button in this form, they are logged in without needing to authenticate again. Similarly for Jupyter Lab (except in this example, the temporary password is written to a config file).
It would be great if a similar approach could be used for the rclone web UI.