April Flash Player Updates
Last week Adobe released the details of an update for Flash Player that will be released next month. While Flash player updates are typically nothing to be concerned with, this time may be different. If you use flash to connect to an outside source for data you need to review this document and see how you will be affected.
Customers for whom the following situations apply should read the article in detail:
- Use of sockets or XMLSockets, regardless of the domain the SWF is connecting to
- Use of addRequestHeader or URLRequest.requestHeaders in any network API call when sending or loading data cross-domain OR Provides access to content on remote domains as a web service provider
- Use of SWFs that are exported for Flash Player 7 (SWF7) or below that communicate with the hosting HTML by any means
- Use of “javascript:” through network APIs to communicate outside a SWF
Specifically the second item is important for me as I have posted about an issue regarding using HTTP Authorization headers in flash player recently. In the 9.0.115 update to flash player were some some significant changes to security model of flash, including the restriction of some previously unrestricted request headers. This change was made in response to a security bulletin but had some negative side effects for developers using HTTP Basic Auth for security on web services.
Through the improvements in the April update a solution has been provided to allow HTTP Request headers to be allowed by 3rd parties. In the same way web service providers currently must post a cross-domain-policy file at the root of the site to provide flash player access, providers can now add to that cross-domain-policy file a node which defines what hosts may pass additional headers. By supplementing the <allow-access-from domain=”*” /> policy with <allow-http-request-headers-from domain = “*” /> web service providers can again allow users to send Authorization http request headers to remote servers.
There are several other changes that will be pushed out to Flash Player in the April update. If you are an Adobe Technology Platform developer utilizing the flash player you need to give this article a read. The only downside to all this is that we will have to wait for this update to push to a significant number of users before we can count on this solution for our customers. I hope your business is in a position to help users upgrade quickly 
18 Mar 2008 Simeon
[…] player and sure enough, support for HTTP headers are part of the update. Check out Simeon’s write-up for more […]
Thanks for the info Simeon!
I think there is a small syntax error in your post:
should be
- Randy
Sure, except where you’re trying to use HTTPService with GET which won’t pass *any* headers at all. HTTP POST works fine with the right crossdomain.xml in place, but not GET.
What gives? Have Adobe fallen victims to knee-jerk security response rather than carefully thought out responses?
The current situation with Flash/Flex and basic HTTP service access is a disgrace.
Hey Brett,
It has always seemed odd to me that you can’t pass headers with a get request. But that is not anything new to these security releases.
Their are other libs that have been created to pick up where httpservice leaves off. Maybe one of those can help you with your app.
So from what I’ve been reading, there is a version of Flash player out in the wild that support no Authentication: header, even with a proper crossdomain.xml. Is this true?
Yeah you got it jason. the Flash player 9.0.115 had no way to pass a header called authorize. Depending on your setup you could use another header that is not restricted and then use mod_rewrite on the serverside to move things along.
Or just force your uses into the new flash player which can use them again when the crossdomain.xml file setup correctly.
Hey Simeon,
Excellent informative posts on this topic. I’m pretty new to Flex and have quickly run into this issue needing to call a web-service outside of my domain that needs basic auth.
As I read the crossdomain.xml spec - it appears that the web-service location needs to host the crossdomain.xml file - not the .swf file location. While that is probably fine for owners of both domains, what if my desired web-service is Amazon S3 or some Google API that requires basic Auth. Asking Amazon or Google to list my site obviously isn’t going to happen.
Am I mis-interpreting the spec?
Thx,
-Brett
Hey brett. You are exactly right. The crossdomain file goes on the server which holds the webservice. This allows them to define who can have access.
In terms of your examples. There is a ticket in googles site to work on this. I am not where I can grab that ticket number. Amazon has been really good about their cross domain stuff. I know several flash based apps that pull resources from s3.
Hope that helps.