You are here

Introducing Entity JS

I recently added a new module to called Entity JS - this module is a javascript abstraction of the popular Entity API.

Here's some ideas for things one could build using Entity JS.

So yeah... pretty much anything you were able to do using entities before can now be handled asynchronously via JS in Drupal.

So how does Entity JS work?

As stated earlier, Entity JS is an abstraction of the Entity API. Some of the functions are nearly a direct 1:1 abstraction such as entity_create and entity_delete. Other functions act more like helpers to provide a set of actions. For example, entity_render_view loads an entity and then invokes entity_view to return the entity as HTML that can be inserted into the DOM. The aforementioned function even takes a 'view mode' argument, to allow for any field display configuration the JS programmer needs. Call and respond a node with a 'Full node' or a 'Teaser' or any custom Entity View Mode that the system allows, and so on.

One of the biggest problems developers face in Drupal is dealing with integrations. Often I've found others struggling to put together simple Drupal/Javascript Library mashups because they must rely on a module like Views or EFQ to retrieve data. Programmers that need to interface Drupal with their Javascript Libraries should have a much easier time working with Drupal using this module. One will be able to write modules written 100% in javascript which is fun, cool and scary all at the same time.

Security and Access Permissions for Entity JS are unique.

Okay so I'm imaging anyone reading this that consideres themselves a "security guy" is probably chomping at the bit. "EFQ in Javascript? This is a major security breach!"

My retort here is "YES!" - I completely agree. This is why the permissions on this module are not set for any users roles on install. Site admins must opt-in these roles to give access to actions using specific entity types. One note: Right now we do not have any check for per-bundle entity access.

Entity JS is definitely an alternate layer that can easily be used to attack a Drupal site if the permissions were turned on fully. Don't do it! You especially don't want to allow CRUD access to 'user' entities on your site to anonymous users. This should be obvious but I have to feel I have to say this here.

There are definitely safe ways to use the module. For example - if you only want users to view content, configuring Entity JS permissions to allow anonymous users to 'read node entities' is fine. But keep in mind, if you have nodes that you don't want people to see, a savvy person could potentially expose Entity JS to call nodes into their browser console or what-have-you.

Why isn't Entity JS access handled by existing permissions?

There is also the idea that one could use the existing access hooks for users to determine what entities can be dealt with for that role. The problem here is that users may need access at different levels when the browser is enacting commands on their behalf, such as it would often be in Entity JS. It shouldn't be implied that just because Entity JS might be configured to allow authenticated users to create taxonomy terms that these same users should be allowed to visit /admin/structure/taxonomy/tags/add from within the Drupal site.

While large portion of users will not read your JS code, especially if it is compressed, this doesn't provide full security because the JS behaviors are still available to anyone willing to try using them.

Setting permissions correctly for Entity JS is very, very, very important. If anyone would like to donate time to do a security audit on this module, I would be very grateful.

Submitted by brant on Sat, 07/21/2012 - 17:15