Skip to main content
Luca_Carlon
Luca_Carlon
Participant
August 30, 2018
Answered

Using ExternalInterface to contact JS when using the file schema

  • August 30, 2018
  • 2 replies
  • 597 views

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!

This topic has been closed for replies.
Correct answer jeromiec83223024

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.

2 replies

jeromiec83223024
jeromiec83223024
Inspiring
September 6, 2018

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...

Luca_Carlon
Luca_CarlonAuthor
Participant
September 7, 2018

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.

jeromiec83223024
jeromiec83223024Correct answer
Inspiring
September 4, 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 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.

Luca_Carlon
Luca_CarlonAuthor
Participant
September 5, 2018

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!

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices