Let's Get Dangerous: Security and Sandboxing in Chrome Packaged Apps

Chrome packaged application provides you with the ability to access many elevated privilege only features like file access, notifications and device access. These types of elevated privileges come at a cost but there are still ways to do what you need.

Dynamic Code

When a user installs your app, they agree to give your app the elevated privileges you request. In order for Google to make sure that your app doesn't accidently or intentionally load and run code other than what the user approved, some common JavaScript capabilities are disabled.

Eval and anything that converts a string into code can't be run in a Chrome packaged application. This includes setTimeout, setInterval and eval. Most developers are used to calling setTimeout by passing a string to be executed.

You can still call setTimeout, but you will need to pass a function to it instead of a string.

setTimeout(function() {
//Your Code
}, 1000);

Some developers are used to using eval to parse JSON from the days when this was the only way to convert a JSON structure into usable JavaScript objects. Instead of using eval, use JSON.parse(yourJsonString);.

Sandboxing

There are multiple popular frameworks that require eval to work successfully such as Kendo and Handlebars. Likewise, there are web API toolkits that rely on eval internally to work properly. In order to use these functions, you will need to put the parts of your app that need to use them in a sandbox.

To create a sandbox, modify your manifest.json file to include a "sandbox" property and under the sandbox property, create a "pages" property. The pages property takes an array of page names that you want to be sandboxed.

The container HTML file is outside of the sandbox and is both restricted by the typical Chrome Packaged App restrictions and has the elevated permissions you requested in your manifest.json. In this example, the "container.html" file just contains an IFRAME that points to the "index.html" page that is in the sandbox.

The sandboxed "index.html" page example below can not only run "loose" script in the page but can also run eval. It isn't a complete "anything goes" environment, you still cannot use "alert" but for all intents and purposes you should be able to use any UI framework or templating library you like inside of the sandbox.

Passing Messages

For most applications, you will find it easier to keep your entire UI tier inside of a sandbox page. You can use the W3C standard message API to pass messages back and forth between your sandboxed iframe and your more secure main page.

For example, if you put the script below in a script that runs on your main window, it will register a listener for "message" events. You can use these message events to receive messages from your sandboxed iframe. In this simple example, it is just passing text to output.

In your sandboxed page inside of the iframe, you can post a message to the non-sandboxed page by calling window.top.postMessage() API. You can pass any serializable data structure using the postMessage api; in this example it is just passing an object with a single "MessageText" property.

Model-View-Controller

The security constraints put on a chrome packaged application may seem daunting at first but once you understand how sandboxing works you'll be up and running in no time. As an added benefit of the sandboxing, it can force a cleaner separation between your UI code and your application code. The Model-View-Controller pattern is perfect in this regard.

Your sandboxed page can be responsible for displaying the user interface and routing user interaction into commands. You can then fire your commands via postMessage to your non-sandboxed app to actually interact with the data and carry out commands.

Although this is a good approach in general, as with most things in programming models there are some fuzzy areas. The Google API works by dynamically incrementally loading additional script files, which is something that can only be done inside of the sandbox. Because of this restriction, this would be an example of a scenario where using the sandbox as your "View" doesn't necessarily keep a clean separation between your View and Controller.

About the Author:

David Talbot has over 14 years of experience in the software industry and specializes in building rich UI web applications. He is also the author of Applied ADO.NET and numerous articles on technology. He can be reached at david@legendarycode.com

IT Solutions Builder
TOP IT RESOURCES TO MOVE YOUR BUSINESS FORWARD

Which topic are you interested in?

Mobile

Security

Networks/IoT

Cloud

Data Storage

Applications

Development

IT Management

Other

What is your company size?

What is your job title?

What is your job function?

Searching our resource database to find your matches...

Please enable Javascript in your browser, before you post the comment! Now Javascript is disabled.

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.