Automatically delete token from cache once session ends

[hadley]

Using gmailr always makes me slightly nervous because if you get access to someone's email, you can basically do anything (since password resets are often handled via email). I don't think there's much of a risk of someone stealing my gmailr token, but it would be nice if we could automatically delete them once the current session is over.

[jennybc]

What are your current thoughts on this?

One thing that may have changed since you wrote this is the switch from .httr-oauth, lying around in current working directory, to a gargle-managed token cache that is more obscure.

But the basic facts around the power of having access to email still hold.

[jennybc]

This would complicate matters for folks who want to hold on to a token, so they can deploy something, e.g. a Shiny app. So if we introduce this, it has to come with ways to turn it on and off.

[hadley]

I do think this is mostly google's responsibility — for dangerous access levels like this it really should offer some time scoped option (i.e. allow access for the next 4 hours). But it still makes me nervous having that token sitting around, so a default option to session-scope it would be nice, I think.

[jennybc]

Maybe what you're proposing is just a different default for cache for gmailr-acquired user tokens. Instead of thinking of the request as "delete token from the cache", perhaps this is just "never put it in the cache in the first place"?

One way to implement that is to create gmailr_oauth_cache(), a variant on the gargle_oauth_cache() accessor, with different default behaviour. Then use that as the default in gm_auth() instead of gargle::gargle_oauth_cache():

gm_auth <- function(...,
#                   cache = gargle::gargle_oauth_cache(),
                    cache = gmailr_oauth_cache(),
                    ... { ... }

If the solution is not quite that simple, I think it should be implemented as a feature of the Gargle2.0 class, wired up to cache, which already has a sort of union type and could gain a way to express this desired behaviour. I think it could be implemented neatly through a finalizer for Gargle2.0: https://adv-r.hadley.nz/r6.html#finalizer.

[hadley]

Yeah, I like that idea — no caching to keep it session specific.