I am surprised this isn’t talked about more in the blogosphere. The only reason I got to this was because a couple of my Flash applications broke this weekend and it took a lot of digging by quite a few of us on my team before we got to the root of the problem. So here is the deal: With all the goodies that have come with the latest Flash Player, one of the features that seems to have arrived is a stricter security model. There is a complete article on the updated security model can be found here on the Adobe Devnet site. A more bite sized sum-up of the article can be found here. As you see, the 2 big changes is the move to XML schemas rather than DTDs and a new site-control tag for meta-policies on crossdomain access.
Ah, so that’s breaking my app.
Well, not really. Before we updated our crossdomain.xml files, I just wanted to confirm that that was indeed the problem. So I enabled logging on my Flash Player (to see how to do that check the logging section on the article here). The log though surprised me. Here is what I saw (I have edited the site names where I was seeing the issues):
Error: [strict] Ignoring policy file at http://[site name]/crossdomain.xml due to missing Content-Type. See http://www.adobe.com/go/strict_policy_files to fix this problem.
Error: Request for resource at http://[site name] by requestor from http://[swf url] is denied due to lack of policy file permissions.
Yikes. So seems the problem was that our server was not sending Content-Type headers for the xml files and the new Flash Player is a lot more strict about that, rejecting such crossdomain.xml files.
Hopefully this helps someone out there. If you do load data across domains, do verify they work on the new Flash Player.
[Update] Also check out the changes to authorization headers support for basic HTTP Auth:
One thought on “Be careful with the new Flash Player 22.214.171.124 security changes.”
thanks for posting this.
normally we can overcome these security settings by always allowing access in the global.security.settings however it seems that running the app over http is the only way for now for the kind of communication our applications require.
great resources on the issue though, thanks a lot.