This is an odd one.
I'm using Amazon S3 for storage of files in my Silverlight 4 application. Because of the file restrictions associated with the REST API and S3 (files have to be < 1mb for REST), I'm trying to get the SOAP calls to work.
I followed the tutorial written by Tim here http://timheuer.com/blog/archive/2008/07/05/access-amazon-s3-services-with-silverlight-2.aspx
minus the parts about CNAME's since he updated and said it was bad to do that for security,
but kept having issues connecting till it just magically started working this morning and I was able to get a list of all my buckets! So I thought it was fixed, until a few minutes ago when I restarted Chrome and then tried the application again, and it no longer connected to the SOAP endpoint and VS gave me the cross-domain error.
However, I thought about all the stuff I had done earlier to get it working, and the only thing I could think of was that I had a tab open with the clientaccesspolicy.xml file open via bucket.s3.amazonaws.com/clientaccesspolicy.xml. So I tried opening it up again in a new tab, opened my application in another, and then the SOAP calls started working! It only works when the file is open in a tab!!! I've tried it in Firefox and IE as well, same thing!
I have Fiddler, and it doesn't seem to actually ever make a call to the clientaccesspolicy.xml, unless it's hidden inside one of the SSL calls which then there's no way to tell, but there's no straight out calls to .s3.amazonaws.com/clientaccesspolicy.xml going through Fiddler like some other questions on here said there would be.
Would really appreciate some help here guys, thanks.
Edit:
Since someone will probably ask for it, this is the clientaccesspolicy.xml file I'm currently using. I know it's not the most secure, just trying to get this to work before I take the wildcards out
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-methods="*" http-request-headers="*">
<domain uri="http://*"/>
<domain uri="https://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Edit 2:
This appears to be an issue HTTPS. If I force my endpoint to be http, instead of the https required by Amazon, Fiddle does show SL accessing the clientaccesspolicy.xml file.
When you open the clientaccesspolicy.xml file in another tab I'm guessing you are passing some credentials which allows you to access it. This sets a cookie which Silverlight can then use to access the clientaccesspolicy.xml file as well. When you close the browser you lose the cookie and thus the access to the file.
So I figured it out.
The first problem, about why it would work if I opened it, was not because of a cookie being set (per say), but that accessing it that way over https made me accept the SSL security policy for amazon.
The second problem, I shouldn't have had to accept it. The SSL wildcard amazon uses, *.s3.amazonaws.com, doesn't match buckets that contain periods in them. So as I was following Tim's tutorial I made all my buckets like this
bucketname.domain.com
and when I tried to access it that way through SOAP (and subsequently https), it wasn't working because the wildcard wasn't being matched. Changed all my buckets to contain no buckets, and it worked.
Should also note that Tim's tutorial no longer works as he's using http and in June of this year Amazon forced SOAP calls over https, so http calls no longer work.
Related
after one day of thorough searching for solutions, I'm at a standstill over the following issue:
I am adding a aspx-page with silverlight app as a feature to my sharepoint.
The app accesses the sparql-endpoint from a virtuoso service and works fine outside of sharepoint. clientaccesspolicy.xml is added to the virtuoso and sharepoint root. Both are accessible over http:
<?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>
I even added crossdomain.xml in both locations after this problem crept up on my and added both files explicitly to the sharepoint path via central-admin.
I'm still getting a securityException...
Please help me with this,
thanks in advance.
After some several more hours wasted, I hammered it out on my own.
For anyone arriving at the same crossroad:
If you are certain that crossdomain.xml is in place and you silverlight app works outside of sharepoint, this specific security-exception stems not from a cross-domain violation, but more likely from one of the other url access restrictions documented here:
As it is stated there:
'When users get an error that results from one of these access policies being violated, the error may not indicate the exact cause.'
This error might have any of the listed causes. (a major negligence of msdn in my opinion)
Since 'Cross-scheme access' and 'Cross domain-access' is out of the picture, this leaves only a 'Cross zone-access violation'. This means your Silverlight app and the service endpoint got to be in the same zone to be allowed to communicate (e.g. Internet or Intranet). Since my SPAQL-endpoint is hosted at localhost for now (an Intranet address as default in IE) and my sharepoint address http: //my.comp.name is by default in the Internet-zone this error was thrown.
To get rid of this error you have to either host your endpoint on an Internet-address or place your sharepoint address in the Intranet-zone manually.
After some more googeling I found the right configuration in the Internet-options.:
->security ->local Intranet -> sites ->add:your sharepoint address (http: //my.comp.name)
That's it, hope I saved you some lasting wrinkles.
take care...
We have a Silverlight application that requests some rss feeds from the client. Not from the server. All the other developers on our team are able to get all 5 of the rss feeds.
**Update to this issue. - I have cleared out all the rss feeds other than one. When this one rss feed is run through I still get a 404 on the clientaccesspolicy.xml file. I am the only one on our team that gets this. We have put in some exception handling around the Rss. We are getting this error.
Error reading feed http://sports.espn.go.com/espn/rss/ncf/news: [Security error.]
but fiddler still tells us that I am getting a 404 on the clientaccesspolicy file
I have also turned off all my firewalls.
There is clearly something different between my machine and the other machines..
Make sure the clientaccesspolicy.xml exists on your machine.
Eg if your website application is at
http://localhost:123/MySite/
The clientaccesspolicy.xml file needs to be in
http://localhost:123/clientaccesspolicy.xml
I've got a Silverlight application that makes a cross-domain request. The clientaccesspolicy.xml file exists on the server I am making a request to and is correctly configured.
I know that it is correctly configured because when I use the application to make a request from my machine I receive a response with no problem.
When a second individual on a corporate network about 300 miles away tries to use the same application, launched from the same URL, to make the same request, he instead gets a security exception.
Here's the odd part. I requested that he download Fiddler so that I could see the request and it's response, and thereby gain some insight into the problem, but when he runs the app with Fiddler open, the request succeeds.
This happens in both Chrome and IE. With Fiddler everything is fine. Without it, it doesn't work.
We've tried clearing his history, deleting the Silverlight app from the cache, everything I can think of.
The request is being made to a private network (which he is on), I make the request through a VPN connection to that network (in case for some reason that matters).
Any thoughts as to what's causing this bizarre problem?
Despite the fact the Fiddler "fixes" the issue it would still be worth while getting this second individual to save a .saz file from fiddler for the successfull set of sessions and then for you to compare them with a successfull set you have from your own machine.
An analysis of the differences may reveal a potential cause when fiddler is not in place.
Another approach would be to use a network protocol anaylser such as Wireshark. The elimination of the proxy that Fiddler represents may be enough to expose the problem, of course such tool is much more technical.
This post is simply to catalog the solution for future users. Thanks to everyone who helped.
The actual problem turned out to be (just as EricLaw -MSFT- suggested) that the client's machine was zoning the request URL as Intranet and the Silverlight application as Internet, and I am not permitted to make requests across zones.
EricLaw's direct responses may be viewed in the comments under the original question.
The URL below (provided by Eric) contains information regarding the denial of cross-zone request, as well as solutions.
msdn.microsoft.com/en-us/library/bb250483(VS.85).aspx
I'm hosting a Silverlight Business Application Template derived application on an IIS Server. I'm using the built-in Forms Authentication which is working perfectly.
Unfortunately, I've added an additional service which has peculiar behavior. If I remote into the server and use the site everything works as expected. If I connect to the site from another PC, Authentication still works but my custom Domain Service is failing with the following error:
IE Throws this Error Message:
System.ServiceModel.DomainServices.Client.DomainOperationException:
Load operation failed for query
'Get___'. Exception of type
'System.ServiceModel.DomainServices.Client.DomainOperationException'
was thrown.
I tried debugging the process and get a little more information:
System.ServiceModel.DomainServices.Client.DomainOperationException:
Load operation failed for query
'Get___'. The remote server returned
an error:NotFound. --->
System.ServiceModel.CommunicationException:
...
My clientaccesspolicy and crossdomain policies are in both wwwroot and the root of the website and are the following:
<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="*" />
<domain uri="http://*" />
<domain uri="https://*" />
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true" />
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
The Domain Service that's failing is using an ADO.NET Entity Model. The entities of which are in the same the aspnetdb database that is used for authentication and I've granted file permissions for the IIS User (and Administrator, I got desperate) for the App_Data folder which contains the db.
Again, all services work if connecting locally on the server. Only the Auth/Registration services works when connecting remotely.
I've searched for two days and tried every solution I can find but can't seem to get it working. Any advice or direction would be greatly appreciated.
Although this is pretty late for your project but it might help somebody else. Sounds like you are having problem with authenticating to the underlying database. You may want to look into what sort of impersonations are happening at database level.
I had a similar problem, and it turned out that I was trying to access the database as Sliverlight client pc account which never existed in authorized accounts (although my authentication was working perfectly just like in your case). Changing the Application Pool Identity fixed it for me (I was using Network Service account on a PC joined to a domain which uses Computer$ account to login on your behalf)
When you run into CommunicationException, you really want to look at InnerException which will tell what is the real issue.
If there's nothing then you'll need to debug on server side (step through service) to see what is throwing the exception.
CommunicationException occurs if an Exception is thrown on WCF server side and not wrapped into a fault causing the channel to become faulted (in my limited experience at least).
Hope this helps somebody.
WCF Tracing didn't help me! It gives an Empty message.
Finally,
FOR MY CASE,
I removed [RequiresAuthentication] like attributes from methods
I removed [RequiresAuthentication] from Domain Service Class (check all partials)
If it works on local but not on server it must be a configuration problem. In my case I used membership.ResetPassword() function which is disabled in web.config as enablePasswordReset=false.
Beside this some people says some methods just invoke-able in asp.net.compatibility mode.
Hope helps someone else.
I have a problem to access SharePoint Webservice over Silverlight.
An error occurred while trying to make a request to URI
'http://sample:8000/_vti_bin/Authentication.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.
Please see the inner exception for
more details.
Some questions:
How do I correctly deploy clientaccesspolicy.xml over Sharepoint Designer? Simply open site in designer, add file and then publish?
The site where clientaccesspolicy.xml should be deployed use forms authentication. I wasn't able to use Sharepoint Designer to publish there. Because of that, I created new zone for this site, which use Windows Authentication and published clientaccesspolicy.xml there. Both use same content database, didn't ?
If clientaccesspolicy.xml will be published, how can I allow this file be accessed anonymously?
Regards
Anton Kalcik
Here answers to my question 1. and 2.:
In Sharepoint Designer you open the site over: File -> Open Site -> In text field "Site name:" type URL of your site. Than drag & drop clientaccesspolicy.xml in root of your site.
If you have Form Authentication, you don't need for this step create new zone (but for some reasons it can be useful). You simply open web browser and type URL of your site. Then fill up text fields (always with user that have administrator privileges) and check "Sign me in automatically". After that will Sharepoint designer use this credentials for specified URL.
If you can help me with question Nr. 3, or you have some other solution, how can I access clientaccesspolicy.xml from Silverlight, post it!
The way we handled this on our project was to use an HTTP Handler. We put the clientaccesspolicy.xml file in the _layouts directory (which is shared across sharepoint sites) using a feature (you can also just manually copy it there).
Then we added our HTTP handler to the web.config handlers section. In our handler we check to see if the request is for /clientaccesspolicy.xml and if so we rewrite the path:
if (path.ToLowerInvariant() == "/clientaccesspolicy.xml")
{
HttpContext.Current.RewritePath("/_layouts/clientaccesspolicy.xml");
}
I'm not sure if this will bypass the security so it might not fully address your issue. But at least it gives you a method to access this file.
That is fine.
It should be, provided you haven't setup a whole new site somehow.
It shouldn't be as that would be a security risk. If you need to authenticate via WindowsAuth for the services so should you for the clientaccesspolicy.xml.
Keep in mind that clientaccesspolicy.xml must be at the domain root. In your example it would have to availble from http://sample:8000/clientaccesspolicy.xml. If you can't open it from your browser at that URL, your Silverlight client won't find it either.
The easiest way to get the file in the right place is to just copy it there via FTP or explorer. The file should be available to anonymous users (read only of course).
I find more realeable way to implement sharepoint httpHandler: it returns all content of clientaccesspolicy.xml himself
public void ProcessRequest(HttpContext context) {
if (context.Request.Path.ToLowerInvariant() == "/clientaccesspolicy.xml") {
context.Response.Write(#"<?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>");
}
}