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

Calling 3rd party DLL that makes calls out to the internet from .Net core fails proxy authentication despite configuring or coding the required settings #26800

Closed
Petermarcu opened this issue Jul 12, 2018 · 4 comments
Assignees
Labels
area-System.Net.Http enhancement Product code improvement that does NOT require public API changes/additions tenet-compatibility Incompatibility with previous versions or .NET Framework
Milestone

Comments

@Petermarcu
Copy link
Member

@Toxophilus commented on Tue May 15 2018

I have created a .Net Core 2.0 Web.API that will relay a request to a 3rd party provider via their .Net 4.0 DLL which in turn handles the communication with their Web API and returns the results.

In a simple .Net 4 application this all works perfectly and when I run my Web.API and make calls to it using a direct internet connection again it all works perfectly.

However, if it is run connecting to our work network which uses a proxy I get 407 Proxy Authentication Required. Fair enough all I need do is specify that I want to use the default credentials and it should all work. So A bit of digging around had given me several possible solutions. Unfortunately under .Net Core 2.0 they don't work.

I have tried deploying to my local machine and specifying in the web.Config:

<system.net> <defaultProxy useDefaultCredentials="true" /> </system.net>

I have also tried adding this configuration to the machine.config (which seemed a bit overkill) again no joy.

I have also tried adding to my code in my Web API:

System.Net.WebRequest.DefaultWebProxy.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;

both before and after instantiating a reference to the 3rd party DLL and still when the vendors DLL makes its call to their Web API, via HTTP or HTTPS I get back 407 Proxy Authentication Required.

In an attempt to prove that I was not going mad I stripped the core of the work out to a standard .Net application to create basic a test harness and applying either of the solutions to that program it all works as expected. I have also created a separate .Net 4 DLL to act as a wrapper to the 3rd party DLL and in its constructor put in the above code to set the credentials in an attempt to isolate the effect to that environment. Again, this works perfectly under a simple test application but fails under the .Net Core Web.API.

Putting fiddler into the equation to watch the communication with the working application you can see the initial request get denied and proxy authentication get requested, the authentication then gets passed back and the actual request then gets through and the result passed back.

But in the .Net core Web.API I have developed the request simply goes out, hits the proxy authentication request, but then no credentials get pushed back to get things going and the conversation terminates.

This is the first time that I have ever worked with .Net Core so I may be missing something that I need to do, but from my perspective it looks like when I set-up the environment in my application for proxy authentication that same environment/settings are not being passed through to the DLL's environment and so I can't handle the request properly.

So I need some way of setting up or injecting the environment for the 3rd party DLL to ensure that it knows what to do with the authentication request via System.Net.WebRequest.DefaultWebProxy or similar.

So far I have tried running the code in a completely different thread and tried creating a completely separate .Net standard DLL to act as a wrapper, inside that DLL I then use code to force the System.Net.WebRequest.DefaultWebProxy.Credentials to use the default network credentials. Plugging either of these into my test harness they work but as soon as they are put into the .Net Core Web API they fail in exactly the same way.

@davidsh
Copy link
Contributor

davidsh commented Jul 12, 2018

I have tried deploying to my local machine and specifying in the web.Config:
<system.net> </system.net>
I have also tried adding this configuration to the machine.config (which seemed a bit overkill) again no joy.
I have also tried adding to my code in my Web API:
System.Net.WebRequest.DefaultWebProxy.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;

The HTTP stack in .NET Core does not read from any config files nor does it currently read/use the System.Net.WebRequest.DefaultWebProxy object. The intent was that passing in credentials for a system default proxy would normally be done by using the HttpClientHandler.DefaultProxyCredentials property.

However, in your case, you are using a hybrid set of DLLs where your application is a .NET Core application but you are using a library that would work in either .NET Framework or .NET Core. Unfortunately, your scenario for enabling default credentials for proxy authorization will not work. The only workaround right now would be for the 3rd party DLL to be revised since that DLL is the one actually creating the HttpWebRequest or HttpClient object.

@dajomo
Copy link

dajomo commented Jul 25, 2018

@davidsh This is very disappointing

@karelz
Copy link
Member

karelz commented Nov 2, 2018

We need to figure out how to configure proxy globally, not just per HttpClient instance.
It has come up couple of times as feedback.

@davidsh davidsh self-assigned this Mar 8, 2019
@karelz
Copy link
Member

karelz commented Apr 3, 2019

Will be tracked by dotnet/corefx#36553

@karelz karelz closed this as completed Apr 3, 2019
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 3.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Net.Http enhancement Product code improvement that does NOT require public API changes/additions tenet-compatibility Incompatibility with previous versions or .NET Framework
Projects
None yet
Development

No branches or pull requests

5 participants