From 23f398329ea62a33a8ee3fa95d873c6de37ff8c6 Mon Sep 17 00:00:00 2001 From: Steffen Bartsch Date: Tue, 17 Nov 2009 17:55:58 +0100 Subject: [PATCH] Added link to Ryan's screencast and straightened README intro --- README.rdoc | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/README.rdoc b/README.rdoc index b3bc802b..c181b2b9 100644 --- a/README.rdoc +++ b/README.rdoc @@ -1,23 +1,18 @@ = Declarative Authorization The declarative authorization plugin offers an authorization mechanism inspired -by _RBAC_. The most notable distinction to existing authorization plugins is the -declarative authorization approach. That is, authorization rules are not +by _RBAC_. The most notable distinction to other authorization plugins is the +declarative approach. That is, authorization rules are not defined programmatically in between business logic but in an authorization configuration. -Currently, Rails authorization plugins only provide for programmatic -authorization rules. That is, the developer needs to specify which roles are +With programmatic authorization rules, the developer needs to specify which roles are allowed to access a specific controller action or a part of a view, which is -not DRY. With a growing application code base and functions, as it happens -especially in agile development processes, it may be decided to introduce new -roles. Then, at several places of the source code the new group needs to be -added, possibly leading to omissions and thus hard to test errors. Another -aspect are changing authorization requirements in development or -even after taking the application into production. Then, privileges of -certain roles need to be easily adjusted when the original assumptions -concerning access control prove unrealistic. In these situations, a -declarative approach as offered by this plugin increases the development -and maintenance efficiency. +not DRY. With a growing application code base roles' permissions often +change and new roles are introduced. Then, at several places of the source code +the changes have to be implemented, possibly leading to omissions and thus hard +to find errors. In these cases, a declarative approach as offered by decl_auth +increases the development and maintenance efficiency. + Plugin features * Authorization at controller action level @@ -37,6 +32,10 @@ Requirements See below for installation instructions. +There is a decl_auth screencast by Ryan Bates, nicely introducing the main concepts: +http://railscasts.com/episodes/188-declarative-authorization + + = Authorization Data Model ----- App domain ----|-------- Authorization conf ---------|------- App domain ------ @@ -75,7 +74,7 @@ A fully functional example application can be found at http://github.com/stffn/decl_auth_demo_app Details on the demonstrated methods can be found in the API docs, either -generated yourself or at http://www.tzi.org/~sbartsch/declarative_authorization +generated by yourself or at http://www.tzi.org/~sbartsch/declarative_authorization == Controller @@ -219,7 +218,7 @@ As access control on read are costly, with possibly lots of objects being loaded at a time in one query, checks on read need to be actived explicitly by adding the :include_read option. -=== Query rewriting using named scopes +=== Query rewriting through named scopes When retrieving large sets of records from databases, any authorization needs to be integrated into the query in order to prevent inefficient filtering afterwards and to use LIMIT and OFFSET in SQL statements. To keep authorization @@ -451,7 +450,7 @@ All bang methods throw exceptions which may be used to retrieve more information about a denied access than a Boolean value. -== Authorization Browser +== Authorization Development Support If your authorization rules become more complex, you might be glad to use the authorization rules browser that comes with declarative_authorization.