When we try to print the Google Map API for Flash component, it is throwing the Security Sandbox Violation
SecurityError: Error #2123: Security sandbox violation: BitmapData.draw: http://ps6143:8080/aa/XYZ/Main.swf/[[DYNAMIC]]/1 cannot access http://mt1.google.com/vt/lyrs=m@171000000&hl=en&src=api&x=1&y=1&z=1&s= Gali&flc=x3t. No policy files granted access.
To avoid this error we tried to use the alternate API provided by library. But that also causing cross domain issue as it loading some 3d library internally which is not able to access our application.
SecurityError: Error #2121: Security sandbox violation: BitmapData.draw: http://maps.googleapis.com/mapfiles/lib/map_1_20_10_3d.swf cannot access http://ps6143.persistent.co.in:8080/dv/SiteOptimizer/SiteOptimizer.swf /%5b%5bDYNAMIC%5d%5d/1http://ps6143:8080/aa/XYZ/Main.swf/[[DYNAMIC]]/1. This may be worked around by calling Security.allowDomain.
Please help us in resolving this issue.
Thanks & Regrds,
Is this a change to how Flash works? I've read posts elsewhere saying that they used to be able to use BitmapData.draw, and it no longer works.
I used Charles to create a local file mapping for YouTube's two crossdomain.xml policy files (allowing "*") and it still didn't work, so what you say makes a lot of sense. Was there a reason for blocking it for all developers, no matter what the crossdomain policy file states?
This has been true “forever”. But things can change in the way you are hosting your SWF to suddenly cause the images to come from other domains. Or maybe a new version of some library you are using changed its caching or visualization strategy and is now using bitmaps
So does Flash not allow BitmapData.draw from any other domain, despite what the crossdomain policy file says? I ask, because I read another developer was having problems with his project that grabbed images from Vimeo and mapped them onto a 3D cube. He *says* that it used to work and now it doesn't, so I can only assume he is not telling the full story?
Also, before I go ahead and try a different strategy, will I come across the same issue if I try building my app in AIR?
A crossdomain.xml on the same domain that is serving the image will allow BitmapData.draw to work. But the crossdomain.xml file has to have the right settings and be in the right place. I’m not sure how that survives re-directs if at all.
There is no redirect... Charles is a web proxy so it will look completely legitimate to the browser.
According to the help, it's getting the access request from the SWF itself and not the crossdomain.xml file:
In the case of a source object other than a loaded bitmap, the source object and (in the case of a Sprite or MovieClip object) all of its child objects must come from the same domain as the object calling the draw() method, or they must be in a SWF file that is accessible to the caller by having called the Security.allowDomain()method.
So the default state accessing a SWF on a different domain is protected, unless that SWF allows some or all domains to access it via the Security.allowDomain() method.
Sorry, thought you were talking about accessing loaded bitmaps. For bitmaps, either you have the crossdomain.xml to allow BitmapData.draw or you don’t.
For SWFs, there are two ways to be allowed access. If you set the SecurityDomain property on the LoaderContext AND have the right crossdomain.xml file, then you will be allowed access regardless of whether the loaded SWF called allowDomain or not.
I’m not sure what you mean by “access request from the SWF and not the crossdomain..”. I think if you use charles or other network monitors you should see a request for the crossdomain.xml before the request for the SWF. The default location for crossdomain.xml is the root of the domain. If it lives elsewhere, you will need to add code to fetch the crossdomain.xml from that other location.