Shiny App with OOD

Get Help
1

We have an user request to set up Shiny. I feel like OOD may be the best way to go.

OSC has an example Shiny app but based on Eric’s reply to TensorBoard for Open OnDemand, Stanford’s Tensorboard approach may be better for the authentication.

Before I dive into this, could perhaps Eric or Kilian comment on what they think about this?

Thanks,
MC

2

Hi,

I tried to use the tensorboard auth approach for shiny, but it didn’t work. It seems that
shiny uses websocket but the python proxy didn’t seem to support that. We (Boston University) ended up
using the OSC app with only a few site specific changes.

–Mike Dugan

1 Like
3

Thanks Mike, good to know, that will save me some time.

4

This is not quite an OOD question, rather a R Shiny, or nginx question, but, I am hoping someone else who set up the Shiny with OOD may have something to say.

I installed the OSC’s Shiny app (slightly massaged like Mike did) but also noticed that I can run the Shiny app from our RStudio OOD app, which uses R based on Rocker’s Docker container. Presumably Rocker comes with the R shiny library installed.

The RStudio approach is not as simple since one has to, in the RStudio command line, run:
library(‘shiny’)
runApp(“newdir”) - where “newdir” is the directory where app.R resides

while in the Shiny OOD app the user just puts the path to the Shiny app (“newdir”) to a box in a web form, but, I am wondering if there’s any other advantage of running the Shiny OOD app (which runs the Shiny using nginx from the openresty container). The extra nginx instance does put some weight on.

I thought that one could use the nginx from openresty to authenticate to the running Shiny app, but, the credentials are set through the template/script.sh so they are not visible to the user. So, apart from not having to run through the RStudio I am not seeing any other advantage of having a separate Shiny OOD app.

Thanks,
MC

5

I’m not familiar with Rocker or how RStudio provides access to the Shiny app that is launched from RStudio, but my understanding is if you execute runApp without specifying the port, a random port will be used and it would be unauthenticated.

The purpose of the OpenResty process is to provide a sidecar proxy that adds authentication. The reason the credentials are not exposed directly to the user is they are managed by the OnDemand app itself, so when the connect button is presented to the user, they click connect and the credentails are used to allow proxying through to the Shiny app.

OpenResty/NGINX was chosen for two reasons: it can easily be configured to handle websocket traffic and can proxy to a unix domain socket, which a Shiny app can be configured to listen on. And it was something we knew so it was the easiest step to take.

Eventually we would like to find a similar but lighter weight solution for most of the apps we launch in OnDemand, because without it the problem of authentication must be solved for each app, and often using the app’s built in authentication mechanism results in a sub-optimal solution.

As for the advantage of having a Shiny OOD app, there are several potential applications, but they may not fit your use case.

At OSC, we use it to turn launching a Shiny reporting app with a particular dataset into a button click from the web interface. So these apps can be a way to provide access to visualization of data with the end user not actually having to have any understanding of R or RStudio to use.

Also, in a future where there is tighter integration between file management and launching of interactive apps, you could imagine two different use cases:

  1. select a shiny app directory in the files app, and click “launch” to launch it via a batch job
  2. select a dataset and click “visualize in shiny app x” where x is some shiny app that has been associated with that dataset
6

Thanks for the explanation Eric, this makes sense. The first of the two future cases sounds quite appealing.

In our case, the user wants to share his Shiny apps with others. This should work if he makes his app world readable and gives the path to the app’s directory - which the other user enters in the web interface.

Though, he also wants external people to run the app, which is something that they won’t be able to do in OOD, so, he may have to resort (pay for) a VM that we can set up for him, and where they can control their users themselves (the VM would be fairly detached from the rest of our infrastructure so their external users could not access our fileservers, …).

I was thinking that the OpenResty/NGINX will somehow allow external users to access a running Shiny app, if the internal user who runs the app gives them the authentication pieces, but, that would essentially give non-users access to our clusters which I am sure no admin here would like.