I am confused by when and how to use the clientaccesspolicy.xml file in Silverlight. What is it for? Right now, my deployed site (not localhost but the remote server) does NOT have it and I can still access the web site and query the database through a WCF web service. Why should I include it in my root directory?
You only need it if your Silverlight app will be accessing a service in another domain.
e.g (from the MS site)
"For example, a Silverlight control hosted at http://contoso.com/mycontrol.aspx can access only services on that same domain by default – for example http://contoso.com/service.svc, but not a service at http://fabrikam.com/service.svc."
When your silverlight application try to access the method of web service.
For the security silverlight first identify the service is valid one not the fake.
For that silverlight first request the "ClientAccessPolicy.xml" file, then requested web service will returns the xml file after that silverlight checks that application is allowed to accept call from current service..if yes then app can free to make a service call to verified service.
Related
If you want to access some REST web services with your Silverlight application, the third party Server(where the service is, you want to access) needs a clientaccesspolicy.xml or crossdomain.xml in the rootfolder.
But how do i consume or access a REST service, which responds with a xml file, with my Silverlight application but WITHOUT any clientaccesspolicy.xml or crossdomain.xml beeing on that server?
if i write the service url in the addressfield of my browser, i can access the service and see response in browser. u can access service with GET.
edit: i already assume, that i would have to use some kind of proxy, but how for a RESTful service? Is it a clientside or serverside proxy?
How to start?
SL security policy prevents you from accessing addresses on a different domain. So the solution is to create a proxy in the domain of your SL app that will forward requests to the web service you want.
The above answer is correct. I have created a Silverlight client library which is convenient for consuming REST. But, more importantly, I have included a pass through to the BitBucket API REST service on ASP.NET Core which demonstrates how to include the clientaccesspolicy for Silverlight. It's all in this Git repo:
https://bitbucket.org/MelbourneDeveloper/restclient-.net
The NuGet for the library is
Install-Package RestClient.NET
I'm using the Composite WebRole approach to host 2 web apps in the same instance and webrole in Azure, one app is using Silverlight and needs to get (for many reasons) the clientaccesspolicy.xml from the root domain which is mydomain.cloudapp.net so it returns Service is unavailable error as expected.
Is there a way to catch the clientaccesspolicy.xml request and redirect it to my custom domain where my clientaccesspolicy file is available? or how can I enable my cloudapp.net domain using this approach? thanks
Working with the Root Container
Enabling Cross-Domain Access to Blobs
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.
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.
I am accessing Sharepoint web services from a Silverlight application, I have put the clientaccesspolicy.xml file in the root of my Sharepoint site, so I can access fine.
What I would like to do though is hard code the user credentials so the web service always connects with the same user.
Is this possible and if so how?
Thanks in advance.
After emailing Tim Heuer, I was informed that is not possible in SL3, but will be in SL4!
I've recently ran into similar case where I need to pass a specific credential to the generated web service client proxy in Silverlight 4 OOB. For whatever reason I am still getting prompted for authentication so, I'm not sure if it's there in SL4.
What I know possible in SL4 is you can force an HttpRequest to use a ClientHttp stack instead of the WebBrowser one. I've used this with SharePoint 2010 OData feed (_vti_bin/listdata.svc) before successfully, but to access SharePoint Web Services (for example: _vti_bin/lists.asmx), it's a different story.
I finally decided to create my own workaround (specific to SL OOB w/ Elevated Privilege) for this that should work on SL3 OOB and SL4 OOB with elevated privilege. Basically creating my own SharePoint Web Service proxy using the ClientHttp stack and composing and passing my own SOAP message manually using WebRequest.
I blogged about how to do this here.