I'm getting the following error when I connect my Silverlight app to my WCF service. I host this wcf as a self host service.
An error occurred while trying to make a request to URI 'http://lmr-hero/iSponsorWebSite/projectService.svc/basic'. 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. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.
What are the possible reasons for this error?
If your Silverlight application is not hosted on the same domain as the service then you will need to put a clientaccesspolicy.xml or crossdomain.xml file on the server that hosts the service.
See this link for details: http://msdn.microsoft.com/en-us/library/cc197955%28VS.95%29.aspx
Right click the .svc file and hit view in browser. Check to see if it's even being hosted and running correctly first. That will give you a good starting place.
Be careful that you set up a WCF web service correctly in Silverlight, when using Silverlight to consume the web service. Unlike a console mode client, in Silverlight you cannot just create a WCF New Item in your Solution, but must, under the .Web portion of your Silverlight solution, right-click, Add a New Item that is called "Silverlight-enabled WCF Service". Now you can go to the Silverlight app folder, add a Service Reference and you will not get this run-time error. This will avoid the run-time error the original poster refers to.
Related
Is it possible to access Rally's SOAP services from Silverlight? I am able to access the service from a .NET 2.0 proxy in a desktop application, but not via a WCF client proxy in Silverlight. I get the following familiar exception,
System.ServiceModel.CommunicationException:
An error occurred while
trying to make a request to URI .... 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. This error may also be caused by using internal
types in the web service proxy without using the
InternalsVisibleToAttribute attribute. Please see the inner exception
for more details.
I believe the problem is caused by trying to make a cross domain request from Silverlight, which requires a cross domain policy file installed on the server. If this is the case, why does the desktop application not require such a policy?
I'm not a Silverlight expert, but this looks like a cross-domain scripting/security sandbox that Silverlight imposes to make sure that Silverlight clients don't make requests to sites other than the server/host from which they were downloaded, unless the Silverlight client is specifically granted that right by the service provider/devloper. In the error message above:
"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."
I think the "owner of the service" means the owner of the Silverlight host, rather than the "external" webservice (in this case, Rally).
Desktop and/or console apps wouldn't have this same sandbox restriction. You would probably encounter the same issue trying to access another vendor's webservices via a Silverlight client.
You might find this Silverlight-specific thread:
Cross Domain Policy
Helpful for the specifics of how to setup and configure a Silverlight cross-domain policy file on your server.
Silverlight was built with security in mind. That means cross site scripting from the Silverlight application is turned off by default and must be enabled on a case by case basis. A .NET desktop application, on the other hand, generally has far greater security permissions and can call whatever web services, COM objects, and native APIs it pleases.
The way you work around this issue in Silverlight is to create a service on your server. The Silverlight client code calls your server side service which in turn calls a third party web service. The server side service can bet .NET, java, whatever. Web servers can generally call whatever they like -- problem solved.
Resolved this myself by using the extended permission features available in Silverlight 5. Since the xap is deployed on an internal internet, this solution was acceptable.
I have a .asmx web service which is hosted on IIS. I took the service reference and i am calling this web service from my silverlight application. But i am getting a communication exception as follows.
An error occurred while trying to make
a request to URI
'http://test.bookmyshow.com/services/wsDebtorTrans.asmx'.
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.
This error may also be caused by using
internal types in the web service
proxy without using the
InternalsVisibleToAttribute attribute.
Please see the inner exception for
more details.
I have added the required policy files (clientaccesspolicy.xml and crossdomain.xml) to my web service. Following is the content of my clientaccesspolicy.xml and crossdomain.xml
crossdomain.xml and clientaccesspolicy
I tried to access the above two files from my browser and the xml files are displayed properly in my browser. I have used basicHttpBinding. I have seen lot of tutorials online and tried them but still I am facing the same problem. Am I missing anything here? Please help me with this problem.
Just to clarify, you only need a CrossDomain.xml file OR a ClientAccessPolicy.xml file. You don't need both. Also, where did you put those files? Did you put it in the Services folder, or did you put it in the root of the server? For example, http://test.bookmyshow.com/ClientAccessPolicy.xml instead of http://test.bookmyshow.com/Services/ClientAccessPolicy.xml . The file should be put in the Root of your application and not the Services folder.
When am trying to connect to the wcf service from silverlight am getting the following exception and here am using the crossdomain.xml and Clinetaccesspolicy file also
Exception : CommunicationException was Unhandel by the usercode
An error occurred while trying to make
a request to URI
'http://localhost:3500/WCFService/Service.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.
This error may also be caused by using
internal types in the web service
proxy without using the
InternalsVisibleToAttribute attribute.
Please see the inner exception for
more details.
You have to add the crossdomain policy xml in the hosted application.
See Cross Domain Policy
This is because Silverlight is like a client application and it will make wcf service calls to http://../somesite. The crossdomain policy xml says that it accepts calls from otherdomains(i.e Silverlight XAP file which is loaded in the client browser.)
You'll probably need to implement the Silverlight fault behavior too to see the actual error
I am using a silverlight with wcf and when I use the .web project then it runs but when use the silver light project to run the following exception throws:
An error occurred while trying to make a request to URI 'http://localhost:9000/Services/BLWCFSvrc.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. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.
I want to use the silverlight project to debug my code
Thanks in advance
In order to access network resources from Silverlight, the domain hosting the resource must provide a client access policy file; this is designed this way for security reasons. See here for details: http://msdn.microsoft.com/en-us/library/cc645032%28VS.95%29.aspx
I think your problem is different that just having the clientaccesspolicy.xml, the fact that it runs under the web project, means that you are delivering policies, if you have those added as seperate files under the web project then they wont be deployed when you run the SL3 app seperately, but im sure you figured this out and you're delivering the policies via WCF using webHttp binding (RESTful style), if not, you should.
I think the problem is that when you run the webproject, it builds to your local IIS and executes from there, IIS will allow the SL3 app to communicate with ports/addresses different from the ones that the site is hosted on
when you run SL3 app natively, VS2008 auto generates a test html site for it to be hosted in with some default settings, and uses VS2008 built-in hosting service, which does not allow communication to an address/port different from that of the hosting address. (even though Silverlight is a client side library, VS2008 can do this)
so if you want to run the Silverlight application natively, meaning actually executing the XAP, you can deploy it to IIS, and configure IIS to deliver XAP files, or just install it and run it out of browser and let it update from IIS the deployed version
Just copy a clientaccesspolicy.xml file (for an example take a look at this post; you can even use this sample) into the root of your webserver (eg: c:\inetpub\wwwroot\).
This should help.
We have a Silverlight app which we wrote which calls a Silverlight-enabled data service. The Silverlight app cannot require a login, as it is required to present data to the unauthenticated public.
We have some schmoe who took the time to examine our Silverlight app, one way or another figure out what service it is calling, and then wrote his own client to slurp off the data so he can post it on his site and pretend like it is his. We need to prevent this.
How can i limit my data service somehow to ONLY accept requests from my silverlight app? I tried using the allow-from domain uri setting in the clientaccesspolicy.xml file to limit access to the service only from the domain in which the silverlight app sits (say mydomain.com). This did absolutely nothing though, and the service is still serving up requests to clients from outside the domain. (I tested this by putting my SL app on a different domain under our control).
What is the proper/best/most effective way to limit the data service so only our app can use it? Thanks!!!
I'm using SL 3 and .NET 3.5.
The clientaccesspolicy.xml tells the Silverlight application which Webservice it can consume. Not preventing people accessing the Webservice.
You can try using a authentication login even though its not required. This prevents 'schmoes' accessing your webservice.
Also use Dotfuscator to prevent 'schoes' to disassemble your Silverlight application and acquire the login.
Silverlight webservice security follows the same patterns you'd use for ASP.NET security, especially services exposed to AJAX. The best way to do make use of ASP.NET's authentication.
RIA Services is an even better way to handle this. It rides on top of the ASP.NET authorization, but validates on both the client and server-side automatically to combat service spoofing. It let you take care of both client and server-side authorization by adding attributes to your methods indicating that the method requires authorized access, and by which groups or users if you need to be specific.
In addition to wire-side security and obfuscation, remember that clients can attach a debugger to Silverlight applications running in their browser. See this example from MSDN Magazine's Security IQ Test, November 2008.