Home

“Taking it down to attribute level” (dta) – a patchset for stffn’s declarative_authorization wiki

dta is a simple approach to apply decl auth rules to active record attributes. Furthermore, it provides helper methods for injecting (monkey patching) acl-checks into methods

• It provides methods for injecting ACL-Checks into the method chain
• If enabled, access to ActiveRecord attributes and association-proxies (new) is restricted.
• It allows querying of readable or writable attributes:

(See: Usage, further discussion)

Restrictions

• Dta does not protect any instance or class-method from being called. (methods are blacklists, not whitelisted. Changing it is trivial, but whitelisting all “non-evil” methods is not (imho).
• Dta does not intercept ActiveRecord-read operations to protected data. The patch works on attribute / model level and not on ActiveRecord / SQL level. This is useful if data is needed elsewhere (ie if_attribute statements), but DANGEROUS if ignored.
• primary keys are not protected by default (for obvious reasons)
• Dta generates methods like def no_acl_attributename(*args,&block) on the fly. Be aware of it.

Conventions:

• Dta specific permissons are prefixed :read_ or :write_ and suffixed with the attributes’s name. (e.g. :read_name implies read access to the name attribute)
• Dta is somewhat consistent with decl_auth’s in_model permissions: read (still) implies read access to all methods / attributes, while :write implies write access (decl_auth uses :create and :update) – see: http://www.tzi.org/~sbartsch/declarative_authorization/master/classes/Authorization/AuthorizationInModel.html

Hints:

• Building and checking attribute ACLs is expensive.
• Consider negative tests on every attribute / method you like to protect. The
  code is under (heavy) development.
• Use privileges for structuring large permission-sets