I've got a Silverlight app that talks to an HTTPS web service.
On most machines it works fine, however, on some machines it fails consistently.
On the machines it fails on, I receive a SecurityException when making a WebClient request to the HTTPS web service. The SecurityException itself doesn't give me any clues as to why it's really failing:
WebClient client = ...;
client.DownloadStringCompleted += OnCompleted;
client.DownloadStringAsyc("https://somewebservice/foo");
...
void OnCompleted(object sender, DownloadStringCompletedEventArgs e)
{
Console.WriteLine(e.Error); // Prints SecurityException. Message = "Security error"
}
What are the possible reasons a Silverlight app will fail to call an HTTPS web service? How can I go about debugging this?
edit Still no answers -- is there any additional info I can give to help solve this problem?
We figured it out. The problem came down to cross-zone calls:
Our Silverlight app was hosted on foo.bar.com, which is in IE's regular Internet Zone (low trust).
Our web service was hosted on foo.ourcompany.com, which is in IE's Intranet Zone (high trust).
Silverlight apps cannot make web request calls from low security zones to higher security zones. See MSDN's article on Silverlight URL Access Restrictions for more information. In our case, going from Internet->Intranet was going from low trust to high trust, and so SL call failed with a SecurityException.
Opinion: Microsoft should provide information about why a SecurityException occurred during web request calls. This would have saved us much time and money.
Related
I have a question about enabling cross-domain calls.
I have a WCF Rest service that is hosted in xyz domain. I am able to test these REST APIs from Advanced Rest Client, Postman and Fiddler. I also have a WPF application that actively calls these API which is hosted in a different domain (say abc domain) which works fine in getting responses.
However, when I created a new Angular web application and a Windows Service (deployed on abc domain), and tried calling the APIs from these two components, I am getting a 405 error.
Can someone explain:
How REST clients always are able to successfully establish a connection?
How does my WPF successfully connects to the WCF service even though
its on a different domain?
Why is my Windows Service/Web App not able to talk to WCF?
I assume that the issue here is caused by the preflight request. The browser issues this OPTIONS verb request to ask the server if the origin is allowed to call the API in a non-safe manner.
If your WCF REST service does not deal with this request, the WCF runtime will try to dispatch the request to your service implementation.
However, if the runtime does not find a method to call for this verb, it will return a 405 Method Not Allowed response.
I've dealt with this in the past by using an IOperationInvoker implementation, installed via an IOperationBehavior. This article describes a slightly different way of doing basically the same.
I am using WebClient to download some resource in following way:
Stream stream;
try
{
WebClient webClient = new webClient();
stream = webClient.OpenRead(MyResourceUri);
}
catch (Exception)
{
return null;
}
return stream;
When I do this in a WPF application, it works fine and proper stream is obtained.
When I do this in a WCF service call, it doesn't work. A WebException is thrown with message "Unable to connect to remote server". (It works for files hosted on my machine or within company network, however it fails for any resource on web). The service is hosted on IIS7.
Investigation so far reveals the difference is because of the webproxy. The webclient.proxy in WPF application refers to the proxy settings as set in IE, whereas the one in WCF is having none.
Why is it so? And more importantly, how can I make the WebClient in WCF use similar proxy settings?
EDIT: I set the proxy on WebClient and it worked in WCF service
webClient.Proxy = new WebProxy(ProxyAddressFromIE);
Here I have hardcoded the proxy addess. What method/APIs are there to obtain one? And still why its different in WCF service & in WPF application?
To answer one of your questions, the reason there is a difference between your WPF application and your IIS hosted WCF service is this.
WPF applications run in an actual Windows session (your user session to be exact). This means there is a user profile loaded for that session and that session contains, amongst other things, the proxy settings as configured in IE.
WCF services hosted in IIS do not run in a Windows session. They are run as a service and therefor do not have a Windows session (they actually run in session 0, but that's just an implementatio detail). This means there is no proxy configuration.
To reliably solve this, you could have your own configuration for a proxy, perhaps in web.config.
Another option is to configure the proxy through netsh.exe.
I needed to do the exact same thing, and I found the answer here: Get the URI from the default web proxy. Basically, you need to dynamically read the proxy using WebRequest.GetSystemWebProxy() and by determining the proxy using a test proxied url.
Hope this helps!
Consider handling the call using sources other than the highly abstracted WebClient. From the higher to lower level, this means exploring WebRequest and WebResponse objects all the way down to programming off the socket. The reason is the WebClient method is tightly coupled to choices in Internet Explorer, as much of the high level Internet stack is in windows. If you want to get around this, you need to dig deeper.
I would love to point a finger at precisely where to dig, but I have not incurred this particular issue and have no experience solving. I know where to look for the answer, but no specifics on "X marks the spot". Because of the high level, highly abstracted nature of WebClient, however, I am not sure you can easily get around the implicit creation of the stack and/or the coupling with IE, without more headaches than punting and using an object that gives more explicit control of HTTP communication.
Happy hunting.
as the title already states I am trying to call a self hosted WCF service (hosted in a windows service) from a silverlight 4.0 application which is hosted in sharepoint 2010. I use the basicHttpBinding and I already tried a lot of things as suggested here:
http://www.dotnetfunda.com/articles/article416.aspx
or here
http://blogs.msdn.com/b/carlosfigueira/archive/2008/03/07/enabling-cross-domain-calls-for-silverlight-apps-on-self-hosted-web-services.aspx
but none of them worked I still get the error:
An error occurred while trying to make a request to URI 'serviceuri'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. Please see the inner exception for more details.
The inner exception states:
when deploying an Office solution, check to make sure you have fullfilled all security requirements.
The two files clientaccesspolicy.xml and crossdomain.xml are accessible on http://myserver/clientaccesspolicy.xml and http://myserver/crossdomain.xml
Does anybody have an idea on how to solve this?
All these things helped me out. But the biggest thing for me was turning on Fiddler and tracing the request/responses from Sharepoint + Silverlight. I was getting a 502 error back for some reason. I noticed that my Url in my code was "http://localhost:", however the request from silverlight was "http://[servername]:" you would think that this should work, however it didn't.
I remembered I had run into issues before where "localhost" was giving me problems, thus what I did was to edit my Host file from /windows/system32/drivers/etc and simply add the line::
127.0.0.1 [servername]
I did a iisreset, I left fiddler running and I unchecked the Enable IPv6 option (Tools->Fiddler Options) and everything started working. The Clientaccesspolicy.xml could be accessed, and sharepoint + silverlight could call out into the wcf world :)!!!
There was one major issues however, when you turn Fiddler off, it stopped working... Now I have to figure this one out...
I hope this hellps you.
I'm having a WCF service deployed on one of my servers, and my Silverlight app on the other server. The problem I'm having is running it in Firefox 3.5. Opening in IE 6/7 works great, but when I open it in Firefox it loads the app, but on calling WCF service i get this:
An error occurred while trying to make a request to URI 'http://10.1.1.20:87/MyService.svc'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent.
(The connection works over VPN so don't worry about the IP address)
I have encountered a similar problem and after a lot of research I found that adding the following line of code into the constructor of my UserControl solved the problem:
bool registerResult = WebRequest.RegisterPrefix("http://", WebRequestCreator.BrowserHttp);
More information about the WebRequest member can be found here.
A service I have in WCF occasionally goes down due a problem with a COM component. While I am troubleshooting I would like to setup another host to make regular calls to this service to monitor availability.
It is slightly more complicated that a simple HTTP call though as the service is secured by SSL and WCF authentication (username / password). I'd also like to be able to parse successful calls to see if they return warning / fail states from my code.
Would you recommend any monitoring providers for this or is it beyond the simple monitoring they normally provide?
Regards
Ryan
You could enable WCF logging and auditing facilities either on the server or the client to produce a log of all traffic. Then you can analyze the results using the WCF Service Trace Viewer Tool provided in .NET Framework 3.0 and 3.5 SDK.
In your situation I would probably enable logging only at the message level. This will reduce the amount of information that ends up in the log file and will help you focus on analyzing the data that's actually being sent back and forth from the services.