The Sky is Falling! URLRequstHeader and Authorization
I posted about one of the new restrictions of Flash Player 9.0.115 over here on my blog. http://blog.simb.net/2008/01/17/urlrequestheader-in-as3-can-not-use-authorization-header/
In that post, I explain how the sky is falling and that we are no longer able to use the Authorization header with the URLRequestHeader object. In the post I incorrectly state that the problem does not exist in Flex and AIR, but only in AS3. But that based on the documentation, it should not work so I expect it to fail soon.
As it turns out the problem is limited to Flash Player and some contexts of AIR. So here is the run down. SWF applications that are created in any form that are intended to run in the browser, no longer have access to this header. So whether they are created with Flex 2, Flex 3, AS3 or Flash IDE. If its headed for the browser and your user has updated to Flash Player 9.0.115 this code will error. If your application is headed for the AIR platform, you are in better luck. Any content loaded into the Application security sandbox still has full access to all headers. Only content that is loaded into a secure sandbox will be restricted.
So did I over react to the problem? Maybe. Only because I could not imagine how a change that could affect so many applications, could slip through so quietly. This is one of the first times I can ever think that a release of the flash player has openly broken backwards compatibility. I understand the reasoning for it, but it is a bit of a blow to my flash platform unified runtime theory, just like in the browser, I now have code that can behave differently for separate users.
What does this mean? Well I have to get back to work on the Freshbooks API, and have the Freshbooks guys label it as an AIR library since it wont work in flash player.
28 Jan 2008 Simeon
I am currently trying to fix our authentication for one of our applications and came across your post. I first heard of the problem from a single Mac user, and thought “that’s strange” - this week, no one can login.
I completely agree that disallowing the authorization header was a very sneaky/dirty move by Adobe. There are many tutorials out there that tell you how to do it; all no longer valid. What the hell Adobe?
Yeah its a tough spot. From what I have gathered this is partially as a result of one of the “flash is insecure” claims by hackers. Because many of todays routers use basic auth, and not many people change the password, it was actually very easy to use flash to disable someone internet connection.
Of course this is a security flaw in the routers, not flash player, but the action has been taken none the less.
If you control both the client and the server you can work around this by changing the name of the header you use for authentication. As long as its not another word that is blocked, then you should be fine. i dont have any details on *how* to actually do that. It was just one of the work arounds proposed to me by Adobe.
So does this mean if we want to sign into twitter with as3 and tweet from a flex app it is no longer possible using the library ? that’s harsh…
Hey Nick,
That is exactly what that means. Now its only a matter of time before twitter finishes upgrading its authentication scheme (there are several under consideration) but for now http basic auth is a no go.
Hey Simeon,
You mention that Authorization can be set in AIR apps. However, I’m attempting to do this in an AIR app working with GData and still getting ArgumentError #2096.
Any insights? I would of thought AIR would allow balls to the wall manipulation of the headers, but it seems to be crippled as well.
Hey Simeon
Like Brooks, I’m running an AIR app (that worked in Beta 3 or the Flash player of that era anyway) and now it suffers that same error. I’m using httpservice to login to google calendar, then parsing the session key and using for Authorization header in subsequent interactions on my calendar (this is the approach Google mandates).
In AIR, with POST…and I’m toast. This would limit me from doing any kind of intelligent interaction with web apis requiring authentication because the entire session requires the session key in the header.
As far as my philosophy on security, if you want to provide an application of any kind, for any platform of any power or value, you need to establish trust with the originator of the application. You’ll never microcontrol application providers and still have them provide anything of value.
Hey Brooks and Danno. I am not sure what to say, I have AIR applications that are connecting using this header in the 1.0 release. The documentation says that its not restricted in AIR.
All of that aside, Adobe released a technical document last week that outlines their path to returning the Authorization header to flash player use as well. There will be another update to Flash Player in April that with a little modification to server communication, will allow you to send the Authorization header again. So they recognize that this was an issue for many people.
The only information I have for your delima was that I am actually using the URLLoader class not the HTTPService. So you might run a test with that and see if they are restricting the header on httpservice.
Simeon,
Do you have a link to the Adobe technical document you mention that outlines a path back to allowing the Authorization header?
I have written yet another update on this thread here including all the information and links that can help people get Authorization headers back.
http://blog.simb.net/?p=1696
Simeon,
I have been trying to get AIR to work with GData ClientLogin with no luck using both URLLoader or HTTPService.
No matter what I try I always get this error: Error #2096: The HTTP request header DQAAA……..pYVA3MvmOksKg
cannot be set via ActionScript.
You mentioned that you have GData services working in Adobe AIR. Could you please provide some example code that works?
My understanding is that you can’t