Repository navigation
Allowing tokens on non-gitlab/github/srht git repos - #12006
P-E-Meunier wants to merge 1 commit into
Conversation
github-actions
Bot
added
the
fetching
| { | ||
| virtual std::optional<std::pair<std::string, std::string>> accessHeaderFromToken(const std::string & token) const = 0; | ||
| virtual std::optional<std::pair<std::string, std::string>> accessHeaderFromToken(const std::string & token) const { | ||
| return std::pair<std::string, std::string>("Authorization", fmt("Bearer %s", token)); |
There was a problem hiding this comment.
Do we know which type of git hosters/software support this scheme? This works with github and who else?
There was a problem hiding this comment.
There was a problem hiding this comment.
Ok. This seems common enough. Also because it seems to be related to oauth2.
There was a problem hiding this comment.
We can also remove accessHeaderFromToken from SourceHut in this case.
There was a problem hiding this comment.
So what I am wondering is that you mentioned this would help with git+https. But I don't think this implementation is used for the git input scheme and all the other input types in this pull request are already handled. So which case did you fix here?
There was a problem hiding this comment.
Ok, so I get a clearer picture: where is the handler for git+https?
There was a problem hiding this comment.
fetchTree.cc is what you are looking for.
|
Closing because of: #12006 (comment) |
Motivation
The current implementation of the
access-tokensdirective innix.confdoesn't obey its documentation nor the intuition behind it: indeed, while the docs mention "or other locations", in practice there are custom implementations for GitHub, GitLab and Sr.ht, while other providers aren't handled.This causes flakes to fail authenticating when using the
git+https:scheme instead ofgithub:.This fix only adds a default implementation.
Context
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.