Closed vgherard closed 2 years ago
There are several different ways to do this, but I normally put my API key in a "config.yml" file and read it in using the {config} package. Like so:
# global.R
app_config <- config::get()
polished::global_sessions_config(
app_name = "my_app",
api_key = app_config$polished_api_key
)
Make sure to add "config.yml" to your ".gitignore" file so that you don't track it on GitHub.
Thanks Andy for your suggestion, understood.
I'm wondering whether it would make sense for you guys to define more than one API token, with different levels of permissions (such as a token for 'admin' tasks - add/deploy app etc. - and a token for login requests). I don't know if that could complicate things, but from the user point of view it looks like an extra security layer, imho. Just throwing in some random idea :-)
Anyway, feel free to close this.
Cheers!
Multiple API keys is more complicated than what we are looking for with polished. Thanks for the suggestion.
Hello! I was looking for a simple solution to add an authentication layer to my shiny apps and came across Polished, which I am trying out and looks very cool.
Right now I’m just hosting a few applications on shinyapps.io, and I have a rather basic question: is there any way I can avoid hardcoding my Polished API key into the apps (that is, into
polished::global_sessions_config()
)? And, if not, would there be any intrinsic vulnerability behind this "naive" approach?Thanks in advance! Valerio
To clarify: besides the major concern of having my API key shown in my apps source (which I don't know to which extent represents a vulnerability), I also worry about more trivial things, like accidentally sharing the code on a public repository, etc.etc.