shinyauthr | R package with shiny authentication modules | Data Visualization library

Reason for the issue

The problem is by design as cyphr::key_sodium creates a key which is valid, well, only for the current session. That is, it is not possible to share it across different session let alone different systems.

Hence, the problem is not at all related to shinyitself, but to the fact that you are trying to use cyphr keys across different sessions.

From the vignette:

When using key_openssl, keypair_openssl, key_sodium, or keypair_sodium we generate something that can decrypt data. The objects that are returned by these functions can encrypt and decrypt data and so it is reasonable to be concerned that if these objects were themselves saved to disk your data would be compromised.

To avoid this, cyphr does not store private or symmetric keys directly in these objects but instead encrypts the sensitive keys with a cyphr-specific session key that is regenerated each time the package is loaded. This means that the objects are practically only useful within one session, and if saved with save.image (perhaps automatically at the end of a session) the keys cannot be used to decrypt data.

Reprex of the issue

As often happens in these cases, a lot of wrangling finally led to an answer but I will post my solution here in case anyone runs into a similar issue.

R2Evans was correct in that it can be called with credentials()$info. The issue was trying to use eventReactive, rather than simply reactive.

Reactive user details are collected via:

From your build output, as you've observed, the cache is indeed invalidated and you build a new image with the new contents of your directory. However, from the comments, you then run this container with a volume /app:/srv/shiny-server which will map access to this directory inside the container in /srv/shiny-server to the host at /app. Note that this path is an absolute path, rather than a relative path, so the files are on the host at /app rather than in your build directory in ./app.

Depending on your use case, there are various solutions. First, in the compose file, you have access to relative paths, so if you are testing locally (the typical reason to mount a volume), then you often want to mount the volume with a relative path like ./app:/srv/shiny-server. The result is the container runs with the contents of this directory without needing to rebuild the image, which is often preferred for faster development cycles.

If you do not want the volume mount, e.g. if this is in production and there's no need to access the files from outside of the container, then removing the volume mount from the compose file is preferred.

And lastly, if you need to have external access to these files, but you want them to be updated by the contents of your image, then you typically want to save the contents of the volume somewhere safe and update the volume with an entrypoint script. In my docker-base repo, I do this with the save-volume and load-volume scripts, one to run during the image build, and the other for during the entrypoint when running the container.

Using extendShinyjs()

You can easily manipulate the data you want to display: Here are several:

1. user_data only gives you back username

user_data <- reactive({credentials()$info[1]}) Because credentials()$info is just an array of characters, you can select only the first one: user name

1. renderTable only shows user name: You can do:

   output$user_table <- renderTable({ req(credentials()$user_auth) user_data()[1] })

or

output$user_table <- renderTable({ # use req to only render results when credentials()$user_auth is TRUE req(credentials()$user_auth) userData <-user_data() userData[1] })

Just by the same logic as the first one: at the end, user_data it is only some character you want to filter