Locked

Using ExternalInterface to contact JS when using the file schema

New Here ,
Aug 30, 2018 Aug 30, 2018

Copy link to clipboard

Copied

Hello! I'm trying to use ExternalInterface to interact with JS code from Flex. It seems everything works when my resources are loaded by the engine (not using a browser but a WebView based on Chromium) from a http or https schema. ExternalInterface does not work instead when resources are loaded from the file schema.

I read around and found this is probably a security mechanism, and according to Manage centrally the Trusted Location Settings it should be possible to enable trusted locations.

I'm not developing a web site, I'm developing an application which loads the Flash view into a WebView based on Chromium, and I would like to enable the location of the SWF during the installation of the application. According to that discussion it should be possible to do this by simply adding a text file inside a directory named FlashPlayerTrusted, adding the path to the resource you want to trust. Extension of the file is not clear, I read txt works but also cfg. Unfortunately I tried many possible combinations, but still I cannot succeed. The only way I have is to manually use the settings page, which is not possible for me.

Anyone who knows if something changed in this mechanism? There is incoherent info about the location of the FlashPlayerTrusted directory. Is it supposed to be in C:\Windows\System32 or C:\Windows\SysWOW64 for 64 bit systems? Anything else I should check maybe? Anything I can do to investigate further?

Thanks!

Views

330

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct Answer

Adobe Employee , Sep 04, 2018 Sep 04, 2018
Adobe AIR is the supported path for building a desktop application using Flash technology.The local filesystem functionality you're talking about is old, and the world has moved around it.  When running in the PPAPI, Flash Player basically lives in a chroot jail.  We have a view of the filesystem mediated by the PPAPI interface.  It looks to us like we can see the filesystem, but it's really pinned to some random subdirectory deep inside of the Chromium instance's directory tree.  It's pretty us...

Likes

Translate

Translate
Adobe Employee ,
Sep 04, 2018 Sep 04, 2018

Copy link to clipboard

Copied

Adobe AIR is the supported path for building a desktop application using Flash technology.

The local filesystem functionality you're talking about is old, and the world has moved around it.  When running in the PPAPI, Flash Player basically lives in a chroot jail.  We have a view of the filesystem mediated by the PPAPI interface.  It looks to us like we can see the filesystem, but it's really pinned to some random subdirectory deep inside of the Chromium instance's directory tree.  It's pretty useless in terms of accessing content on the local system.

Furthermore, we disabled the ability of Flash Player to read from the local filesystem by default a year or so ago.  In the context of modern web security, a browser plugin shouldn't be able to read from the local filesystem.  The original intent was to operate in security sandboxes, so you had this concept of "read from the local filesystem but don't talk to the network, but not really though, because you can still send requests for external assets like images)" and "talk to the network, but don't read from the local filesystem".

The problem with the first case is that it's inherently leaky.  You can use network APIs that don't technically "send" data, but they're sending requests, and if you're clever, you can encode data into the request and retrieve it on the server side.

I don't think that what you're trying to do is going to work without asking your users to make a bunch of super hacky configuration changes that weaken their security posture.

If you were using AIR, you'd have working filesystem APIs and all of the other ActionScript APIs that you need from Flash Player.  There are also a lot of libraries that implement Flex data exchange protocols (AMF, etc.) in JavaScript.  If you're just using Flash Player in your Chrome web app or whatever as a hacky way to get to the filesystem, that's not going to work.  If you're using it as a bridge to LCDS or other backend services shared by the Flex application, then finding JavaScript-based support for those protocols and eliminating Flash Player from the equation might be a better approach.  You can check out the Apache Flex community over at flex.apache.org, and I bet you'll find a lot of good, current resources on that front.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Sep 05, 2018 Sep 05, 2018

Copy link to clipboard

Copied

Hello,

thank you for your answer. I need to integrate an existing Flash app with another application. The app already uses heavily ExternalInterface. The only option I have is a WebView, which is properly integrated with the rest of my framework. Luckily, it seems everything works properly when accessing resources from a local webserver. Even better would be to use the file schema, but I can probably live without it.

I see I can set trusted locations properly using the settings app: by adding the path, ExternalInterface works from the file schema. Unfortunately I cannot ask my users to do that. So if no other option exist, I'll have to keep using a local webserver.

Thanks for your answer!

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Sep 06, 2018 Sep 06, 2018

Copy link to clipboard

Copied

No problem!  I figured that running a local webserver was out for the same reason that administrative controls were a non-starter, but that's probably the best approach that you can take.  This is actually what I recommend to everyone doing local development as well.

The local filesystem support in Flash is problematic for a number of reasons.  As the security constraints in major browsers have evolved over the last few years, the resulting behavior is now intractably fragmented.  If you can interact with everything like it's a hosted web application, you avoid all of the platform-specific quirks that would otherwise introduce churn and risk to your deployment, as we regularly continue to see changes (both browser bugs and intentional restrictions) in those areas across multiple browsers that would break applications relying on this kind of functionality...

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Sep 07, 2018 Sep 07, 2018

Copy link to clipboard

Copied

LATEST

A local webserver is not a problem, as I can embed it into the app itself, and this is totally transparent for my users. I just wanted to know if it was possible to access the file directly, as reported in other threads, to remove this webserver component entirely. As I understand this is instead not possible (or too complicated), I'd say the local webserver is a perfectly acceptable way to go. Thanks for your help.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines