Going to try to consolidate this thread a bit. On 11/5/14, 11:53 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi, > >> The Ardisia example sizing problem feels like a SecurityDomain issue. >> After you force a resize with the divided box, the app scales down to >>fit >> instead of resizing. Third-party content may not size correctly unless >> “import loaded” which I don’t think is the default. > >Tour De Flex uses mx:SWFLoader to load content and doesn't set >trustContent (which defaults to false) so I believe that means that >content isn't being "import loaded". [1] Setting it to true would make it >"import load" but that has other implications. (see line 1896 of >SWFloader.as which sets the loaded contents securityDomain to be >the.current domain) Scale content default s to true [2] so I'm not sure >that explains the odd clipping. If trustContent=false, the SWFLoader doesn’t know it loaded another Flex SWF. There is code in SWFLoader that tries to size loaded Flex SWFs differently than other SWFs. From your other post: > There's already a wildcard cross domain file for Flexicious [1] Gee, I sure hope Flexicious doesn’t also serve internal apps off this domain. A wildcard crossdomain.xml is equivalent to leaving the door unlocked. If the door is for a refrigerator and you are giving away free beer, that’s great, but if it is the door to your house and you keep other valuables in the house, you are more likely to get robbed. >>And if import loaded, then SWFLoader should have trustContent=true, but >>probably only when loading third-party, just to be careful, and maybe >>have >>its own whitelist of domains baked into the SWF. >Which would mean we need to make a release every time we add a 3rd party >example which is what we are trying to avoid in the first place. We have to decide how secure we want to be. If we accidentally leave a hole where someone can inject a URL to load, it might get exploited. If we put a whitelist in an XML file on our server, that might be secure enough. > If (and I can't imagine this happening) we find that a 3rd party > is doing something naughty we can just remove them from the 3rd party >xml > file until they fix the issue. IIRC, there are two issues: A) How hard do we have to try to prevent bad stuff from happening? It is fine to stop using a credit card reader that is stealing credit card numbers once you know about it, but should we have made it harder for someone to hack it? It isn’t that the folks who have submitted examples to us are evil, but what if one or more of them is some other popular third-party library that turns out to have a security hole? B) Similarly, the third-party may not trust Apache Flex TDF to be a good secure host. What if there is a security bug in Apache Flex SDKs or in TDF? Or in some other third-party example? If FooCorp supplies us an example that uses a third party library with a security hole, it could attack the third-party example supplied by BarCorp. BarCorp may prefer to remain sandboxed for that reason. Fundamentally, bad people suck, and there are too many of them out there. -Alex
