Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retry HTTP requests failing because of GitHub API SAML SSO enforcement with different token #140

Open
Gummibeer opened this issue Aug 26, 2021 · 0 comments · May be fixed by #167
Open

Retry HTTP requests failing because of GitHub API SAML SSO enforcement with different token #140

Gummibeer opened this issue Aug 26, 2021 · 0 comments · May be fixed by #167

Comments

@Gummibeer
Copy link
Member

GitHub has an option for organizations to enforce SAML SSO for all API requests made to their organization by members.
https://docs.github.com/en/rest/overview/other-authentication-methods#authenticating-for-saml-sso

In case this happens the response is a 403 Forbidden with the following headers and body:

x-github-sso: required; url=https://github.com/orgs/stjude/sso?authorization_request=ABCXYZ
{
    "message":"Resource protected by organization SAML enforcement. You must grant your OAuth token access to this organization.",
    "documentation_url":"https://docs.github.com/articles/authenticating-to-a-github-organization-with-saml-single-sign-on/"
}

This has a massive impact on the queue right now they are catched by the rate-limit retry logic and do 12 requests over the duration of 12 hours to the API without any benefit/reason.
So far I know there's no attribute provided by API that indicates if an organization enforces SAML SSO. So the only way is to try'n'catch.
All these requests can pass and get a response if they are done with a non-member access-token. This works for us as we only request public data that wouldn't need an access-token at all. This problem is already reported to GitHub Support and is on their backlog/roadmap without any ETA.
As it prevents us right now from syncing two organizations:

We have to solve it with a "temporary" fix. The idea is to detect this response the same as the rate-limit one and instead of just retrying it 1h later we would have to switch to a non-member access-token. So this will have to be solved in a Guzzle middleware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

1 participant