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.
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.
17 Replies to “Flash Player 10 Surprise: Error #2176”
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.
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. 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.
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.
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.
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.
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.
This issue is really annoying me. I’m not a poor bastard who complain by the way ;oP
I just need in my project that a function which opens the file dialog box is called either from a button click or from another function. Why? The first click button is inside a large buttons panel. So due to the importance of this button, I decided to initially place an enlarged version of it in a more visible place. Then when the user clicks on it, this enlarged clone is tweened towards the original one in the buttons panel until it fades out. I wanted to eventually give to it the same functionality the original one has, so, by means of a TweenEvent handler, I call the same function which acts as a MouseEvent handler whenever I click the original button (I used the trick of assigning … args to the function parameter so that it didn’t throw any error when this function is not called by the MouseEvent). So, any suggestion to work around this?
This is a poor solution, as it is limiting. A proper solution would give the user a confirmation dialogue to choose. The user can determine whether to allow the domain attempting to invoke .download, or .upload via script. “jessewarden.com would like unlimited download/upload access on your computer, is this ok? [NO] – [YES]”.
I really love the way Adobe does security. It protects both me and my users from… aaa… ummmm… I don’t know. But I know it does a great job protecting us, soo many security features. They do care a lot for us, I can tell!
Goodbye Flex, hello Java!
I’m here for the same reasons – posting a PNG of user generated avatars when they save them i.e. click the “save” button. So, user interaction from a button IS triggering the POST, but in an indirect way as I invoke another class to actually take and post the snapshot.
Thanks to Adobe I now have to essentially “break” my nicely architected code to fix it.
I wonder if I should just post to an Adobe forum all the goading I get off my C++ / Java developer colleagues, for using Flex.
These red marks on my forehead are from me banging my head against this very problem for a few hours. Got it working though. Wasn’t sure how to properly embed pngencoder in the IDE so I used aspngencoder (by aswing). Works! Thanks for pointing this out.
Count me as another poor bastard…My resize before upload swf was all set. It took me a while but finally got it (first flash project I made no less!) and I thought it was obviously me being a noob. Nope, it’s Adobe being lame.
I don’t want to have to make a submit button in flash. In my case I want my file upload field (just one not multi) to be placed where ever and it’s designed to look just like normal one… Then I want a normal submit button in html/js to send off the submit from wherever I see fit in the design.
Sigh. Anyone have any kinda work around?
Cloning a click event (the browse for file button) and then dispatching that again for the actual submit didn’t work. Security saw right through that.
Also tried LocalConnection to call from another “button” swf a function in the “main” swf to then submit the form and it didn’t work.
My next step is to try to send from the submit to the main swf then from the main swf send all the data back to the submit swf and do the call there actually since that will be within a click event. That’s a lot of data passing between swfs and I’m curious to see how that’ll work ..Lots of hoop jumping. Probably won’t work either =(
40kb limit and localconnection makes it too unreliable and slow to transfer an image that way… I suppose AMF could be used but that requires then data to be passed back and forth to the server. Man Adobe…Come on…Let LocalConnection call the load() or browse() methods will ya? It’s not ExternalInterface at that point. It’s a very concious embed of a swf, a very deliberate action. Where’s the security issue??
Well that took a few days, but I got it. base64 encode the byte array to a string. Post the string along, base64_decode(), fwrite() (in the event of PHP) and ta da! Perhaps not the most secure…Isn’t that ironic, Adobe’s security forces us to circumvent and be less secure…But it works. I want to submit my form via ExternalInterface darnit and I’m gonna do it!
AMF also would be a viable solution I imagine. http://www.adylevy.com I believe does to get around the security.
Stupid sandbox security. Stupid.
Thanks to this blog post (and more importantly, the comments suggesting to change filename to fname in multi-part uploads) it was an easy fix.
Comments are closed.