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 :)
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.
Hey
I was trying out your solution to the problem, using the following code snippet:
function fetchData(url:String,credentials:String):void
{
var request:URLRequest = new URLRequest(url);
request.method = URLRequestMethod.POST;
var authHeader:URLRequestHeader = new URLRequestHeader(“Authorization”,”Basic ” + credentials);
request.requestHeaders.push(authHeader);
var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, handleComplete);
loader.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
loader.addEventListener(HTTPStatusEvent.HTTP_STATUS, onHttpStatus);
loader.load(request);
}
I am developing in the Flash Authoring Tool (CS3).
The XML source is at the same domain as the swf-file.
I have added the suggested directive to the cross-domain file.
However the line:
request.requestHeaders.push(authHeader);
crashes with the following message:
ArgumentError: Error #2096: The HTTP request header Authorization cannot be set via ActionScript.
Is this supposed to work in the later releases of Flash?
to SiggeLind
this worked for me in version 124
OK.. now i get it :)
http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403030&sliceId=2
(there’s a listing for every flash-player 9 release)
Starting with Flash Player 9.0.124:
In Flash Player 9.0.124.0 the Authorization header is no longer blocked. For more detail see “An Authorization header does not work for an HTTP request” (TechNote kb403184).
@SiggeLund
I have the same scenario and snippet as Siggelund posted above on Aug 25th.
I have files installed in two places. These files are identical:
1) My personal computer: Files in the same folder: crossdomain.xml, index.html, test.swf, test.fla.
2) On the server: Files in the root directory of http://www.example.com: crossdomain.xml, index.html, test.swf
(For utter clarity, the swf is embedded in the html.)
Here are my 3 test setups:
A) Flash CS3 environment – compiling and running the swf in the player alone. I get the Argument Error #2096 as discussed plenty above. I don’t see a way to control which version of the player is used when I compile the .fla. I have 9.0.124 installed, so I assume it’s using that one, and if it is, why would I still get this error?
B) Loading index.html (from files on setup 1) in Firefox, with Flash 9.0.124 installed. This works just as expected. Couldn’t be happier.
C) Loading http://www.example.com, in same browser, I get a security error: [SecurityErrorEvent type="securityError" bubbles=false cancelable=false eventPhase=2 text="Error #2170"]
I’m mainly interested in knowing why C doesn’t work, but also would like to understand why A doesn’t work.
I started to think that the site to which I’m sending my POST needs to have the cross domain policy file on THEIR server, not mine . . . but the success of test setup B rules out that thought.
Any help is much appreciated.
Below is my cross domain policy file:
@Leif
My xml got stripped. I’ll attempt to show my cross domain policy again (I have manually stripped the brackets)
cross-domain-policy
allow-access-from domain=”*” secure=”*”/
allow-http-request-headers-from domain=”*”/
/cross-domain-policy
Adobe security guys suck…they don’t understand the security problem very well… but they use their pighead to trouble the developer.