Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub connection doesn't work behind authenticated proxy #2505

Closed
csmager opened this issue Apr 27, 2020 · 5 comments · Fixed by #2507
Closed

GitHub connection doesn't work behind authenticated proxy #2505

csmager opened this issue Apr 27, 2020 · 5 comments · Fixed by #2507

Comments

@csmager
Copy link
Contributor

csmager commented Apr 27, 2020

The Octokit client created via the Fake.Tools.GitHub API uses the default proxy, but it doesn't pass on the credentials so you get a 407 Proxy Authentication Required error.

This proxy can explicitly be configured when creating the HttpClient (we'd set it here), but we'd need to decide how to approach this. I think we can do either of these (or both):

  1. We can add additional createClient function(s) that accept an IWebProxy option. Not sure I like this as it rather ties your build script to the environment.
  2. As suggested in Default Proxy issues dotnet/runtime#25745 (comment), all we should have to do is make sure the DefaultProxyCredentials are set on the HttpClientHandler and the system config should 'just work'.
@csmager
Copy link
Contributor Author

csmager commented Apr 27, 2020

Just noticed we still target net462 and DefaultProxyCredentials doesn't exist there. Might need an alternative!

@matthid
Copy link
Member

matthid commented Apr 28, 2020

@csmager To be honest: I have no idea what the best way forward is. Considering this might hit other modules as well we should aim for an approach which works for others as well.
Can you send a PR for approach 2?

@csmager
Copy link
Contributor Author

csmager commented Apr 28, 2020

Yes, will look into it. Unfortunately seems a little trickier than hoped given that property doesn’t exist in net462. I’m curious why we target that as well as netstandard2.0?

@matthid
Copy link
Member

matthid commented Apr 28, 2020

I don't think we really need net462 support, we add it to make the modules more useful (all FAKE modules/libraries can be used from regular .NET projects as well)

@csmager
Copy link
Contributor Author

csmager commented Apr 28, 2020

Ok. It's fairly easy just to add #ifdef NETSTANDARD2_0 and do what we need in there. Just need to find a willing colleague to do some testing to prove it solves the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants