Problem when {azkit} is used in deployment

[matt-dray]

The issue described in The-Strategy-Unit/nhp_compare_mitigation_predictions_app#191 (comment) appears to still be active, as per The-Strategy-Unit/tpma-explorer#4.

Basically a 403 in the logs when used on Connect.

[O-Mohammed]

Likewise, I had trouble with deploying to connect using the azkit::get_container() function.

Similarly to Matt, I replaced azkit::get_container() with a get_container() function found in nhp_outputs.

However, azkit::get_auth_token() worked perfectly for managing authorising the deployed app on connect.

63714fd

[O-Mohammed]

@matt-dray
I tried using your app from #52 to test my own deployment.

I found that the issue with authenticating seemed to be coming from azkit::get_container(), and specifically this part of it

azkit/R/get_container.R

Line 17 in 2429e29

container_names <- list_container_names(token)

If I remove container_names and any reference to it later in that function, everything works as expected.

This makes me (ignorantly) wonder, do our deployed apps have permission to list all blobs? Or is there something else going on with list_container_names()

[francisbarton]

After latest dev work on azkit is approved and merged, we might be able to explore this issue by passing different values to get_auth_token, such as playing with force_refresh/use_cache or by specifying different scopes to the resource argument, or by trying auth_method = "device_code"

[francisbarton]

Also note that in the help for AzureAuth::get_azure_token()/get_managed_token() we have

use_cache ...The default value of NULL means to use the cache only if AzureAuth is not running inside a Shiny app

so perhaps we need to use use_cache = TRUE and somehow manually set up a token in the cache for the app somewhere that AzureAuth will find it, or perhaps for Shiny apps we need to continue to use auth_method = "client credentials" with an app secret, or somehow use auth_method = "on_behalf_of" with a pre-existing token.