Github API Collaborators access changed today #24618
-
It seems until yesterday accounts with Today, only the Our merge bot relies on that for automatically figuring out who can trigger it. Was this change a mistake on Github’s part? Is it going to be reverted? If it’s intentional, is there some other recommended way for automation to detect collaborator permissions which doesn’t require the |
Beta Was this translation helpful? Give feedback.
Replies: 20 comments
-
I found this issue while diagnosing a similar problem with our merge bot. This change started affecting us somewhere in the last two hours. |
Beta Was this translation helpful? Give feedback.
-
You all caught this well before I could! We did push a recent update (4 hours ago, as of this writing) that now requires This change brings our API in-line with the Web based experience, and should be more consistent. There’s quite an extensive reasoning behind this and if it’s necessary I can elevate those details. So yes, this was a deliberate action. For now, I don’t believe there is another permissions level outside of Alternatively, it is true that GitHub Integrations have the ability to list collaborators, but we will likely be reviewing that in the future. Edit: our team is currently in discussion about the impact this might have, and whether or not a reversion is warranted. Will update when there’s more to share. |
Beta Was this translation helpful? Give feedback.
-
This change is affecting our merge bot that requires such permission for listing the authorized people to perform such action:
[14.0][MIG] im_livechat
Migration done. If such list is public, why it should be restricted to admins? |
Beta Was this translation helpful? Give feedback.
-
Was there some warning or notification before this went live? Is there a way to be warned about similar changes which could break tools using the GitHub API in the future? Thanks |
Beta Was this translation helpful? Give feedback.
-
Hi @emin63 👋 Thanks for joining the Support Community to participate in this thread. Unfortunately, this change was made silently, after comparing the experience with accessing this information via the web UI, and the API. As it was, it was an inconsistent experience where only Administrators could view collaborator information on the UI, but In my edit earlier I mentioned we were considering a rollback, but that doesn’t seem likely now. We should be posting to our blog about this soon. Though I can’t say exactly when. |
Beta Was this translation helpful? Give feedback.
-
I have the same problem |
Beta Was this translation helpful? Give feedback.
-
I believe this may have also broken the “Get Repository Permissions for a User” API even when a user is trying to access their OWN permissions: I don’t think a user should need to be admin to check their own permissions. Is there any other way for a user to use the API to find out their permission level on a repo? |
Beta Was this translation helpful? Give feedback.
-
Hey @hatboysam 👋 I’ve followed the discussion since this morning, and that portion of our codebase (get permission) should not have been impacted. At least, that’s my current understanding. Would you mind submitting this as a Support ticket? Or if you prefer, we can split this off into it’s own thread. For now, increasing permissions for these automation tools to I’m so sorry for the lack of comms before this was put out, ya’ll. Not the best experience here. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick response. I filed ticket 1310760 a few hours ago, it has some details. I was able to work around this by using the “get repository” API which returns a personalized But it would be great if you could investigate anyway, as I do believe that API is now behaving as I described. |
Beta Was this translation helpful? Give feedback.
-
Went back and yes, the Again, apologies for the lack of transparency before this change was made. I myself wasn’t aware until this thread. We hope to have out a /changelog post soon. 🤞 |
Beta Was this translation helpful? Give feedback.
-
nethgato:
Requiring admin privilege merely for checking whether a user would be allowed to merge a pull request seems overbearing. This would go directly against the principle of least privilege. This change would mean that bots will have to be guarded against accidentally doing any of the other catastrophic actions that admin permissions would bring. Bots need a non-admin way to know whether a user can trigger it. The jerk change to suddenly make merge bots admin is going to make them a prime target for attack. No one saw this coming, and suddenly giving merge bots admin access is going to be a huge and very obvious security risk. Not communicating this change isn’t the biggest problem, the biggest problem here is demanding merge bot users to accept this security liability. |
Beta Was this translation helpful? Give feedback.
-
FPtje:
☝️ this; we also got hit by this change, effectively breaking all our Jenkins jobs. |
Beta Was this translation helpful? Give feedback.
-
FPtje:
Fully agree. Several Eclipse projects are affected by this as well. See also [cross-project-issues-dev] GitHub issue - "Must have push access to view |
Beta Was this translation helpful? Give feedback.
-
Even it is effecting us running prow bot |
Beta Was this translation helpful? Give feedback.
-
@nethgato you said this change was made to bring the API in line with the information accessible via the Web UI, but actually it is not. My use case for this API is to allow users to find someone who can review their code. On GitHub this is done via the Reviewers autocomplete box. This box only allows the user to pick other collaborators and is visible to anyone with write acccess: So this information is already intentionally visible in the Web UI to anyone with write access. I would really appreciate if the API would give me at least the same ability to list collaborators. |
Beta Was this translation helpful? Give feedback.
-
Hi all! While I was away, a larger number of users both wrote into this thread and into our Support ticketing system. After taking into the consideration the experience this was having, our engineering team rolled back this update. I’m so sorry for the confusing and frustrating impact this had. When this comes back up to review for re-adding to our API, we will be posting to the changelog in advance of the change. |
Beta Was this translation helpful? Give feedback.
-
Thanks for reconsidering. |
Beta Was this translation helpful? Give feedback.
-
Many Thanks. |
Beta Was this translation helpful? Give feedback.
-
Ah, I shouldn’t take any thanks here, but I appreciate how perplexing it must have been to see these 403s out of nowhere and without a changelog to point to. And I should further clarify (rather than edit my last post) that I should not say “when this comes back up,” but “if.” We are considering marking this internally as a “won’t fix,” but there are some internal conversations that initially sparked the change, and was fast tracked, without considering the impact on automation tools that leverage those endpoints. So if it comes back, it will be announced in advance. |
Beta Was this translation helpful? Give feedback.
-
You all caught this well before I could! We did push a recent update (4 hours ago, as of this writing) that now requires admin access via the API to see collaborators. This change brings our API in-line with the Web based experience, and should be more consistent. There’s quite an extensive reasoning behind this and if it’s necessary I can elevate those details. So yes, this was a deliberate action. For now, I don’t believe there is another permissions level outside of admin to perform this action. Alternatively, it is true that GitHub Integrations have the ability to list collaborators, but we will likely be reviewing that in the future. Edit: our team is currently in discussion about the impact this might have, and whether or not a reversion is warranted. Will update when there’s more to share. |
Beta Was this translation helpful? Give feedback.
Hi all!
While I was away, a larger number of users both wrote into this thread and into our Support ticketing system. After taking into the consideration the experience this was having, our engineering team rolled back this update.
I’m so sorry for the confusing and frustrating impact this had.
When this comes back up to review for re-adding to our API, we will be posting to the changelog in advance of the change.