Authorization has recently broken about googledrive

[jennybc]

The bottom line is that the OAuth client needs to match in these two contexts (along with other token details, such as the target user, scopes, etc.):

• The context where you interactively obtain and cache the token
• The context where you want to non-interactively rediscover and refresh the token

The tricky bit to appreciate is that the default OAuth client varies with the computing environment:

• On a local computer, the default is a tidyverse client, of the "installed" type
• On RStudio Server, Posit Workbench/Connect/Cloud, and Google Colab, the default is a tidyverse client, of the "web" type

So, to ensure client matching, you probably need to explicitly specify the client type on one end, to match the other.

If you've got something working, then godspeed.

[jennybc]

I can tell you are using an OAuth client of the "installed" or "Desktop app" type, which is likely no longer going to work in a cloud setting.

oauth client name: tidyverse-clio
oauth client name: installed

(that second debugging message should read "oauth client type", oops)

Can you say more about the context and computing environment?

What is the process you are using to put that token into the .secrets cache?

Overall this feels like you've gotten a token in one (non-cloud?) context and are then trying to use it in a cloud context. And since we default to OAuth clients of a different type in those two settings, it's causing the cache miss. I just need to understand your situation better to advise on what to do.

[quantitative-technologies]

Ah, I misunderstood the documentation. I interpreted it to mean that if there is a single token in the cache then it must match.

You are correct about my process. The token was generated using googledrive on my local machine, and I just added it to .secrets using git. Then it is failing to match in the cloud. I cannot generate the token in the cloud anymore, because Rstudio server no longer works there.

Is there a way to generate a token locally that will match, or to instruct the cloud to accept the locally generated token?

[jennybc]

In the code that needs to use a cached token (originally obtained on your local computer) in a cloud context, you'll want to set some options:

options(
  gargle_oauth_cache = ".secrets",
  gargle_oauth_email = TRUE,
  gargle_oauth_client_type = "installed"
)

Or you can intentionally use the OAuth client of "web" type locally, which is a clunkier flow, but still works, when you first capture the token:

options(
  gargle_oauth_cache = ".secrets",
  gargle_oauth_client_type = "web"
)
# obtain a token interactively HERE

in which case you would delete gargle_oauth_client_type = "installed" from the code running in the cloud (because the default "web" is what you want). Or have gargle_oauth_client_type = "web" everywhere just to remind yourself what you're doing.

[quantitative-technologies]

The first approach was unsuccessful, adding the option gargle_oauth_client_type = "installed" still misses the cached token:

> files <- drive_ls(instances_id)
attempt to access internal gargle data from: googledrive
trying `token_fetch()`
Trying `credentials_byo_oauth()` ...
Error caught by `token_fetch()`:
inherits(token, "Token2.0") is not TRUE
trying `credentials_service_account()`
Error caught by `token_fetch()`:
Argument 'txt' must be a JSON string, URL or file.
trying `credentials_external_account()`
aws.ec2metadata not installed; can't detect whether running on EC2 instance
trying `credentials_app_default()`
Trying `credentials_gce()` ...
Error caught by `token_fetch()`:
Expected content type application/json, not application/text.
trying `credentials_user_oauth2()`
attempt to access internal gargle data from: googledrive
Gargle2.0 initialize
adding "userinfo.email" scope
loading token from the cache
email: '*'
oauth client name: tidyverse-clio
oauth client name: installed
oauth client id: 603366585132-dpeg5tt0et3go5of2374d83ifevk5086.apps.googleusercontent.com
scopes: ...drive, ...userinfo.email
token(s) found in cache:
[e-mail]
token we are looking for:
no matching token in the cache
initiating new token

Since rstudio server is working again (in the cloud), I generated a new token interactively in the cloud.

I also need to use this noninteractively in the cloud, so I put the option gargle_oauth_client_type = "web" in my script (not sure if this should be necessary?) and everything seems OK now.

[quantitative-technologies]

Well, it seems to have solved my issue. I can use my token with noninteractive authentication is two different contexts by specifying the client type.