> This is the standard Flash sandbox security model in Action. This would > happen to you on Window and Macintosh as well. It is extremely confusing to > the user to have this popup occur.
Agreed there: apart from having to load the slow macromedia site to be allowed to change the settings, I used to read it as give the URL of the site you want to allow it to connect to. But instead you give the URL/directory/filename of the swf you trust to be allowed to connect anywhere. Another frustration is needing to restart the swf you wanted to run (which often means a browser restart). The security model is a good idea, I just find it too user-hostile to take control of (a simple "trust this swf" button in the pop-up, in addition to the OK and Settings buttons would be nice; ideal would be "trust for this run only" and "trust permanently"). But, the problem here (see my other email) is the linux standalone player doesn't prepend current directory to the filename when considering security privileges. > We were having security issues similar to this (and other ones as well like > cross-scripting limitations) with a standalone projector application. We > switched to ScreenweaverHX instead of a projector and things are working > smoothly now... Making a projector has always worked for me as a way to avoid these kind of security restrictions (including flash 8 content run with the windows player). I.e. an exe is always assumed trusted. So I guess it was those cross-scripting problems that screenweaver fixed/bypassed? Darren _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
