There are tighter security rules in 4.6 requiring use of the securityDomain parameter when loading modules from different domains.
Thanks for the information. Is that a setting I can apply to the ModuleLoader?
Here's the basic code for the modules:
modLoader = new ModuleLoader();
modLoader.url = url;
modLoader.percentHeight = 100;
modLoader.percentWidth = 100;
Separately, there's also a method called during initializtion that loads a bunch of policy files, using
Security.loadPolicyFile, Security.allowDomain, and Security.allowInsecureDomain
I should also add that the modules and application are in the same amazon s3 bucket, while the page that loads the application is on heroku.
Thanks for the help!
Yes. New options were added to 4.6 ModuleLoader
Somehow I don't think this is the issue. I tried using Flex Builder 3 on an old windows machine, using the exact same project that the original developer had successfully built moments before, and the behavior was the same. When the root application gets up on the staging server, it does not load the modules.
Could it be that I HAVE to have flash builder 4.0, like the original developer, or could there be something else going on?
Sorry, but I still don't understand how it could be that the exact same code compiled on three different machines would trigger different security rules, when uploaded to the same location on the web. I've asked the developer for a dump of his compile config file, hoping that might illuminate something.
I don't know what, specifically, to change otherwise. Any further suggestions would be greatly appreciated!
I’m still trying to understand the scenario.
If machine A can build an application swf and module swf and it “works”, does that mean you can run the application from any other machine?
Then when machine B builds the app and module swf (and this assumes you are re-building both and making sure you aren’t picking up one from a cache), it doesn’t work?
Or is it that machine A can run the app from machine A only?
Are you getting any security warnings in the console?
Sorry for the lack of clarity.
The project is basiclly a widget wrapper that loads its tools via modules. The widget and the modules are stored on S3 at the same domain, and the html wrapper changes depending on where the widget is displayed (it's embeddable, but always points to the same application swf on S3).
Machine A is running Flash Builder 4 and the project compiles using the Flex 126.96.36.1997 SDK. Machine A can compile the widget successfully, meaning that when we upload the widget to S3, it still works. The user of Machine A zips the source code and sends it to Machine B.
Machine B is running Flash Builder 4.6. After unzipping the source code and importing the project, making sure that the project builds using the 188.8.131.527 SDK, Machine B compiles the widget and uploads it to S3, where it ceases to import the modules. From the debugging session, the modules start to load, get to about 5 - 10% downloaded (~600k modules), then sends the error "SWF is not a loadable module". No other error appears in the debug session.
Machine C (running windows and Flex Builder 3) shows the exact same result as Machine B.
I hope that clarifies. Incidentally, I compared the dump-config between Machines A and B, and they were identical except for system paths.
Is the SWF size relatively the same? Are you rebuilding and re-deploying the modules as well?
SWF sizes are very close in size. I have tried using the original modules and new ones. It doesn't seem to make a difference for the spark.
The modules I publish work fine; It's only the application root swf that doesn't work when Machine B or C compile it.
1 person found this helpful
I don’t know how S3 works. Is the full URL domain the same? Any textual differences will fool the security model into thinking it is a different domain. For example:
Are two different security domains, and so is bugs.adobe.com.
Can you show more of the module loader code? One scenario for this error is when the module gets unloaded or garbage collected.
It finally worked! The application was being loaded https, while the modules were regular http.
I guess your initial point about the security restrictions on FB 4.6 was correct, though I'm not sure why the Flex Builder 3 scenario got the same results.
Thanks so much for your help.