PD2: Just to add to "the way certain similar security decisions have been made in the past". Remember crossdomain.xml rules? They "evolved" to more strict standards, but without breaking existing content. In FP6, there were no crossdomain policies. In FP7, domain restrictions were enforced, but these applied to >= FP7 swf's; old rules applied for contented targetted at FP6. In FP8, the control got more fine grained: now, instead of domains, subdomains were matched; fine, but that didn't affect swf's compiled for FP7.
This was Macromedia "style". But now, the rule of respecting other people's work, time and money, has changed. Now, they change the rules in the middle of the game. And if that breaks your work, well, screw you. You might want to check our website, where we have some not very thorough guidelines on our new policies -- if you're lucky enough to find them because our site sucks a bit, you know --, with some suggestions to find a workaround for that site you developed three years ago and now is broken by our new release (but don't take our word on this, sucker, because we could change our minds for our next release). And it's not the first time it has happened. I remember not so long ago, I had an app that suddenly and silenty ceased silently working. After a couple of hours of pulling my hair, I found out why. The app connected to a web service hosted on a different domain. A properly configured crossdomain.xml was in place, but Adobe decided that now, since the WS added some header to the HTTP Request, you had to have a special directive in the crossdomain.xml to allow it. Again, they decided that it was ok to screw you, because they had second thoughts on how to manage certain security restrictions. Sorry for the rant, but this really pisses me off. Cheers Juan Pablo Califano 2008/10/17, Juan Pablo Califano <[EMAIL PROTECTED]>: > > PD: > > This moronic change affects not only already deployed content that uses > FileReference programatically. It also blocks any multypart-encoded POST > that contains a file. I've just tested it in FP 10. > > So, if you're taking a snapshot of some movieclip and uploading it to the > server, you'll first have the user click on a button to proccess the image, > and then click again to confirm the post, or something like that (I guess, > haven't tested it yet). > > I could put up with this crap for new content, but now I'm going to have to > change at least 15 sites that are already using that functionality and will > start to fail silently when people begin to upgrade to FP 10. > > Sounds like a lot of fun... > > > > Cheers > Juan Pablo Califano > > > 2008/10/17, Juan Pablo Califano <[EMAIL PROTECTED]>: >> >> I don't think that's how these kind of changes have been handled by >> Macromedia in the past (Dave points out good examples). Plus, this "feature" >> is not dealing with a really critical exploit. It's not they're fixing a >> security bug; it's a security enhancement to their design because they >> failed to foresee a pontential problem in the first place. And it's ok, >> sometimes you only learn with experience; but keep this non-critical fix as >> what it is, an enhancement for new stuff, and don't break a ton of apps that >> have been deployed over three years. >> >> >> Cheers >> Juan Pablo Califano >> >> >> >> >> 2008/10/17, Zeh Fernando <[EMAIL PROTECTED]>: >>> >>> The problem is if they took that approach, the vague security hole would >>> continue to exist - a potential exploit would simply need to compile for >>> an >>> old version of the player. >>> >>> It's awful, but I wouldn't really say it's an "stupid" decision. As soon >>> as >>> they decided to cripple the functionality, making it global is the only >>> way >>> to go. It's a no-win situation. This is also the way certain similar >>> security decisions have been made in the past. >>> >>> I think the only real solution would be to let it work as usual, BUT add >>> an >>> optional checkbox to the file browsing dialog that would let the user >>> disable further dialogs from that Flash movie (or at least THEN make it >>> respond to events only), in the same vein Google Chrome does with >>> Javascript >>> dialog popups. It works very well to combat the focus-stealing exploits, >>> and >>> I'm not sure why Adobe didn't take that route instead. >>> >>> >>> Zeh >>> >>> On Fri, Oct 17, 2008 at 4:47 PM, Juan Pablo Califano < >>> [EMAIL PROTECTED]> wrote: >>> >>> > Not that it doesn't work, necessarily, but now the browse() method will >>> > only >>> > be callable in response to a user action, not programatically. >>> > >>> > http://theflashblog.com/?p=423 >>> > >>> > In my opinion, this change would be ok if it were applicable only to >>> swf's >>> > compiled for version 10 or greater, but changing an existing API in a >>> > way that deliverately breaks existing content that has been working for >>> > years is a stupid decision and a serious lack of respect to users of >>> the >>> > platform (end users and developers), to say the least. >>> > >>> > >>> > Cheers >>> > Juan Pablo Califano >>> > >>> > >>> > 2008/10/17, Merrill, Jason <[EMAIL PROTECTED]>: >>> > > >>> > > HOLD THE PHONE. So are you saying FileReference upload no longer >>> works >>> > in >>> > > AS2/AM1 published .swfs in Flash 10????? If so, that IS VERY BAD and >>> > will >>> > > break many applications. >>> > > >>> > > Jason Merrill >>> > > Bank of America >>> > > GCIB & Staff Support L&LD >>> > > Instructional Technology & Media >>> > > Join the Bank of America Flash Platform Developer Community >>> > > Are you a Bank of America associate interested in innovative learning >>> > ideas >>> > > and technologies? >>> > > Check out our internal Innovative Learning Blog & subscribe. >>> > > >>> > > >>> > > -----Original Message----- >>> > > From: [EMAIL PROTECTED] [mailto: >>> > > [EMAIL PROTECTED] On Behalf Of Dave Segal >>> > > Sent: Friday, October 17, 2008 2:18 PM >>> > > To: 'Flash Coders List' >>> > > Subject: [Flashcoders] Flash 10 file upload >>> > > >>> > > The new Flash 10 security restriction on file upload and lack of >>> backward >>> > > compatibility is killing me. What was Adobe thinking unleashing this >>> > > nightmare and breaking working applications? Is there any quick fix >>> for >>> > > this besides recoding old swfs? >>> > > >>> > > _______________________________________________ >>> > > Flashcoders mailing list >>> > > Flashcoders@chattyfig.figleaf.com >>> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>> > > >>> > > _______________________________________________ >>> > > Flashcoders mailing list >>> > > Flashcoders@chattyfig.figleaf.com >>> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>> > > >>> > _______________________________________________ >>> > Flashcoders mailing list >>> > Flashcoders@chattyfig.figleaf.com >>> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>> > >>> _______________________________________________ >>> Flashcoders mailing list >>> Flashcoders@chattyfig.figleaf.com >>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>> >> >> > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
