Ensure other authentication options can be used

[LDSamson]

Addresses #33.

Creates different configuration options with and without shinymanager, so that other login options can be used. In case other login methods will be used, the user information will either be obtained directly from the shiny session (e.g. Posit connect deployment), or from the HTTP headers within the session (ShinyProxy deployment).

[jthompson-arcus]

Some comments and discussion starters...

Using golem::app_prod() in place of test_mode

We ran into issues trying to do this on a separate project. It mostly boiled down to the fact that how golem has this setup, a user has to opt-in to run the application in production mode (i.e. that have to set the option golem.app.prod to TRUE).

Configuration file

Perhaps we should consider using a separate configuration file for testing purposes. I think it's a little confusing to have both a test_shinymanager and a prod_shinymanager. Plus you have already set it up so that the file path can be set using the environmental variable CONFIG_PATH. Maybe we should make a test-config.yml.

[jthompson-arcus]

Does it make sense to allow these to be set in deployment when user_identification determines their value. Particularly in a case like shiny_session.

[LDSamson]

I do not completely follow here. To be set how exactly? Not in the golem-config.yml file, but somewhere else?

[LDSamson]

I agree that both a test_shinymanager and prod_shinymanager config might be confusing. The biggest difference is whether app_prod is set to 'yes'. We can just make one shinymanager config, with app_prod set to yes, and then temporarily set options(golem.app.prod = FALSE) in any test where that is needed.

Regarding the use of golem::app_prod() Would this problem still occur if users set their specific configuration, and we set the option app_prod in these? Since this will set the variable golem::app_prod() as well?

[jthompson-arcus]

I agree that both a test_shinymanager and prod_shinymanager config might be confusing. The biggest difference is whether app_prod is set to 'yes'. We can just make one shinymanager config, with app_prod set to yes, and then temporarily set options(golem.app.prod = FALSE) in any test where that is needed.

Regarding the use of golem::app_prod() Would this problem still occur if users set their specific configuration, and we set the option app_prod in these? Since this will set the variable golem::app_prod() as well?

The result of golem::app_prod() is not actually being set in the configuration file.

> golem::app_prod
function () 
{
    getOption("golem.app.prod") %||% FALSE
}
<bytecode: 0x0000021537725a20>
<environment: namespace:golem>

[LDSamson]

I agree that both a test_shinymanager and prod_shinymanager config might be confusing. The biggest difference is whether app_prod is set to 'yes'. We can just make one shinymanager config, with app_prod set to yes, and then temporarily set options(golem.app.prod = FALSE) in any test where that is needed.
Regarding the use of golem::app_prod() Would this problem still occur if users set their specific configuration, and we set the option app_prod in these? Since this will set the variable golem::app_prod() as well?

The result of golem::app_prod() is not actually being set in the configuration file.

> golem::app_prod
function () 
{
    getOption("golem.app.prod") %||% FALSE
}
<bytecode: 0x0000021537725a20>
<environment: namespace:golem>

Ah my bad, that is confusing!