You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an organisation has enabled and requires SAML SSO in order to access their repos, and we are using PATs, it is not possible to use the generated PAT because it is lost/never stored by GCM Core.
Normally we'd expect Git to tell us explicitly if a given PAT should be stored or erased after we return from a get.
However when a PAT requires SSO be enabled manually on the web, GitHub returns a 403 to which Git does nothing except print the remote: SSO required message.
Ideally we would want Git to tell us about the 403 and that the PAT was for a valid user, but lacked the specific permissions. That way we could store it and direct the user to update/change the PAT permissions, or even fix them automatically for them.
In the meantime, to workaround this we should store the PAT once we generate it. This means that when users who hit this scenario, they can come back and retry with the same PAT after enabling SSO permissions.
This workaround does break another scenario however - if the user has manually changed the permissions of the generated PAT in the web, then GCM will not prompt to generate another PAT since it always finds the existing 'bad' PAT and Git never tells us to erase it. Since this is a scenario where the user has 'done the wrong thing', it is a smaller and more unlikely situation than a user needing the SAML SSO approve their PATs.
The text was updated successfully, but these errors were encountered:
In order to allow a user that requires SAML SSO to be manually enabled
on their newly generated PATs to access org repos, we must store the PAT
as soon as we generate it. This then allows the user the ability to
visit the web UI, enable SSO, and then repeat their Git operation using
the _same PAT_.
Workaround for issue: git-ecosystem#133
We've hacked around this by storing the PAT on get when we know the PAT is good (even if not SSO enabled). This means that the PAT is not lost before the user does the manual interaction to enable SSO.
Since the 'better' fix here is actually just moving to OAuth as the preferred/default authentication mechanism, I'll close this issue.
In order to allow a user that requires SAML SSO to be manually enabled
on their newly generated PATs to access org repos, we must store the PAT
as soon as we generate it. This then allows the user the ability to
visit the web UI, enable SSO, and then repeat their Git operation using
the _same PAT_.
Workaround for issue: git-ecosystem#133
When an organisation has enabled and requires SAML SSO in order to access their repos, and we are using PATs, it is not possible to use the generated PAT because it is lost/never stored by GCM Core.
Normally we'd expect Git to tell us explicitly if a given PAT should be
store
d orerase
d after we return from aget
.However when a PAT requires SSO be enabled manually on the web, GitHub returns a 403 to which Git does nothing except print the
remote: SSO required
message.Ideally we would want Git to tell us about the 403 and that the PAT was for a valid user, but lacked the specific permissions. That way we could store it and direct the user to update/change the PAT permissions, or even fix them automatically for them.
In the meantime, to workaround this we should store the PAT once we generate it. This means that when users who hit this scenario, they can come back and retry with the same PAT after enabling SSO permissions.
This workaround does break another scenario however - if the user has manually changed the permissions of the generated PAT in the web, then GCM will not prompt to generate another PAT since it always finds the existing 'bad' PAT and Git never tells us to
erase
it. Since this is a scenario where the user has 'done the wrong thing', it is a smaller and more unlikely situation than a user needing the SAML SSO approve their PATs.The text was updated successfully, but these errors were encountered: