Only request access to the repo(s) being used in GitHub

[ryanblock]

Currently GitHub's public_repo + repo OAuth flows requests read/write access to various repos; it would be great if Begin provided some alternate means of repo authorization that enables more refined scope of permissions.

As it pertains to more granular git authorization, GitHub, like other providers (GitLab, BitBucket), only offers extremely coarse Oauth scopes. We do have at least one path forward: GitHub Apps.

I've done some work on a GitHub Apps integration, which allows per-repo authorization, and we have a rough plan for implementation that would allow you to select which repo(s) you want Begin to have access to, and exclude all else.

Unfortunately, the GitHub Apps flow has some limitations that make it somewhat impractical; for example, you cannot create a fresh repo (which most people do in Begin) permissioned as you want it. Instead, you have to show up with existing (presumably empty) repos ready to be permissioned. This adds a lot of complexity and difficulty for the end user to work through when in the new app flow.

Would love to hear more about how / whether folks want this feature!

We used to hear this request a lot more, and then we added progressive authorization, where we ask for as few permissions as possible along the way, and folks can opt into what access they provide Begin on a very granular basis.

[grjzwaan]

The idea of begin.com is really nice and I've started to use Architect, which I enjoy.

In your post you describe progressive authorization, but I got 'access read+write to all public repos' and then 'access read+write to all repos' when adding private repos. If I'm missing something here please let me know!

For me personally the required permissions are too broad to use it outside of hobby/testing.

• Giving access to all the public repositories can be ok for testing, but I would still be uncomfortable. Even if only from the perspective that by mistake I'll overwrite a repository from the begin.com application/console.
• Giving access to all private repositories is simply not possible for me. I have multiple customer projects that have to be private and of which I really cannot give access to - even if only theoretical.

I wouldn't mind at all to create repositories by hand and then giving access (or even better: only read-access and configuring it myself).

[ryanblock]

The progressive auth that you mentioned as being too coarse is still just the scopes provided by GitHub’s OAuth API – we can’t get any more fine-grained there. You’re not missing anything, it’s just what it is, and we’ve limited the request for scopes as much as possible. I wish we could do better there, but that’s the GitHub OAuth API.

Out of curiosity, you mentioned overwriting an existing repo from Begin, can you speak further to that concern? What do you think Begin may do?

[grjzwaan]

Thanks for the additional explanation.

Sure, good question. It was a minor concern where I could accidentally pick the wrong repository in begin.com and the application would overwrite the content in the repo and commit. It can be easily reverted and perhaps begin.com would never overwrite files...

The more I think about it, the less it's a practical concern and more a reflex to limit privileges as much as possible.

[ryanblock]

Generally probably better to be paranoid about token issuance than lax!

All that said, the entire Begin codebase only contains two write actions to git:

• During initialization:
  • If it's a new repo: it creates the repo contents; this code path cannot be run unless a new app and repo is called to be created, and will fail if the repo already exists
  • If it's an existing repo: this code path adds to an existing repo the minimum number of files necessary to operate as a Begin app – specifically that's two files, and they're only added if they don't already exist: app.arc and public/index.html. Begin also may add @architect/sandbox to your project's deps, if it has a package.json.
• During use: if you click the deploy to production button, Begin will create a git release via the GitHub API; this is specifically to the create release endpoint (api.github.com/repos/{owner/repo}/releases)

So that's the entire surface area of what the Begin application can actually do to mutate a git repo, and the circumstances under which it does so.

This is highly intentional: every way Begin can mutate a git repo is a vector we could mess something up for folks. We've heard this feedback, too, and our goals are aligned in that I think everyone wants Begin to basically just be as close to read-only as possible.