That’s right kiddies, I just got bit by the new security restrictions in Flash Player 10. A developer I’m working with claimed his new image save feature worked. I tried it, and it didn’t. This morning, another developer sings praise in an email chain, and I’m like huh? I try again, and get the:
Error #2176: Certain actions, such as those that display a pop-up window, may only be invoked upon user interaction, for example by a mouse click or button press.
Doh!
The converted image received from the server would trigger a FileReference.download. Adobe did make announcements with commentary, but the unique nature of the change, and the fact that Flash Player 10 didn’t have wide adoption when these announcements came out (still doesn’t) made them pass through one ear and out the other. They weren’t relevant at the time because Flash Player 9 works, and you move on with life. Not to mention the fact this is an event driven security change, which makes it not so black and white.
Fixing this in our Flex app isn’t a big deal, it’s just that some of our team is on FP9, including their development boxes. The con is, we weren’t planning on developing for Flash Player 10, but now we have to. The pro is, we can now leverage FP10 features such as saving images locally vs. using a server to do it.
Naturally I’m wracking my brain this morning trying to remember all the applications I’ve written that utilized FileReference.upload and download. I’m pretty sure all were initiated by a mouse click. I just feel bad for all the poor bastards who utilized ExternalInterface to do it on past client websites and are now screwed.
RSS Feed
Ha! I feel sorry too for those poor boys complaining at the forums. Fortunately, being the smart ass I am, I’ve always used a mouse click to initiate FileReference.
Mario
October 23rd, 2008
I was bit by 10 as well. Only in my case I was bit by a new security ‘feature’ that I don’t recall being mentioned anywhere before the release of 10.
Apparently, even sending a file in the POST data of a regular URLRequest triggers a security exception if it is not a direct result of a button click. Flash 10 applies these new security restrictions on anything that looks vaguely like an upload, even if it’s not through FileReference.
What I found even more perplexing is that in the same Tech Note that described the new security restriction, they described how to get around it. Just rename the ‘filename’ parameter in the POST data to something else ( I changed it to ‘fname’ ) and surprise! Flash doesn’t recognize it as a File anymore. I’m sure there is a reason to implement new security restrictions and a workaround for them at the same time but to me it seems like Adobe is just trying to break stuff.
Jamie Scanlon
October 23rd, 2008
@Jamie. I was bitten by that one, too. I just can’t understand why would the want to block a file being posted. WTF could be wrong with it? It’s not that I’m grabbing an arbitrary file from the user, I’m just taking a screenshot (and no, I can’t POST as a result of a user’s action because the player is not fast enough to encode a 800 x 600 BitmapData to PNG or JPG without getting unstable on many machines, so I have to break up the processing with a timer).
I could change the parameter, but then from the server side grabbing it as a file would be problematic.
So, for this one, I just decided to base64 encode it and then decode back on the server. But I’ll have to recompile at least 15 apps, and then change the backend accordingly for each of those sites.
I’m wondering what kind of h4Xor can’t figure out how to change “filename” to something else or base64 encode a ByteArray ( and they don’t even have to write a routine for that, there are many available already). So, what really intrigues my is what’s the rationale behind banning those POST’s?
If anyone has any hint, I’d be most grateful.
Juan Pablo Califano
October 23rd, 2008
I’m one of the poor bastards using ExternalInterface to initiate the file upload dialog box. The website has a very distinct look and feel, and nearly every imaginable action lies in an IFrame, including the “browse for file upload” button. I’ll have to break the news to my client that the button will have to be in the flash object now.
Mike Burns
November 6th, 2008
i understand the security risk but this affected batch downloading on http://www.poddymouth.com which used to be able to do a download of multiple mp3s a user purchased.
Adobe, there should be a fileReferenceList.download method.
seth
November 8th, 2008
I got here because I have this error in an app. This fix was easy, but what is more secure about tricking my users into clicking FOR ANY REASON to start an action? How does it protect them? Gets you wondering what Adobe understands about things like security. Just when I was going to bet my future on AIR. Maybe not.
Daniel Rosenstark
March 1st, 2009
I really dislike the way they are doing this. Being tied to a player right this is really bad for developers if the maker of the player doesn’t play nice.
Steve
April 14th, 2009