I need to disable all the aspects of functionality which access the client file system in a flash/flex application. I started having a look on how to do this. It appears that the package flash.filesystem need to be importated to allow the interaction with the file system.
However, I did not find any reference to this package in the application.
I am a beginner concerning these technologies so maybe I am missing a point here. Do I need to look into an other direction?
Thanks
Basic flash/as3 resource: http://www.adobe.com/devnet/actionscript/as3.html
The flash.filesystem library is for AIR applications only because flash is not supposed to be able to reach outside the browser to affect a client's computer. That would be a security violation. Even AIR apps are highly restricted in this way.
Update:
Related Question:
flash actionscript access filesystem without air?
This is brand-new in Flash 10.
Update 2:
And an older reference in Flash 9 here. Though it mentions that it's still subject to the user turning off permissions via their settings manager.
Related
I've recently been slated with a task to port an existing Flash Player-base game to a desktop app for publication on the Steam platform. The Adobe AIR framework seems like a logical choice for distribution, especially given the latest updates in AIR 3. Given the fact that I'm relatively new to flash/flex development, I've read through a fair amount of AIR documentation on the Adobe site in order to gain a better understanding of what the task involves. In general, I think I have a decent idea of what needs to happen, but there are a couple of wrinkles that may affect if/how it is even possible to port to the AIR framework:
The AIR application will need to load the actual game client from an external server due to the quick turnaround time of the client development.
Since the AIR application will be deployed on Steam, I want to use the Captive Runtime bundling that's available in AIR 3.0, i.e. no need for the user to 'OK' a separate AIR installation.
Have minimal impact on code changes within the external SWF as I'm not the primary developer of the game.
My first priority is to figure out the best approach for loading an external game client SWF into an AIR application. Initially, I tried to utilize Loader.load(), but that resulted in the following exception:
SecurityError: Error #2070: Security sandbox violation: caller http://localhost/MyClient.swf cannot access Stage owned by app:/AS3_AIRTest.swf.
at flash.media::SoundMixer$/set soundTransform()
at com.company.client.sound::SFXManager$/load()
at global/client.util::loadEmbeddedSounds()
at MyClient()
The offending code is:
static public function load():void {
SoundMixer.soundTransform =
new SoundTransform(Client.Settings.PlaySFX ? 1 : 0);
}
Upon hitting this exception, I decided to read up a bit more on the AIR / Flash player security domains. I have a much clearer understanding of why the exception occurred, but I'm still uncertain what the best approach would be to load the SWF and not receive the exception above.
After scouring through numerous posts on various forums, I found that a number of developers use Loader.loadBytes() to bring the SWF into the application sandbox. From an ease of implementation standpoint, I can see why many choose to go that route; however, I'm not inclined to pursue that approach due the potential dangers to user systems in the event that the external server is compromised.
The second approach that I've read about is that I can utilize a sandbox script bridge, and write an interface to grant certain privileges to the external client SWF. I'm hesitant to go this route at the moment because the game client is fairly complex, and I'm not entirely certain how much access it will require of the stage via different flash APIs. I haven't written this approach off as it sounds like it may be the best bet, but it could potentially be a large endeavor and I want to have minimal impact on the client SWF.
The final approach I've read about is by making an HTML AIR application. My understanding (sketchy at best) is that a SWF loaded via HTML (I believe in a frame/iframe) will have its own stage. My line of thinking is that if the HTML app loads a main page, which in turn has an iframe with SWF embed of the game client, then the client SWF will load in a remote security sandbox and have access to its own stage. My hope is that the SWF would behave as it does in the Flash Player.
This leads me to the following questions:
Is my line of thinking correct about the HTML app?
Would the client SWF have access to its own stage and pretty much behave like it does in the Flash Player?
Can HTML-based AIR applications be bundled with the captive runtime?
Can I use a traditional flex application with HTMLLoader to accomplish the same goal or does it need to be a full-blown HTML app?
If HTMLLoader can be used, would I need to provide the sandbox script bridge meta tags in the iframe tag?
Any help would be very much appreciated at this point. It seems like there are a number of options available, but I'm not sure which path is the right one to pursue at this point in time.
Thank again.
Josh
You have already investigated a lot. I was going to mention Loader.loadBytes technique but you mentioned that it is not secure. Actually, you could take care of security if you knew the signed hashes of the SWFs that may be downloaded. I remember to have read this approach in a AIR team's manager's blog but I can't recollect the link at this time. Basically, the approach would work if you knew all of the SWFs before hand that could be downloaded, and then generated their signed-hashs and put those hashes in an XML which shipped with the initial AIR app. Then, the initial AIR app can download those SWFs, compare their signatures and load them in application sandbox if it matches up with shipped hashes etc.
(Long question with lots of points, but here goes)
You are correct that passing the Stage object through a script bridge isn't going to work. So, removing the code that accesses the stage and possibly using the script bridge to get the job done in each specific case would be necessary.
If you embed the SWF in an HTML page, it will indeed get its own stage. It does not matter whether this is an "HTML-based" AIR application or an ActionScript-based application that uses the HTMLLoader. (Really the two are the same thing.) You don't need an iframe for this. This sounds like the easiest approach, especially if you aren't adding many AIR-specific features.
For information on signing, see http://www.adobe.com/devnet/air/flex/quickstart/articles/xml_signatures.html
The other thing I'd look at, if you haven't already, is what facilities Steam offers for doing such updates. Is the turn around time for uploading a new project/update to Steam really greater than the time it would take to add this post-install update system to the app itself? (I hope you aren't in one of those Dilbertian situations where, on paper, it looks like you can save time by doing weird things. In my experience, miracles created by dragging sliders around in Microsoft Project (or the like) don't pan out.)
Just I have started learning flex for my project. This is project is a kind image, video, audio file management which is accessible from local hard drive like adding, deleting etc..
I heard that Air is doing this kind of work. But our client asking that the project should run only on the browser not like a application.
I have searched lot of tuts. But I haven't get much tutorials. please give me some suggestion to get this type o tutorial.
Thanks
Browser applications cannot manipulate local hard disk contents, regardless of their type - Flash, or JavaScript, or Silverlight - security model is similar for all of them. Try to persuade your client with seamless install of AIR applications (google "AIR badge install".)
If you have limited server resources and expect a lot of traffic to a Flash site, is there a way of NOT having to serve Run-Time Shared libraries, but rely on Adobe to do this for you?
For example, if you want to make sure "framework_4.0.0.14159.swz" is always fetched from "fpdownload.adobe.com" and not from your own server, what modifications should be made to the config section:
<runtime-shared-library-path>
<path-element>/opt/flex4/frameworks/libs/framework.swc</path-element>
<rsl-url>http://fpdownload.adobe.com/pub/swz/flex/4.0.0.14159/framework_4.0.0.14159.swz</rsl-url>
<policy-file-url>http://fpdownload.adobe.com/pub/swz/crossdomain.xml</policy-file-url>
<rsl-url>framework_4.0.0.14159.swz</rsl-url>
<policy-file-url></policy-file-url>
</runtime-shared-library-path>
...
<static-link-runtime-shared-libraries>false</static-link-runtime-shared-libraries>
Also, is there any reason this might be a bad idea?
Please notice, I am using the command-line compiler, mxmlc.exe (not Flex Builder).
UPDATE:
I guess my issue is more about the errors I get at run-time than the above question. In fact, the reason Flash tries to download from my server to begin with is that the Adobe download fails (see error messages in my comment). I am therefore going to accept the below answer and, if I don’t succeed in solving the problem, I might open up another question.
from Using the framework RSLs:
Note: You can point to the SWZ files
that are hosted on the Adobe web site,
rather than deploy your own SWZ files
as RSLs. In this case, view the
default entries for the RSLs in the
flex-config.xml file to see how to
link to them.
You can, but you never should - adobe.com does go down sometimes, or the client maybe allowed access to your site and not Adobe's (because of a corporate firewall, for instance).
Please feel free to add multiple answers, each with a single point, to make the voting work well... and don't add something someone else already said.
All I know about AIR is you can have local storage, but there must be more to it... offline access is another key one but then you can run a SWF locally if you save it to your PC.
The biggest benefits (in addition to LocalStorage/SqlLite support) would be...
Read/Write Access to the local file system (including support for native file system dialogs)
Native Drag and Drop Support
In addition, Air apps aren't just Flash based, but can also use HTML/JavaScript via WebKit
Update:
All the info you need on Air is on the Wikipedia page. (and it's external links) http://en.wikipedia.org/wiki/Adobe_Integrated_Runtime
In short, if you need native filesystem and limited desktop interaction Air is the way to go, if you don't need these features, use Flex in the browser.
If you need additional system integration but still cross platform, try Appcelerator/Titanium, Java/JavaFX, Python with WxWidgets, or C++/QT.
It really depends on what you want to build.
You can find all features specific to AIR here :
http://www.adobe.com/products/air/features/
Running a swf file locally doesn't really work for applications that have been pushed out to end users. The user's won't have access to any updates of the application (which an Air application does). Also a swf run locally might not be able to connect back to the server it came from, depending on the security settings.
In reality the nice part of flex is you don't have to commit to web or air. You can develop an application that can be built to run in both the web and on the desktop. For example you can put a majority of the code in a library project and then have a web specific and desktop specific projects that use that library.
Two other advantages of Air - one is that it allows you manage updates to your application and have the updates automatically pushed out. Second is it supports drag and drop (similar to native file access) so you can support dragging pictures or files onto your application.
AIR apps run using Adobe AIR runtime. It has access to your file system and includes more powerful capabilities. Whereas, a web-based flash/flex app runs in a flash player within a web browser. It runs in a sandbox. It has limitations. It can't access local file systems (without user intervention).
Features of AIR:
Can access file system.
With AIR 2.0 you can access (communicate) to native file (executables) of that OS. Means you can communicate to a C app which does some OS specific functionality from the AIR app.
Encrypted Local Store for securely storing credentials.
Easy drag-and-drop functionality.
Behaves as native desktop applications.
Notifications.
System tray icons.
.. and much more.
When using FileReference.download() to retrieve a file from a server, I'd like to give the user the option to open the associated application directly rather than having to save it to disk first.
Is this possible in Flex 3? And, if so, how is it done!
Thanks,
Mark
ps. I've tried doing URLLoader.load(URLRequest) also, but no dice...
navigateToURL(urlReq, "_blank") works in most cases, but do not open Excel, CSV files(MS office apps) in IE 7 and older versions.
Nope, you can't do that unfortunately. My guess is that this is due to security restrictions.
From a web application this is most certainly not possible. It might be possible from an AIR application by asking the operating system to handle the opening of the file and leave it at that. Windows and OS X should be able to handle it gracefully.
Why Adobe restricts such actions from web applications makes sense. It would be a glaring oppurtunity for anyone to create a regular site with a flash app that downloads and runs a virus without the user actually knowing anything about it.