September 29th, 2008 by Kyle
Tags: crossdomain.xml, crossdoman, flash, Flash Player, Flex, security, web-service, webservice
Posted in: ActionScript, Flash Player, Flex
Earlier this week I was helping a customer trouble shoot a webservice crossdomain.xml issue.
I pointed him to a blog post I published a while ago as a reference on how to code webservice stuff in actionscript instead of mxml:
http://flexmonkeypatches.com/flex-webservice-with-auto-repeat-and-increasing-timeout/
I was a little embarrassed to find that my sample didn’t work anymore.
The code was fine and the app worked when the swf was run from Flex Builder (thus avoiding sandbox security issues). I hate saying “do as I say and not as I do”, so I decided to took a closer look.
It turned out that my crosdomain.xml file, which was this:
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>
no longer met new security requirements for the newer flash player.
I was using FLash PLayer 9.0.124.
A little searching and I found this blog post:
http://enefekt.com/sansbrowser/2008/06/05/updated-flash-player-901240-security-gotcha/ which pointed me to this Adobe knowledgebase article: Arbitrary headers are not sent from Flash Player to a remote domain
This led me to change my crossdomain.xml to look like this:
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*" />
</cross-domain-policy>
and presto, change-o….my sample app started working again.
(Oh ya…and make sure you are not getting an old swf or crossdomain.xml from your browser cache!
Google Chrome cached things which made me think things were not working after I had checked them using Firefox.)
Tweet
No Comments »
