Since the last release (see this blog post), we received two interesting use cases for which we did not imagine ShinyProxy would be used.

First of all, we received a request to support other authentication methods than LDAP authentication. Whereas ShinyProxy is currently used primarily by larger organizations and companies that typically work with LDAP-based authentication systems, it seems people appreciate the elegance of the framework also for more small-scale use. In particular we received a request to support file-based authentication. Since all configuration of ShinyProxy was always dealt with in one single configuration file (the application.yml file), we decided to stick with this principle.

In order to make use of this novel functionality, you will need to specify the ‘simple’ authentication system as follows:

shiny:
  proxy:
    authentication: simple

and users (and groups for authorization) can now be specified as

shiny:
  proxy:
    users:
    - name: bert
      password: password
      groups: scientists
    - name: ernie
      password: password
      groups: mathematicians

Since there are now multiple systems to specify users and groups (for authorization), some configuration parameters were renamed to make these more generally applicable. When you specify your apps in the apps block e.g. the groups for authorization are no longer called ldap-groups but just groups. Similarly the specification of the admin groups, i.e. user groups that have access to the admin area for viewing and managing active sessions, have moved up in the YAML configuration from shiny.proxy.ldap to shiny.proxy.

If file-based authentication was the last feature on your mind for ShinyProxy, there is one nice side effect, though: you can now demonstrate ShinyProxy apps with authentication on a machine without internet connectivity (since there is no need any more to reach an LDAP server).

A second use case we worked on since last release relates to the usage of ShinyProxy as part of an architecture where Shiny applications are brought to end users inside web sites managed through content management systems (e.g. Drupal). Already early on (version 0.1.0) we had foreseen to disable authentication for this type of setup (authentication: none) where the CMS would handle authentication, but now there was a request to pass information from the CMS to the Shiny app. Shiny has a nice mechanism in place to pass arguments via URLs (see this article), and so we made sure ShinyProxy honored this mechanism in 0.7.5.

Documentation has been updated on the project homepage and as always community support on this new release is available on our support site.

We are already back to our keyboards to work on the next release, so keep the suggestions coming and have fun with ShinyProxy!