Repository navigation
Add basic validation of stored credentials #268
Description
Right now GCM Core always returns any stored credentials for a request without any validation.
We cannot ever 100% validate that a credential is "good" for the particular Git command/request because the remote Git server can reject the credentials based on the content of the pack during a push, for example.
We can however validate if a stored a credential is expired or not, such as a PAT or OAuth JWT token that have expiration dates.
To do this we need to extend the credential store API and platform implementations to support reading/writing expiry metadata.
In the event the metadata is missing or the credentials have no expiry we should optimistically return them - assume they are good. This would mean we only reject definitely bad credentials (expired) and avoid false negatives.
Activity
hickford commentedon Apr 13, 2022
This would also work nicely for refresh tokens -- and a more elegant solution than storing under a distinct host.
I believe https://git-scm.com/docs/git-credential supports storing arbitrary key value pairs. [correction: it does not]
hickford commentedon Nov 1, 2023
It would be neat to store Git's password_expiry_utc attribute https://git-scm.com/docs/git-credential#Documentation/git-credential.txt-codepasswordexpiryutccode
Currently GitLabHostProvider makes a HTTP request to check expiration. This would no longer be necessary. GenericHostProvider is unable to store expiry, so does OAuth refresh every time.
becm commentedon Feb 14, 2025
The Git authentication flow will likely keep to enforce some limitations.
So the respective providers will need to handle most aspects of expiry and refresh during the
getphase anyway.The Azure and Bitbucket providers do some stuff with (dummy) web calls already.
Only missing one (at the moment)? should be generic OAuth2, expiry could be extracted from JWT content.
Trying to use that as part of #1837.
Also problematic:
The
refresh_tokenMUST be updated as soon as there is a new value supplied by a reply.The
auth_tokenwill take a detour viagitand come around (depending on result) as astoreorerasein a totally separate GCM invocation.So they definitely have to remain as two distinctly changeable entities, unless both are (only) updated during
get.