How to make Github app connect after approval

[jainankit]

Hey folks,
We have a GitHub app that can be installed on a repository. This works using the GitHub app authorization flow that returns back an installation_id that we use to associate a user account on our web app with their GitHub repository. In this case we get a callback to our url: /callback?setup_action=install&installation_id=<installation_id>

This typically works fine, but there are some scenarios where the authorization flow doesn't complete in a single step. In many GitHub orgs, it requires approval from an admin before the app can be installed. In these cases we don't immediately get the installation_id in the url but a request state: /callback?setup_action=request, and once the admin approves we get the installation_id.

In this case, since the approval step is completed by a different user, we don't have our web app session to associate the user with this installation_id. Is there a way to identify the user / account of the original request when the authorization is approved?

[harsha-threado]

Any suggestions on this?

[yury-imbro-ox]

I imagine this should be a fairly common scenario for GitHub App integration developers. Very interested in how to tackle this as well.

[jainankit]

Apparently there's no solution yet. This is what support told me:

I'm afraid, there isn't a way to identify requesting users. We have an open internal issue with the engineering team tracking similar reports as a feedback/feature request and I have added this as a +1.

I understand this is something the team would consider in the future but since it isn't a straightforward lift there is no timeline for when it would be implemented.

I'd recommend that you keep an eye on the GitHub Blog and the Changelog where we make announcements and share updates on features now supported. I have also made a note on the internal issue to follow up with you when it is eventually worked on.

[jamesmoss]

Does anybody else have a work around for this? Right now we've got the "Request user authorization (OAuth) during installation" option enabled for our app and we make user go through the following:

1. Prompt the user to enter their org name in our UI, save it in our DB against the tenant ID and then send them off to install the app.
2. On return of the requester to the callback URL we save the requester's oauth refresh token we get from the code param.
3. Admin approves the app install and is sent to the callback URL, with the installation_id. We use the installation_id to find the org it was installed into and use that to find the tenant Id saved in step 1. We also check that the requesters oauth token saved in step 2 is a member of the org to prevent any spoofing of the callback URL & installation_id. I would prefer to do this check in step 2 but you can't accurately see org membership for the requester until your app is installed.

This approach works but is horrible and error prone, there's lots of moving parts. How are others doing this?

[jamesmoss]

Following up on this we really need both of these:

1. state that was passed to the initial install URL is passed to the callback URL when the org admin approves the install.
2. When the callback URL is called with setup_action=request it is additionally given the name of the org/repo the app was requested in. There is no way to know right now where the install was requested without this.

[rashadksh]

+1

[thellimist]

+1

[barry1cassidy]

I have a question for @jainankit, the original poster. How do you match the installation id to the account in your own application? I'm currently testing on localhost and if my callback URL is to my server, the callback request will not have my authentication headers. My workaround right now is to set my callback URL to my client and to make a server request from the client with the "code" query parameter. I use the code to get an access token and then call https://api.github.com/user to get the github username, and match it that way.

Another follow up question. In production, should the callback URL be to my client or a server URL? I assume that if I use a server URL in production, that it will have the users authentication headers, seeing as it will be on the same domain as the client. However, this doesn't work for me on localhost because the client and server are on different ports.

Yes, a state query parameter that would be propagated back to the callback URL would really help with this.

[jainankit]

Hey Barry, yes this works only for the case of server URLs (assuming you mean client as the javascript client). In your case, I think the right approach would be to have the callback URL of the server, and then once authenticated you can redirect back to the client.

Typically in the callback request to a web application, you should have the user cookies also pass through from browser to the webserver. At that time, we can use the cookie / session to identify the account on our application.

This breaks in the scenario that is described on this issue, because the approval of GitHub app and the callback happens via a different person (GitHub admin) who may or may not have an account on our application.

[furkando]

+1

[airadier]

According to https://docs.github.com/en/webhooks-and-events/webhooks/webhook-events-and-payloads#installation the application receives this webhook when the installation is completed. So after approval, it should receive a call with action=created.

Can't you keep the application in "pending approval" state when the callback setup_action=request, and then be ready to handle the installation webhook once it is approved?

[furkando]

We already keep like that but the problem is we are not able to match the webhook with pending state since there is no in common between both and the main reason of this is callback not returns enough information (e.g which org requested)

[airadier]

The webhook includes the organization, and and "installation" field, as well as the user. Is there not enough information to match?

[furkando]

Webhook has enough information but callback has no information so it is impossible to match. We are doing similarity check with auth user of our own with webhook but it is not matching all the time

[sammcj]

Any update on this? It's badly needed to allow only authenticated users to access a github-app enabled application.

[jamesmoss]

@hpsin can you help us on this? It makes the app install process useless for most of our enterprise customers right now as the person requesting the install of the app never has permissions in GitHub to actually install it.

[hpsin]

ACK, I see and understand the pain here and it's on our todo list. Right now we can only recommend that you fetch the list of the user's org memberships and compare that to where you have installations.

[furkando]

ACK, I see and understand the pain here and it's on our todo list. Right now we can only recommend that you fetch the list of the user's org memberships and compare that to where you have installations.

It is funny that pm at GitHub suggest a non-exist feature for broken feature 😅

[isflavior]

+1

[NicHaley]

+1

[NicHaley]

It seems to me the setup_action=request callback at a minimum needs to return a reference (perhaps the installation request id, or the org name) for the application dev to store, then match once the App is approved. But as @jamesmoss mentions the original state value would be ideal.

I've been exploring alternative ways of doing this, and I think I'm sadly going to be stuck with a manual work flow until this is resolved.

[AdrienFromToulouse]

I agree I posted the same conclusions years ago in the previous community issue board https://github.community/t/way-to-link-requested-install-back-to-original-request/240424

The fact that when the GitHub Admin install the app "out of bound" (could happen a few days later), then the original state is not know since not passed to the Post installation Setup URL which makes the flow incomplete. There is no safe way to reconcile afterward between the one you requested the install and then the one you actually approve and install it.

It requires too much many shenanigans on the consumer side. Would be just simple to return the initial state. I wonder why it has been designed this way on day one except that they clearly missed this specific flow in their design.

If the one stores the state when requesting install then even if the app is installed 6 months from now the state should still be returned in the callback and the one should be able to just check the state and do whatever needs to be done.

[AdrienFromToulouse]

Exactly what is said here too https://github.com/orgs/community/discussions/42351#discussioncomment-5605662

[dylankilkenny]

Is there any update on this? Interestingly I noticed a few cases where the original state from the install request is being sent along to our callback url once the admin approves the request, but now it seems to be missing again.

[evakdev]

Also looking for a solution for this issue. Any updates on this?