I'm developing kind of standalone kiosk and having trouble as in title.
Explanation:
Application is launched in Google Chrome with "--app=file://..." option
Application should play video files from local filesystem after user
interaction and after playback is finished app will send log-message
to web server.
Problem:
When using with "-use-network=false" i can use local files and cannot
send messages.
When using with "-use-network=true" i can send messages but cannot
red local files.
When using with debugger and Safari on Mac locally - no problems.
Is there any way to get around this?
Software used: Debian, latest Google Chrome with latest pepper Flash.
As written in Adobe docs:
The local-trusted sandbox—Local SWF files that are registered as
trusted (by users or by installer programs) are placed in the
local-trusted sandbox. System administrators and users also have the
ability to reassign (move) a local SWF file to or from the
local-trusted sandbox based on security considerations (see
Administrator controls and User controls). SWF files that are assigned
to the local-trusted sandbox can interact with any other SWF files and
can load data from anywhere (remote or local).
Besides that, I doubt there is an easy way to do both networking and access local files since this is how Flash security sandboxes work. Or you could write an AIR app (2.6 is last supported version on Linux) or wrap your swf in a native app that would act as a layer between .swf and network/filesystem interfaces.
Related
I'm building a packaged app that's meant to interact with a website I wrote to get its localStorage data and send it to other devices using bluetooth. This seems like it would be easy with an extension, however with an extension I would not have access to chrome's bluetooth API. I'm not sure this is even possible, but if it is, how would I go about accessing and communicating with the website using the packaged app?
The answer is that you can't. The two local storage repositories are distinct ("sandboxed"), and one can't access the other.
If this website wants to make data available to any other website, or to a Chrome App, it should put it someplace on the server, accessible via a URL, and then the Chrome App can easily access it. But, there's no way to effect such sharing with the data on the client.
Two Chrome Apps can share data locally, because they can access the local file system. However, web apps (HTML/JavaScript loaded from a server) can't access the local file system, only a sandboxed file system.
I am developing a chrome extension which needs to fetch some configuration from a system file... Earlier chrome provided NPAPI plug-ins, which could access any system resource (win registry, file system, IPC calls etc...)
However knowing that NPAPI will be discontinued soon, i am looking for alternatives.. one of the ways to build a plug-in is using Pepper clients, but pepper clients read/write only to chrome local storage.. which looks like a more data version of cookies...
So is there any other alternative to access system resources (like registry, files etc) in chrome extensions now??
The suggested alternative to NPAPI for many cases is "Native Messaging", where you provide an installer to users which adds binary code that chrome can communicate with via message passing. See http://developer.chrome.com/extensions/messaging.html#native-messaging.
For file access, in packaged apps there is the fileSystem API that lets you get access to the actual (non-sandboxed) filesystem. See http://developer.chrome.com/apps/fileSystem.html.
In my packaged app I would like to open pdf's stored in local filesystem. I've managed to open them if I select them using chrome.fileSystem.chooseEntry, but I can't find a way to do the same if the filesnames are hard coded.
The idea behind is an app that manages book information and allows to open them if they are stored in the local filesystem. Thanks a lot!
This can't be done, for good reason. Packaged apps have a security model based on the open web. Web pages can't access your local files without your permission (i.e., without a "user gesture" or a specific user action such as going through a file chooser), and packaged apps have the same restriction.
You could import local files (again using a user gesture) into the HTML5 file system, or into chrome.syncFileSystem. Then you'd have gestureless access to the imported copies. Likewise, you could export from either of those file systems to the local file system, again with a user gesture. But the boundary between local files and your app's access to them is meant to be loud and explicit.
I'm trying to load a local video to display it and I'm having this error ( Error #2148) at runtime, I have read in many places what this problem is, about flash security and all that stuff but there's no solution anywhere and some people say that it can't be done.
My swf works fine when loading from internet, I have my cross-domain on my server but is completely necessary for me to create a standalone version which can run without internet connection and load the videos from file system.
May be with different compiling options? I'm using Flash Builder 4.6
Any idea how could I achive a local resource loading?
P.D. I know that the trusted folder can resolve the problem but that implies a configuration change in every computer it runs and I need it to be portable like in a USB to run on any computer that has Flash Player.
I'm writing a Google Chrome app that stores things locally with the HTML5 FileSystem API. Is there any way to use Windows Explorer to get to the directory where Chrome stores these files or is it entirely virtual and inaccessible from outside the app? I haven't been able to find the directory by poking around nor have I seen any reference online to it.
I suppose I could just write something within the app to allow me GUI management of the files my app stores or just use the developer console, but it would really be a time saver to use WE.
Nevermind, I just found it. For anyone looking, it's in (on my windows 7 machine at least)
C:\Users\ user \AppData\Local\Google\Chrome\User Data\Default\File System
Also note that this was in Chrome 11, in Chrome 13 there were some changes to the FileSystem (probably for security) that make it very difficult to find specific files by scrolling through the files in Chrome's AppData space.