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

Comments

@jennybc
Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member

commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member

commented Nov 13, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.