|
The AIR security model aims for a backwards compatibility
with legacy Ajax models while reducing the risk associated with
exposing system APIs to data beyond the developer’s control. In
the browser client-server model, the browser handles much of the
presentation and some dynamic third-party data loading. The server
handles most of the sensitive processing and provides OS-like facilities
such as storage, cryptography, and so on. By providing two sandboxes
that communicate via indirectly exposed functions, Adobe AIR makes
it less likely that attackers can access end-user machines and data.
Leveraging Ajax frameworks
Because a non-application sandbox is effectively the HTML
browser sandbox, Ajax developers should find porting of existing
applications and patterns to AIR relatively straightforward. For
example, you could take an existing crossword game from the web
and insert it entirely into a non-application sandbox frame.
While Ajax frameworks running in non-application sandboxes should
run just as they do in a web browser, some framework versions may
not completely work in the application sandbox if they rely on
eval()
and
cross-domain code loading. It largely depends on how much a given
framework depends on
eval()
and similar behaviors,
as well as which parts of the framework the developer uses.
These restrictions do not prevent using
eval()
with
JSON object literals. This allows your application content to work
with the JSON JavaScript library. However, application sandbox content
is restricted from using overloaded JSON code (with event handlers).
For other Ajax frameworks and JavaScript code libraries, check to
see if the code in the framework or library works within these restrictions
on dynamically generated code. If they do not, you will need to include
any content that uses the framework or library in a non-application security
sandbox.
Migrating applications
What if you want to take that simple crossword game and
implement functions like
saveGame()
and
loadGame()
?
Doing so requires accessing AIR APIs, and you implement the relevant
APIs in the application sandbox. Functions and data in the application
sandbox are then exposed to the non-application sandbox via a sandbox
bridge. At a high level, the process involves the following:
-
Rename the original root content file to
someName.htm
.
-
Create a file named
myRoot.htm
and include
an
IFRAME
or
FRAME
that points
to
someName.htm
.
-
Write functions that call the AIR APIs. It’s safer not to
call the APIs directly.
-
Create a
parentSandboxBridge
that exposes
the application sandbox functionality to the non-application sandbox.
Communication
between the two sandboxes can be two way:
parentSandboxBridge
and
childSandboxBridge
enables
traversing the bridge in both directions. This gives developers
more control over content flow between the application and the application
environment.
A real use case
Signet (a bookmark manager for del.icio.us users) is an
HTML-based AIR application that implements the AIR security model
in the following way:
-
First,
SignetRoot.htm
was created to
contain a frame with id
signetFrame
and three required
attributes that identify available domains.
-
In
SignetRoot.htm
,
onload
calls
the
SignetBridge.js
which contains all the exposed
functions.
-
In SignetBridge.js, the functions are exposed to
signetFrame
via
parentSandboxBridge
.
-
In
Signet.js
, the exposed functions make
direct AIR API calls. For example,
writeRscContentPriv
calls
writeRscContent
.
While
the methodology is relatively straightforward, the effect is powerful: remote
and local domains are defined for two sandboxes, the bridge is started during
onload, and the APIs are indirectly exercised through mediating functions
via the bridge API.
|
|
|
