Open elipousson opened 10 months ago
The important thing to note here is that we are not using API keys but rather using access tokens which by design have an expiry unlike API keys. The only type of access token that can be refreshed non-interactively is the auth_code()
result—which is actually a really good thing to document for non-interactive workflows....
I know that httr2 allows for caching which I tried understanding once but despite a real attempt, failed (https://github.com/r-lib/httr2/issues/210). I think this should be explored before writing bespoke code that writes very sensitive information to disk.
Additionally, I think it should be a follow up to https://github.com/R-ArcGIS/arcgislayers/issues/128
I know we talked about it in https://github.com/R-ArcGIS/arcgislayers/issues/3, but think it makes sense to revisit adding keyring as an optional dependency and allowing that to be the mechanism for storing credentials. It will support the secure backend provided by the operating system, and allow the OS based password management interfaces to be used independently of R when useful and help minimize the chances of credential leaks from the environment table.
@elipousson, have you been able to retry the auth_user()
function? There was an issue with one of the request parametes. set_arc_token(auth_user())
is non-interactive and will let us read and write private content.
I know the ArcGIS authorization tokens expire but it is a PITA to have the set token disappear and require re-authentication every time I reset my session within R.
I have a revised, and re-revised version of the
tidycensus::census_api_key()
function that I've used as a token setting helper in several different packages. I'd be happy to reuse that code to implement similar features forset_auth_token()
. You can see that here: https://github.com/elipousson/standaloner/blob/main/R/standalone-settoken.RPotentially related to https://github.com/R-ArcGIS/arcgislayers/issues/128