I port a .NET application that runs in .NET 3.5+ to WinRT, and it includes a WCF service client (created using ChannelFactory<T> programmatically) that shares almost all of its code (that is, as far as I could do the same) with the original version of the program. Access to the service is via SSL on port 9443 and uses Windows authentication. The original version of the code works flawlessly, but the WinRT port usually fails using a three-layer exception sandwich: I get an EndpointNotFoundException ("There was no endpoint listening in https: // ...") with an internal WebException exception ("Cannot connect to the remote server ") with an internal exception SocketException (" An attempt was made to access a socket that was denied by its access permissions 192.168.xx: 9443 ").
It is strange that this will not succeed IF I will not have Fiddler acting as a proxy server and fixing traffic.
Now, more details.
- The SSL certificate is valid from a trusted authority and covers the host header name attached to my IIS site (and only that name).
- I can view the .svc file and its wsdl without any errors, and wsdl itself reports the exact URL that I use from my application.
- This site has bindings for https on 9443 and http on 9999 (both have a host header name associated with them)
I have the following clientaccesspolicy.xml in the root of the site and it is accessible through HTTP and HTTPS through the corresponding ports:
<?xml version="1.0" encoding="utf-8"?> <access-policy> <cross-domain-access> <policy> <allow-from http-request-headers="*"> <domain uri="*" /> </allow-from> <grant-to> <resource path="/" include-subpaths="true"/> </grant-to> </policy> </cross-domain-access> </access-policy>
The service account serving the service has an UPN associated with it, as someone suggested this might help. I tried putting this in <servicePrincipalName/> at my <identity /> endpoint, but to no avail; using <dns /> didn't help either.
- Binding
BasicHttpBinding to BasicHttpSecurityMode.Transport , and I set ClientCredentialType = HttpClientCredentialType.Windows . The credentials are currently hard-coded and correct. But I do not think this is a problem, because ... - I can set up a service call in a loop and watch for a crash, crash, crash, and crash until I switch Alt + Tab to Fiddler and start capturing traffic. This redirects the service call through the local Fiddler proxy, I understand, and for some reason this makes it just perfect - I don’t even need to restart the program, let alone recompile it.
- This is the same regardless of whether I have set the Fiddler man-in-the-middle certs to be trusted or not, regardless of whether I choose to decode SSL sessions or not.
- The traffic that I see when I do this with Fiddler does not particularly illuminate me; looks like a standard handshake negotiation with an HTTP 401 error, followed by a successful connection after that.
- IIS is version 7. Logs (inetpub \ logs) don't seem to show anything interesting - in fact, I never see anything there until Fiddler is attached, when everything works fine.
- I tried using Wireshark to sniff it, but the results are mostly useless to me. It doesn't even look like Wireshark selects anything until I start capturing in Fiddler and then I get traffic, but I don’t know enough to find out if I was looking for it incorrectly.
- Trying to add a standard Visual Studio proxy by adding service references in the same behavior as my custom code.
- Just for kicks, to find out if WinRT has an unpublished restriction on ports such as Silverlight, I set the site to port 4505 (to get into the 4502-4534 range). Nothing changed.
- Clearing the cache and cookies in the Internet settings does not matter.
- Windows Firewall is turned off. Does Windows 8 have other traffic barriers? (Not that it matters, because the desktop application works great all the time.)
- Windows Defender real-time protection is disabled.
- The behavior is the same even if I run the application on a simulator. I cannot test another physical machine because it is my only installation of Windows 8.
Hopefully this shows that I have done due diligence about this. What did I miss? Please let me know if I can provide more information.
source share