Launch a local file with default file handler from chrome packaged app (or extension)

Question

I'm building a launcher for internal use with a Chrome packaged app which includes links to internal resources (databases, web links, etc.).

The problem is with local files. I want them to launch using whatever program is the default handler for them. For example, access databases open in Access, etc.

I've tried:

1. Creating a file link file:///. Nothing happens in this scenario on click and the link is not followed.

2. I found an extension (locallinks) here: https://code.google.com/p/locallinks/, which will open local file links. I've tried borrowing from that extension and passing the file link to the background script in my packaged app which would then open a new window with that url. Unfortunately, that results in a file not found, even for simple types such as text files. So obviously the local filesystem is sandboxed. Not surprising.

3. I thought maybe it would work to pass the link to an extension to open, but in that case, the file would be opened in Chrome and if Chrome does not support it, it would attempt to download the file locally.

The reason I'm using Chrome Packaged Apps is: 1. This will be updated often and the Chrome Web Store update feature would make it easy to keep clients updated without having to build our own update mechanism. 2. We can restrict installation of the app through CWS to internal users. 3. The app would be used in a Windows, Linux and Mac environment. Obviously the file paths here would be different but since they would point to a samba share, and mount points and network share drive's are known this is an easy problem to overcome. 4. There is additional functionality we will be building into the Chrome app in the future other than the launcher which fits very well with how Chrome Apps are designed.

My thoughts are:

1. Native Client? I have read a bit about these, but I think I would end up with the same limitations where the native client app would be sandboxed and may not actually have any better way of launching a local file.

2. Sockets? Maybe a simple Qt app listening on a socket to launch apps? Since the Qt app would be run with user permissions, and the socket would only accept connections from localhost, I guess the socket could in theory be used by a non-privileged app to launch something with user-level permissions. Is there a way for me to limit connections through the socket to only be accessible from my extension?

The sockets solution isn't ideal but may work since the app would not be updated often (if ever) since functionality is so simple.

Am I missing an obvious way of doing this that wouldn't require another component (a Qt app?)

Answer 1

Relating to your thought #2, not sure what local installation footprint you are willing to tolerate, but you may consider:

Hosting a miniscule local web server, or Qt app as you mention, which can also launch local programs (any of those lightweight web server frameworks). Have your packaged app, or your own chrome extension rewrite links such that they point at your web server along with the url of the original link, which can easily launch whatever program. Downsides: this may cause bypassing some browser security screening of the original links in some forms of implementation.

You may also look at this stackoverflow question if it helps.

You can limit access by confirming the requests originate from the local machine, or by embedding a key or hash inside your chrome extension. You may generate the key upon installation so that it's unique per machine. None of this will pass very proper security scrutiny so it depends on your risk profile. You will have a hard time justifying how each part is secure and clean of exploitation attack potential.

It seems you will need both a chrome extension and a local miniscule web server to make this work. Maybe it's easier to let users just download the files and click them...

Sorry if this isn't help enough, but basically you are trying to do something that is by design not made possible in Chrome, so at this state of affairs there would likely not be a simple solution.