Updated: flensedCore, CheckPlayer, flXHR
A major update has been released which affects all 3 flensed projects, flensedCore, CheckPlayer, and flXHR. All users are encouraged to upgrade as soon as possible.
Here’s a run-down of the major things to note (more details can be found in the documentation and release-notes for each project):
- Both CheckPlayer and flXHR have been tested thoroughly on a wide spread of browsers and platforms. The pass/fail notes can be found here: flensed Documentation
- A new test-suite tool is available for easy testing of CheckPlayer and flXHR in various browser environments. The tool can be found here: flensed Test Suites
- CheckPlayer now supports two new events, SWF_TIMEOUT and SWF_EI_READY. The timeout is an optional setting that times-out a non-responsive loading request of a SWF asset. The EI-ready is an optional SWF ExternalInterface callback function to check for availability/initialization on the loaded SWF (since the EI takes some time to be ready after a SWF is fully loaded). Both events tie into the DoSWF callback function feature, which allows your code to respond definitively when either of these events occur, and either load a new SWF asset or display other alternative content.
- flXHR now supports the username/password parameters to the open() method call, which if non-empty, will create an ‘Authorization’ header and append it to the request.
- flXHR now has a new feature called ‘instancePooling’. Essentially, this feature is most useful when integrating flXHR with Ajax frameworks (jQuery, Dojo, etc). The feature instructs flXHR to keep references to flXHR instances around, and when new instantiation requests come in, if a suitable idle (already-used) instance is available, to re-use that by sending back its reference, instead of the time/memory penalty of creating a new instance. This should greatly improve the performance of flXHR in a multiple-request environment, especially with JS frameworks.
- Both CheckPlayer and flXHR have undergone some significant polishing in terms of code clean up, proper memory management, robust asset loading, etc.
- Lastly, flXHR has received a major security upgrade. Details of this security change are far too intricate for this post, and will instead be handled in a separate post and in dedicated pages. These writeups are forthcoming very shortly. The short story is that (what we deem as) a security ‘hole’ in Adobe Flash Player’s cross-domain policy model was identified and reported to Adobe, and is pending a response from their engineers.
But rather than wait for a future plugin update, flXHR’s code has *temporarily* (hopefully!) been augmented with code to attempt to plug the hole in the best way possible. The change in behavior that authors will now see is that the cross-domain policies will be enforced more strictly, in that both the flXHR.swf’s originating domain *and* the URL domain of the HTML page that hosts the flXHR.swf will be checked for cross-domain authorization (before, only the SWF’s domain is checked).
Please update flensedCore (to v0.2), CheckPlayer (to v0.7) and flXHR (to v0.6) as soon as possible to take advantage of the bug fixes, security updates, and new features! Join us in the forums and in our google-group mailing list for more information and answers to any questions you may have!