How to make Github app connect after approval #42351
Replies: 43 comments 17 replies
-
|
Any suggestions on this? |
Beta Was this translation helpful? Give feedback.
-
|
I imagine this should be a fairly common scenario for GitHub App integration developers. Very interested in how to tackle this as well. |
Beta Was this translation helpful? Give feedback.
-
|
Apparently there's no solution yet. This is what support told me:
|
Beta Was this translation helpful? Give feedback.
-
|
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:
This approach works but is horrible and error prone, there's lots of moving parts. How are others doing this? |
Beta Was this translation helpful? Give feedback.
-
|
Following up on this we really need both of these:
|
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
The webhook includes the organization, and and "installation" field, as well as the user. Is there not enough information to match? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Any update on this? It's badly needed to allow only authenticated users to access a github-app enabled application. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
It is funny that pm at GitHub suggest a non-exist feature for broken feature 😅 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
It seems to me the 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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly what is said here too https://github.com/orgs/community/discussions/42351#discussioncomment-5605662 |
Beta Was this translation helpful? Give feedback.
-
|
Is there any update on this? Interestingly I noticed a few cases where the original |
Beta Was this translation helpful? Give feedback.
-
|
Also looking for a solution for this issue. Any updates on this? |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1. We are adding a number of different integrations to our product, and I thought, "Oh, I'll do Github next, they're probably nice and easy and normal because they should be good at code." And instead, this is what I find. I don't like the idea of linking a github org to an internal org via user matching. Saying "GitHubOrgA installed MyApp, and GitHubUser1 authenticated on our service as part of InternalOrgB, and GitHubUser1 belongs to GitHubOrgA, so therefore GitHubOrgA can be safely linked to InternalOrgB" feels dangerous to me. Can't GitHubUser1 belong to multiple orgs? I don't know, maybe there is a good way to do this in a way that truly is secure, maybe I just don't get it, but I don't trust these types of custom-made-10-step-dances. I really just wanted a normal oauth flow for getting a token, not sure why that was too much to ask for. And I'm absolutely sure that most people who implement this logic haven't thought of any of this stuff that people are discussing here, meaning there's a ton of vulnerable code out there in the wild. It is very surprising to me that Github knows about this and just decided it doesn't matter. |
Beta Was this translation helpful? Give feedback.
-
|
+1 here.. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
@hpsin is there an update on this? |
Beta Was this translation helpful? Give feedback.
-
|
Can you guys pretty please *** fix this |
Beta Was this translation helpful? Give feedback.
-
|
We all know they will never fix it. |
Beta Was this translation helpful? Give feedback.
-
|
The most naive solution here is simply to ensure This is simply ridiculous that GitHub App is the only way to get access to PR checks functionality, yet installation flow is inferior to more restricted oauth app flow. Please fix it, GitHub team. |
Beta Was this translation helpful? Give feedback.
-
|
Adding my +1 here. We're also facing an issue with state not being present when admin approves :/ |
Beta Was this translation helpful? Give feedback.
-
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
|
@github-actions[bot] needs a 4th option: 4️⃣ Continue waiting for GitHub to sort this mess out and actually make the install request flow usable. |
Beta Was this translation helpful? Give feedback.
-
|
Crazy this doesn't get more attention from GitHub :( |
Beta Was this translation helpful? Give feedback.
-
|
CC @jaredpalmer 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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_idthat 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 theinstallation_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?Beta Was this translation helpful? Give feedback.
All reactions