feat(auth): add github proxy authentication #146
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi there, here's a production-grade-aspiring implementation (w/o tests yet) of the GitHub "proxy" authentication, which provides the same access permissions to a Git LFS org/repo as are those for the same GitHub repo. It uses Github's HTTP API personal access tokens, which are used to retrieve the particular user's permissions.
The module has been developed with the focus on minimizing GitHub API traffic where feasible, so it uses a lot of [configurable] API response caching.
The next aim was to keep the new 3rd party dependencies low, which so far worked, except for the use of a small package called
cachetools
andmarshmallow
, which both are already (transitively) used by existing code. I looked around for various libs, but eventually ended up doing something that badly feels like inventing the wheel in case of thread-safe caching wrappers for the [idempotent] GitHub API calls. I didn't find any alternative, tho 🤷, so there it is.Everything is in a single file to avoid back-and-forth merging hassles, but it might be worth splitting some parts into separate files once/if the PR gets merged.
Originally, this was a very simple file, but then came config values, their validation, persistent connection reuse, robust error handling, caching, and ultimately further thread-safety measures.
There is also an option to change the GitHub API URL so it could be used for "enterprise servers", which have a different API endpoint than the public cloud GitHub.
I'm opening this as a draft, because I'm aware that I didn't write any docs or tests, but I also deeply desire someone to review the code, so we'd know we're on the right track and I didn't create some design issues along the way so far. Thank you.
PS: Again, thanks @athornton for letting me know about his own custom implementation which I sure used for inspiration.
Closes: #147