Want to automatically create / update issues on an org repo. OAuth or Github App?


#1

Our use case is to have users fill out a form on our site. Then have that data be used to create an issue in one of our organization repos.

Currently we are using an OAuth app. I added the scope “public_repo” but this still seems way too broad. We don’t need access to the user’s repos / code. Just to be able to create an issue in our own repo on behalf of the user.

What’s the best way to go about this?


#2

If you’re creating issues “on behalf of the user”, and you want those issues to appear in GitHub as having been created by the user, then you need OAuth. Unfortunately that means requesting the broad permissions that you mentioned above

Alternatively, with a GitHub app you’d be able to create issues with the GitHub app as the creator (and perhaps tag the user that requested in the issue in the body). You’d be able to request essentially no permissions from the user in this case (as it wouldn’t be their account that is being used to create the issue), whilst still verifying that they have a valid GitHub account (and are the person they claim to be. That might be preferable, depending on your setup.


#3

hey man thanks for the reply. I finally got my app up and running as per your suggestion. But now I have another issue. I set it to “private” so that random people cant install it on their org / repo.

However this also means that I am only able to install it on the single org in which it was created. What is the best path to be able to limit people besides myself installing it while still letting me install it in all of my orgs?

My main concern is with abuse. Someone malicious could install it on thier org then hammer my app server with events. Or maybe I am misunderstanding? Here is a link to my other post if you are able to answer it


#4

My strong advice would be to just make it public and set up an email or text message for every signup. I had to hustle pretty hard to get 1-2 signups a day for Dependabot before it was in the marketplace - I don’t think anyone found it just by themselves in the early days!

If it turns out to be a problem you could write an intermediary step that stops it doing any work for new installs until and admin has approved them.


#5

I thought of that but isn’t it possible to still abuse the events?

My understanding is that when an app is installed in an org then it is automatically subscribed to all of the events the app listens for.

I certainly wouldnt handle any of those events but the server must still receive and respond to those requests.

By the time they reach the /setup page they will already have the ability to spam events.