Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scope handling #90

Closed
jennybc opened this issue Nov 13, 2017 · 5 comments
Closed

Scope handling #90

jennybc opened this issue Nov 13, 2017 · 5 comments
Labels
breaking change ☠️ API change likely to affect existing code

Comments

@jennybc
Copy link
Member

jennybc commented Nov 13, 2017

When user specifies no scope, does it make more sense to select only "full" vs all scopes?

In favor: "full" implies all the other scopes. Using all 4 scopes is redundant.

Against: Once gargle starts to ask "does this token have the scope I need?" as opposed to "does this token have this exact set of scopes?", it is nice to have them all listed.

What if someone gets a token by explicitly asking for "full"? They have enough to scope to "compose" but gargle can't detect that w/o using external knowledge of the API.

@jimhester
Copy link
Member

It looks like there are now more scopes than the ones currently included in the package (https://developers.google.com/gmail/api/auth/scopes).

Also it seems that 'full' scope is not simply equivalent to all the other scopes.

This scope should only be requested if your application needs to immediately and permanently delete threads and messages, bypassing Trash; all other actions can be performed with less permissive scopes.

Which implies to me that those actions are not included in other scopes and can only be obtained by using 'full'.

I think the current behavior is to default to readonly scope if the user does not specify one, am I correct in that?

@jennybc
Copy link
Member Author

jennybc commented Nov 13, 2017

Current default is to get all 4 scopes:

> get_token()
<Token (via gargle)>
  <oauth_endpoint> google
       <oauth_app> tidyverse
           <email> jenny.f.bryan@...
          <scopes> ...gmail.readonly, ...gmail.modify, ...gmail.compose, ...mail.google.com, email
     <credentials> access_token, expires_in, id_token, refresh_token, token_type
                   (expires in 60 mins)

Agree, "full" is not equivalent to the other scopes. But it implies all the other scopes. If you have "full" scope, you can do anything permitted by another scope. So, a token with "full" scope can always be used, even if user specifies they need "compose". But current httr (and even gargle) logic won't detect that and will go through the OAuth dance again.

@jimhester
Copy link
Member

I don't really remember my original intention, but I think this is actually a bug and my intention was to make read_only alone the default. But because it uses match.arg(..., several.ok = TRUE) it returns all of them.

https://github.com/jimhester/gmailr/blob/c0d45d40deda7accc19de644a17d12ac39dbe70c/R/gmailr.R#L81-L83

I think we should probably change the default to simply "read_only" and change the call to match.arg(scope, names(scope_urls), several.ok = TRUE)

@jennybc
Copy link
Member Author

jennybc commented Nov 13, 2017

Sounds good. I opened this issue in anticipation that, once the gargle dust settles, gmailr might get a maintenance pass and it would be good to rethink the scope handling. I'd be happy to pitch in btw.

@jimhester
Copy link
Member

Yes, it definitely needs one and help would be great!

@jimhester jimhester added the breaking change ☠️ API change likely to affect existing code label Aug 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change ☠️ API change likely to affect existing code
Projects
None yet
Development

No branches or pull requests

2 participants