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
Related
I develope a GWT-application which creates a PDF-file at the server, and then transferres it to the client.
At the client-side, a window appears which allows the user either to
open it with a program assigned to the file name ending, or
save it to disc.
I have read several threads to this topic, such as
How can a user download a file in client side (Google Web Toolkit)
GWT: Showing PDF created as POST response
How can a user download a file in client side (Google Web Toolkit)
and that helped me coding the doGet()-methode in my print-servlet like this:
resp.setContentType("application/octet-stream");
resp.setHeader("Content-Disposition:", "attachment; filename=\"" + fileName + "\"");
This works fine when testing and debugging using the local GWT-developement server.
But my big problem is:
After deploying to GAE and running the code on GAE, the created pdf-name is not transferred to the client...!
Instead of e.g. TestPdf-25072016.pdf, the name only consists of the word print.
This leads to the fact that the standard-program for a PDF is not invoked automatically when I want to open it. And, of course, print is not the name of the PDF I want to have...
Where is my failure? Especially I am confused that everything works fine when using the local developement server?
Thanks a lot for your support!
You could use a tool like Wireshark or Fiddler to capture the actual HTTP header sent to you when you call printing in GAE.
Maybe GAE is adjusting the header or just blocking it.
I am running a Tomcat 6 server configured to use port 7787.I have to post data from a Silverlight app to a servlet running on this server.Ofcourse this is crossdomain so it requires me to have clientaccesspolicy.xml in the root.
I have seen various questions about this here and on the web and all have the same answer.To put the xml in webapps/ROOT.This works if I try to access the xml via
http://somedomain/
However since the servlet is running on port 7787 I have to post to somedomain:7787 and thus Silverlight tries to find the xml under
http://somedomain:7787/
This is unsuccesfull.
I am sure that Silverlight does indeed check somedomain:7787 for the xml as I used Firebug to confirm it.Is there anything in Tomcats configuration I can change or somewhere else I can place the xml so Silverlight can find it under port 7787.Or is there perhaps something I can change on the Silverlight side where the POST is being done?
On Windows machine simply copy the two security files to Tomcat's webapps/ROOT folder
As long as you can get response from ...:7787/crossdomain.xml, anyway solution is OK.
Looks like Silverlight only cares about the response.
I created a Silverlight client and it is OK to get response both from WCF service and Tomcat.
I'm running into this problem and its driving me crazy.
Also, we are not allowed to update the version of IIS.
The content on the server (asmx files holding WCF webmethods called via SOAP) exists and I can freely browse in inetmgr to the virtual directory that contains this data. The files all exist all on the file system and the virtual directories all point to the correct spot and have the correct ACLS, but when I go to their URLs all I get is a 404 message.
I have reset IIS, I have rebooted the server, and I have done everything I can think of.
The IIS logs simple return "404 - -" as the entire line contents, with no other data in the line.
The event logs show nothing, and ASPNET is not dying or anything like that.
With no event logs, and minimal logs in IIS , I have no idea what to do and was hoping that others had run into this before.
In IIS logs there should some codes along side the 404 error which will help find the issue.
Check IIS has the correct version of .Net installed using aspnet_regiis command line tool. Also check that ASMX extensions are mapped to the .Net ISAPI filter as they are with ASPX pages.
I have a client who installed our silverlight app recently. it works fine from their server itself. but when they try to run it from a client, they can log in through the aspx login page, but on the main page, which hosts the tag and the .xap file, they see absolutely nothing!
I cannot see their screens, just get occasional screenshots via email and cross my fingers that they are typing the URL I tell them to. Even Shareview is not working for them - they can see my screen but I cannot see theirs.
So I am pleading - help! Please throw out some wacky ideas. I just learned an hour or so ago that they did not even have silverlight installed, so the mornings debugging effort was a waste of time. So who knows what the next fascinating source of problems is?
Here is the user-agent info. Oor app is .net 4.0 could that be the problem? It does noty look to my untrained eye that the client supports 4.0 (from the web server log):
Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 401 3 5 0
Getting closer - I see that the GET request for the XAP is returning 401 - not found! What would do that?
It's very possible that they are blocking XAP files either directly or indirectly at the firewall. XAP files are simply ZIP files and inspection-based firewalls tend to look at these as a security risk. You may want to see if they can setup an exception in their rules.
Hmm..
1) check if your client access the good url. Request their IP address, then check the web server logs. ie: are they requesting the good url, are they downloading the xap? (check if they use a proxy, too?)
2) check that they restarted their browser after installing the Silverlight runtime.
3) Do you handle the UnhandledException event for your Application class? If no, use it to send detailed exception logs to your server on application crash.
4) Use javascriptto initialize your Silverlight application. This way, you can be notified if the runtime fail to start, (for example if it failed to load the xap file) You can use ajax to report the issue to the webserver.
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