GitHub Community
How to make Github app connect after approval #42351
Replies: 20 comments 14 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.
-
|
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.
-
|
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.
-
|
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.
-
|
It seems the problem is still here. Would be great to have this |
Beta Was this translation helpful? Give feedback.
-
|
@hpsin If you are still working on this area... 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
I've come up with a hacky workaround. On the initial callback with
On the callback with
A user can cancel a request and their is no callback or webhook from github for this, so if they re-request after canceling you could get duplicates in your DB unless you handle it... What happens if multiple users request? I don't know since I only have 2 users to test with 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
This is also the approach we're doing as well now, it works but it doesn't feel very solid, especially if the same user has installed the github app into multiple orgs. I imagine if you're running a high traffic app with many install requests you might have to have to paginate back pretty far through the API results. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is the best solution so far until GitHub has something official. |
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.
-
|
Posting a message to keep this alive. Since it's open now for 2 years, I'm guessing that GitHub team has no intention to prioritize fixing this bug. We can close this issue if we don't get any new activity in the next few weeks. |
Beta Was this translation helpful? Give feedback.
-
|
I know it was still an issue for us, it'd be really nice to get this solved |
Beta Was this translation helpful? Give feedback.
-
|
@hpsin -> can you get this prioritized? lmao |
Beta Was this translation helpful? Give feedback.
-
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