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
This has come out of a brainstorm in #166 (comment) and as the issue's original topic will be covered by PR #175, this is being separated out not to get lost in a closed issue.
For the record, checking if a repo is readable would be done with the Get a repository API call and checking the visibility field for public or internal. public is simply readable to the world, internal only to members of GitHub Enterprise organization. I assume the latter wouldn't be visible at all for a user outside of the enterprise organization, so a 40x response is a good marker the repo is not readable.
This will now need to be thought through for both the personal access tokens and app installation tokens.
The text was updated successfully, but these errors were encountered:
The auth plugin's job is to scramble all valid permissions for the identity behind the provided token. Therefore, the check for public repo access evaluation should be done as a last resort, after all existing permission-evaluating means fail.
As each API call to GitHub is expensive (and potentially limited), this should be cached (outside of any identity cache, just a map of public repos).
visible internal repos can't be considered generally public, but when successfully listed, the read/read_meta permission should be added to the identity's permission.
public repos don't need any token to get listed, so we should make sure not to require internal resolving to any identity. As the giftless code assumes there's always some identity, in case the token is invalid or missing, we should provide some bogus identity. However such identity can't serve as a catch-all fallback for misauthenticated calls. Therefore we need to cache the public repos independently of any identity.
TODO think about how this all applies to app installation tokens.
This has come out of a brainstorm in #166 (comment) and as the issue's original topic will be covered by PR #175, this is being separated out not to get lost in a closed issue.
This will now need to be thought through for both the personal access tokens and app installation tokens.
The text was updated successfully, but these errors were encountered: