Only ask for OAuth permissions when we actually need them

[jish]

Hello,

I haven't logged into my gratipay account since it was still called gittip. When I went to log in today, it seems you guys are requesting more access to my GitHub account.

Is it possible for me to still log in somehow? Can you remove the additional request for information?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[techtonik]

Is it possible to let people choose what they want to share and explain why Gratipay needs it?

[Changaco]

@jish Why is read-only access to organizations a problem ?

[techtonik]

@Changaco because participation in some organizations is a private business?

[galuszkak]

@techtonik but private organizations or one that you don't want be listed publicly aren't exposed in API.

[techtonik]

@galuszkak I don't see that in the screenshot.

[jish]

"@techtonik but private organizations or one that you don't want be listed publicly aren't exposed in API."

"@galuszkak I don't see that in the screenshot."

Yea, if that is true, and was explicitly stated, I would be more comfortable with clicking accept. ;)

[chadwhitacre]

Best practice with OAuth is to ask for permissions at the point of need. In this case we shouldn't ask for read:org until the user tries to attach a GitHub account to an existing Gratipay account. When signing in for the first time we should only require user:email.

[galuszkak]

@techtonik this question should go to GitHub then. I think people that aren't familiar with GitHub API couldn't know which information by this permission is visible. But this isn't a Gratipay issue IMO.

[chadwhitacre]

But this isn't a Gratipay issue IMO.

Well, ideally we wouldn't ask for read:org until we need it (someone tries to connect a GitHub account to an existing Gratipay account).

[galuszkak]

That doesn't change a fact, that even if we want that permission later it isn't clear for GitHub users what they are exposing to 3rd party application. For example they could have NDA and they can't show for who they work now. So my initial thought is that users here saw problem in that they doesn't know what they are really exposing to Gratipay. ;)
This is similiar problem that Facebook had with profiles/post permissions a few years before.

[techtonik]

Answer from GitHub support:

It's a very important topic and we're glad you're bringing it up with us. As I mentioned, providing more granular OAuth scopes and configuration options is already the biggest blip on the API team's radar and it's something we'd love to do. Still, I can't promise an ETA for when this might be available.

[techtonik]

A follow-up:

If you need just the list of organizations the user is a member of and for which the user publicized membership -- then you can get that list without requesting any scopes because that's publicly available information.

https://developer.github.com/v3/orgs/#list-user-organizations

Looks like we only need to require user:email in OAuth and fetch all other info using public, non-authenticated (but not less secure) channel. Now I get what @whit537 meant in #2854 (comment)

[techtonik]

So, the plan to fix this is:

• find when orgs are needed
• find where orgs are fetched
• switch orgs fetching from GitHub OAuth API to GitHub Public API

[techtonik]

Blaming.. =)
dab9933 github.py (Changaco 2014-02-07) oauth_email_scope = 'user:email'
d61266b github.py (Changaco 2014-04-22) oauth_default_scope = ['read:org']

[techtonik]

Seems like organization info is needed when a user attempts to add team. I see some code in www/on/%platform/associate.spt and templates\account-row.html, but I need more time to read what they do.

[techtonik]

Looks like I won't be able to deal with it in any reasonable time frame. Need a diagram how the flow is implemented in Gratipay.

[techtonik]

Ok. I need to deal with this challenge sooner or later. Just raising the priority.