When I try to use the GitHub login option, Beeminder requests read/write access to all my public and private user data and read/write access to all my public and private repos (including the ability to push code in my name or give access to other users). That’s crazy and dangerous. Please don’t do it. For login, the user:email scope should be enough; even for monitoring github activity (which I don’t need; I just want to log in) surely public read access (which is included in every scope) should be enough for 99% of Beeminder users. It sucks that Github doesn’t provide readonly scopes (although it seems to be coming soon, but setting up a more limited access method for all the people who just want to log in or track their public Github activity without creating security risks should still be doable with a reasonable amount of effort.
Agreed. I think this comment applies to pretty much all of the potential authentication methods. Afaict, we don’t currently make much of a distinction between ability to use as authentication and ability to use as a source of goal data.
This particularly freaks out the people wanting us to monitor their gmail inboxes, because the required permissions are way too broad for our needs.
Bumping this very old topic because I wanted to start Beeminding GitHub activity but ran in to this same problem. My observations:
- I can’t see any reason that Beeminder should need write access to any repo.
- For public repos, it’s not even obvious why any user-specific API access is needed: in principle it ought to possible to beemind activity by username.
- I noted that GitHub invited me to request access to the organisation that owns some of the repos that I want to beemind. Were they private that might be an understandable necessity, but in any case I doubt that such a request would be approved under any circumstances, and a request for write access by an unknown external application should almost certainly be denied.
It would be great if the GitHub integration could be modernised, because at the moment this issue and another concerning beeminding commits on other branches are both blockers for my particular needs.
(Unfortunately multigitminder is probably not a suitable workaround for me, as it appears that it would be necessary to install it in each repo to be monitored, most of which are not my own personal repos.)