One of the interesting comments on our RailsConf Europe presentation on declarative_authorization was offered by Timo Hentschel. He stated that on the Rails CRM project with 90 Controllers and 200 Models that he is working on the declarative_authorization approach was simply not viable. Projects of this size are currently not the target of our plugin, though. Currently, we focus on bringing maintainable authorization into small to medium applications. Nevertheless, it is interesting to look into Timo’s points:
- “Role definition is for admins not developers”: It certainly depends on the project size. With small to medium apps (our primary target) admins might just be the developers. Still, our future plans include a possible move of the authorization rules to database, enabling a policy editing UI.
- “You’d need a UI for handling the policy development”: This might be true. But without further evaluation, I am not convinced of the superior performance of a UI when compared to a readable, concise policy syntax. Policy files still provide documentation and specification for free. We will look into UIs, especially to facilitate a test-driven policy development approach, though.
- “I can’t redeploy on every role modification”: In practice, engineering an application’s policy is certainly error prone. Missing permissions will have to be added to roles once taken into production. Changing roles on a production system isn’t optimal either, though: role-permission assignments need to be carefully checked for side effects. Thus, a QA workflow would be desirable, just as provided by a deployment cycle. I would prefer to handle missing permission assignments just like other software bugs which need to be fixed asap. Nevertheless, with the planned features (TDD, UI, policy in DB) and an integrated authorization workflow, online role modifications may be feasible. In our self-service authorization approach we would even like end users to extend their permissions on their own, on a limited scope and in some environments.
- “With 90 Controllers, the authorization policy will become unmanageably long”: This is certainly true with the current syntax. On the one hand, we will distribute rules to multiple files in order to group similar aspects. Also, currently one context is used per model. A hierarchy of contexts is planned to cut the number of specific rules and thus ease policy development and maintainability.