-
Notifications
You must be signed in to change notification settings - Fork 1k
Http authentication for private repositories #264
Comments
Oh, there are also some sorta sketchy workarounds for this that involve configuring git to rewrite http urls into ssh urls, but we can definitely improve on this. |
I'll take a look at this on the weekend. The ways I can think of are:
The composer approach (username and password in the URL) is depreciated (RFC 3986) so we should probably avoid this. |
Thanks for spinning this out, and sorry it took me so long to respond here. Almost all of the substantive change here is going to be in gps. dep's just going to be responsible for picking the information up, then injecting it into gps appropriately. Some things I can say up front about @zacps' suggested possible approaches:
In a sense, we do this already. When doing "source deduction" on an import root, we typically produce a set of multiple schemes that could be used for an import path. In gps parlance, these are known as
This is a strong maybe. I opened sdboyer/gps#28 nearly a year ago after someone raised the point about wanting to be able to make SSH work without an agent. The problem, as that issue notes, is that prompting the user is somewhat at odds with doing all this work in parallel (which we very, very much want to do for performance reasons).
It would be good to rely on standard configuration from the underlying tools as much as possible. Barring that, though, I'd say that configuration is a possible option...but I worry we'd pretty quickly find ourselves in a discussion about creating a dotfile for dep. I'd rather we try to avoid going there just yet.
As above, we sorta end up doing this automatically. For us, the problem is that source discovery operates so much by magical incantation string inference that we can't really know ahead of time what's private and what isn't.
Agreed, I would prefer to just not even have this on the table at all. |
How about using authentication callback. When solver requires credentials, it would call the callback (if one is registered). dep or another front end can then return credendials from any available source. Moreover, text mode driver can ensure to serialize text prompts, and ask the user for one credential at a time. This would require calling solve() in async way, but that should be easy I think. |
a callback is interesting - it's in keeping with a number of other tools that I'm aware of. it might have to take a few different forms, though. e.g., ssh creds, https token vs user/pass, etc. but it would open up integration with system keychains, which is what we need. let's spec it out. |
so, git handles this. I've added instructions to the FAQ on how to configure Authentication with git so that it will work with dep. |
closing this now, as the solution described in the docs is good enough for now |
Regarding the FAQ entry and telling git how to authenticate to these private repositories: This only works if If I have import "ghe.example.com/org/repo" then, as best as I can tell, Lines 604 to 605 in 83789e2
deduceRootPath proceeds to httpMetadataDeducer.deduce(..) .
|
@mattnworb so, there's a few phases here. the unfortunately, this doesn't work very well with github enterprise (nor would it with github itself, actually - github only works because it's one of the well-known cases handled in by far the easiest solution here will be to add a |
Thanks @sdboyer for the fast response. Is there a listing somewhere of all the ways to make |
@mattnworb yep, we follow the rules set down by |
Hello, I had the same problem, and i could solved i by a little "hack":
where $$GH_TOKEN is a secret env variable containing my personnal access token |
Spinning this item out of #174
I'm specifically looking for something along the lines of what composer does. Go get has always been painful to work with for private repositories for this reason. You generally have to manually clone the project to your gopath to get around this issue. Being able to configure dep with a personal access token and/or a git-like credential manager would make working with private repositories much easier.
Furthermore, Github Enterprise at my org is configured to require authentication for all pages, even "public" repositories. I'm not even sure if it can be configured otherwise. This makes
go get
fundamentally incompatible with our GHE instance without this feature or some kind of intermediate vanity url that doesn't require authentication.The text was updated successfully, but these errors were encountered: