Really puzzled by the flaky behavior of LocalConnection.
Using a debug utility(LuminicBox) that uses localConnection to work.
When the page containing the swf is loaded in a browser locally , localConnection works.
When the identical page and swf are viewed 'live' on a remote site, localConnection fails.
Anyone encounter this??
By default LocalConnection allows communication between swfs loaded from the same domain. When you're loading the swf in the browser, the debug utility also has to be loaded in the browser from the same domain.
You can get LocalConnection to work across domains but it requires more configuration. Here's a link to Flex's docs on the subject. This issue is the same for Flash/Flex.
http://livedocs.adobe.com/flex/3/langref/flash/net/LocalConnection.html
I haven't used LuminicBox, but if you have access to the code that initializes the receiving LocalConnection object, call allowDomain("your.domain") on that object.
var lc:LocalConnection = new LocalConnection()
lc.allowDomain("your.domain.com");
//or even better - allow all domains
lc.allowDomain("*");
If the receiving SWF is hosted on an HTTPS page and the sender on a normal page, you need to call allowInsecureDomain.
lc.allowInsecureDomain("your.domain.com");
I think part of the problem is that I DON"T have access to the code that initializes the receiving LocalConnection object, just the sending LC (my application).
I would assume though, that the author of the debug utility would have definitely used lc.allowDomain("*"); Will check further.
The only other cause I am aware of is having an existing LC connection already open, when you try and open a new one.
Related
I have an http handler built and running on my website server. Code in flex generates a http request then navigates to the handler, which generates and streams back file information for the user to download.
Basically the request sends image data and the return result is a pptx stream with the image data in a powerpoint slide.
This worked fantastically this morning until about an hour ago. I have no idea what changed, but every swf I am building which attempts to access this handler is now giving me:
* Security Sandbox Violation *
Connection to https://g1.localhost/Turm/BounceBack.aspx halted - not permitted from https://g1.localhost/Turm/FlashApps/ImageAndExporting.swf?debug=true
I even fully qualified the BounceBack.aspx name (it was a relative url until just now) in case something was confusing the flash player, but as you can see, the url request and the swf are loaded from exactly the same domain (even the same virtual app in the web domain).
I have even added the physical filepath as a 'trusted folder' in my flash player security settings.
What gives? Anyone have any suggestions?
Using the Apache 4.9.1 SDK and latest version of flashplayer.
As mentioned, this worked all day yesterday and this morning. I cannot figure out what has changed, but am having no luck resolving the issue, source code has not changed.
Finally figured out what changed. I move the navigation to my ASPX handler into a seperate method that delays invoation till after a UI update. Becuase I use the same ui components for printing as well as exporting, I tested the updates with the print feature and that worked without error. About an our later, I noticed the handlers were failing. Since the url request is not handled inside a UI interaction event (Like MouseEvent.CLICK) the flash player was preventing the call. Once I moved the navigation back into the event handler, the sandbox violation went away.
If you ask me, not a very good error message due to the actual problem encountered, but ... you learn something every day.
I have crawled the web quite a lot these days, but couldn't get any accurate information on how crossdomain.xml files behave in case of 302 redirects; especially with the sandboxes having changed significantly over the last versions!
I am relatively new to flash... so any advice is more than appreciated!
I have been working on a project lately that uses audio streams with some sort of CDN distribution! what happens is that a common url is triggered, and then the user is dynamically redirected to the next best server available. In my case, i have no access at the server side of things (at least not anytime soon). And the only path providing an appropriate crossdomain.xml is the one performing the redirect. All the other dynamic paths provide exclusively content!
http://resource.domain.com (valid crossdomain.xml)
302 => http://dyn1.domain.com/...
302 => http://dyn2.domain.com/...
302 => http://dyn3.domain.com/...
I noticed that flash doesn't care much if i try to load the audio stream with something like...
var req :URLRequest = new URLRequest("http://resource.domain.com");
var sound :Sound = new Sound(req); // ie. effectively playing http://dyn3.domain.com
sound.play();
It gets both redirecting, and streaming done well! and doesn't bother for any crossdomain file and starts playing!
Although when i try something different, like setting up some custom headers to the request and loading the file with URLStream instead, everything gets messy! Well, the redirect gets done, as expected but all of a sudden i need another crossdomain file in the redirected location!
Is there any explanation to whats happening and eventually ways to resolve this?!
Thanks for your time!
It comes as a site question : i noticed everything to work flawlessly while being in the local-trusted sandbox and errors happening mainly if not exclusively in the remote sandbox. is it possible that the local-trusted sandbox doesn't care about crossdomain policy files at all!?
Summary
Add crossdomain.xml to each CDN host or adopt to limited Sound functionality.
Details
SWF files that are assigned to the local-trusted sandbox can interact with any other SWF files and can load data from anywhere (remote or local).
Sound can load stuff from other domains that don't allow access using cross-domain policy with certain restrictions:
Certain operations dealing with sound are restricted. The data in a
loaded sound cannot be accessed by a file in a different domain unless
you implement a cross-domain policy file. Sound-related APIs that fall
under this restriction are Sound.id3, SoundMixer.computeSpectrum(),
SoundMixer.bufferTime, and the SoundTransform class.
Flash in general has pretty complex cross-domain policies but in your case the bottom line is that you'll need to have proper crossdmain.xml on each host except the one that serves the SWF:
3.1. If your file is served from http://resource.domain.com it's not required to have http://resource.domain.com/crossdomain.xml but it's really good to have one.
3.2. You will need to have proper http://dyn2.domain.com/crossdomain.xml explicitly allowing your SWF to access dyn2.domain.com to be able to use URLLoader and other APIs that provide access to raw loaded data.
3.3. There's a reason for these restrictions - cookies (and other ambient user credentials). If Flash would not require proper cross-domains after a redirect, one could access any domain with user cookies attached by simply loading his own redirector first. This means accessing all user cookie-protected data (e.g. mail.google.com) from any SWF on the internet that's running in your browser.
(ActionScript3) Hi, I'm trying to work out why a URLRequest is failing when viewed via a third party website. Ideally any error could be pointed out in the below code, however, I think it's fine as similar things we do work fine.
Next to ideal would be URLRequest error handling, how can I find out WHY the URLRequest is not pulling the information from time.php? Even if it's just output to a textbox on the timeline (everything works fine when done from the testing environment)
Many thanks
Craig
Scenario:
domain.com (Server 1): file.swf uses a URLRequest to load domain.com/time.php?a=b (so the PHP and the SWF are both hosted on the same domain and server)
example.com (Server 2): PHP page embedding file.swf (which in turn URLRequests time.php)
Outcomes:
When you access file.swf directly via browser, it loads the data from time.php just fine
When you view the page file.swf is embedded on, on Server 2 the loading fails
file.swf
var loaderNameHolder;
var loaderNameHolderLoader:URLLoader = new URLLoader();
var loaderNameHolderURLRqst:URLRequest = new URLRequest('http://domain.com/time.php?a=b');
loaderNameHolderLoader.addEventListener(Event.COMPLETE, loaderNameHolderURLFunc);
loaderNameHolderLoader.load(loaderNameHolderURLRqst);
function loaderNameHolderURLFunc(e:Event):void{
loaderNameHolder = loaderNameHolderLoader.data
gotoAndStop(loaderNameHolder);
}
Security
There is a crossdomain XML in place on the domain's root folder, it seems to make no difference (or is not being referenced/used correctly) however as mentioned similar things I do work fine without modifying this XML
It sounds like a security issue, although you say that you have the crossdomain file in place.
Have you checked the http calls with a tool like Charles (http://www.charlesproxy.com/)? This is definitely the best way to debug such a problem.
Thanks for the tips above, they'll be great resources to keep.
The actual issue was that the Requested URL didn't include "www" (I think because the SWF is embedded with the WWW so it was coming from an "outside" domain. I think I need www.domain.com in my own security XML).
Craig
try adding this code
Security.allowDomain("*");
Security.loadPolicyFile("http://domain.com/crossdomain.xml");
and read about crossdomain.xml using links given here: https://stackoverflow.com/a/9728845/2234089
I ran into this problem and could not solve it, so I have a swf file that loads assets from
another swf file, everything's fine, until I put them on the server, they are under the same
domain, relative path doesnt work nor does absolute path. This is not even a cross domain
problem, since both files are on the same server.
Did anyone ever have the same problem?
Thanks.
If you're using Flex Builder you can set the right -use-network compiler flag.
If you're using Flash IDE and the content is on the same server, make sure
you've got the Local playback security set to 'Access local files only', in the Flash
tab under Publish Settings.
alt text http://www.adobe.com/devnet/flash/articles/local_network_playback/fig01.jpg
That should do it. As Dru stated, what is the error message you are receiving ?
The images comes from this article which might come in handy.
Goodluck!
http://www.ultrashock.com/forums/actionscript/loader-problem-with-swf-from-same-domain-123692.html
try this , maybe can help
we have a small flash component on our website/application to upload multiple files.
This works fine, however we want to get the Content-Type from the headers and its always set to 'application/octet-stream'. From what I've learned this is due to a security of flash sandbox and FileUpLoad will never give this to us.
Is there any other way we could do this in flash (aside from creating an html/ajax multi file upload)?
many thanks
We have had a simlar problem when uploading from a browser. What is sent in the content type is dependent upon the browser and what is installed on the client machine. If it is an extension that the client machine does not recognise it will come back as application/octet-stream.
What we ended up doing was creating mapping functionality from the file extension to the content type. That way we could ensure consistency.