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
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
@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.
The text was updated successfully, but these errors were encountered: