1NAME
2 Catalyst::Plugin::Authorization::ACL - ACL support for Catalyst
3 applications.
4
5SYNOPSIS
6 use Catalyst qw/
7 Authentication
8 Authorization::Roles
9 Authorization::ACL
10 /;
11
12 __PACKAGE__->setup;
13
14 __PACKAGE__->deny_access_unless(
15 "/foo/bar",
16 [qw/nice_role/],
17 );
18
19 __PACKAGE__->allow_access_if(
20 "/foo/bar/gorch",
21 sub { return $boolean },
22 );
23
24DESCRIPTION
25 This module provides Access Control List style path protection, with
26 arbitrary rules for Catalyst applications. It operates only on the
27 Catalyst private namespace, at least at the moment.
28
29 The two hierarchies of actions and controllers in Catalyst are:
30
31 Private Namespace
32 Every action has its own private path. This path reflects the Perl
33 namespaces the actions were born in, and the namespaces of their
34 controllers.
35
36 External Namespace
37 Some actions are also directly accessible from the outside, via a
38 URL.
39
40 The private and external paths will be the same, if you are using
41 Local actions. Alternatively you can use "Path", "Regex", or
42 "Global" to specify a different external path for your action.
43
44 The ACL module currently only knows to exploit the private namespace. In
45 the future extensions may be made to support external namespaces as
46 well.
47
48 Various types of rules are supported, see the list under "RULES".
49
50 When a path is visited, rules are tested one after the other, with the
51 most exact rule fitting the path first, and continuing up the path.
52 Testing continues until a rule explcitly allows or denies access.
53
54METHODS
55 allow_access_if
56 Arguments: $path, $rule
57
58 Check the rule condition and allow access to the actions under $path if
59 the rule returns true.
60
61 This is normally useful to allow acces only to a specific part of a tree
62 whose parent has a "deny_access_unless" clause attached to it.
63
64 If the rule test returns false access is not denied or allowed. Instead
65 the next rule in the chain will be checked - in this sense the
66 combinatory behavior of these rules is like logical OR.
67
68 allow_access_if_any
69 Arguments: $path, \@roles
70
71 Same as above for any role in the list.
72
73 deny_access_unless
74 Arguments: $path, $rule
75
76 Check the rule condition and disallow access if the rule returns false.
77
78 This is normally useful to restrict access to any portion of the
79 application unless a certain condition can be met.
80
81 If the rule test returns true access is not allowed or denied. Instead
82 the next rule in the chain will be checked - in this sense the
83 combinatory behavior of these rules is like logical AND.
84
85 deny_access_unless_any
86 Arguments: $path, \@roles
87
88 Same as above for any role in the list.
89
90 allow_access
91 deny_access
92 Arguments: $path
93
94 Unconditionally allow or deny access to a path.
95
96 acl_add_rule
97 Arguments: $path, $rule, [ $filter ]
98
99 Manually add a rule to all the actions under $path using the more
100 flexible (but more verbose) method:
101
102 __PACKAGE__->acl_add_rule(
103 "/foo",
104 sub { ... }, # see FLEXIBLE RULES below
105 sub {
106 my $action = shift;
107 # return a true value if you want to apply the rule to this action
108 # called for all the actions under "/foo"
109 }
110 };
111
112 In this case the rule must be a sub reference (or method name) to be
113 invoked on $c.
114
115 The default filter will skip all actions starting with an underscore,
116 namely "_DISPATCH", "_AUTO", etc (but not "auto", "begin", et al).
117
118 acl_access_denied
119 Arguments: $c, $class, $action, $err
120
121 acl_access_allowed
122 Arguments: $c, $class, $action
123
124 The default event handlers for access denied or allowed conditions. See
125 below on handling access violations.
126
127 acl_allow_root_internals
128 Adds rules that permit access to the root controller (YourApp.pm)
129 "auto", "begin" and "end" unconditionally.
130
131EXTENDED METHODS
132 execute
133 The hook for rule evaluation
134
135 setup_actions
136RULE EVALUATION
137 When a rule is attached to an action the "distance" from the path it was
138 specified in is recorded. The closer the path is to the rule, the
139 earlier it will be checked.
140
141 Any rule can either explicitly deny or explicitly allow access to a
142 particular action. If a rule does not explicitly allow or permit access,
143 the next rule is checked, until the list of rules is finished. If no
144 rule has determined a policy, access to the path will be permitted.
145
146PATHS
147 To apply a rule to an action or group of actions you must supply a path.
148
149 This path is what you should see dumped at the beginning of the Catalyst
150 server's debug output.
151
152 For example, for the "foo" action defined at the root level of your
153 application, specify "/foo". Under the "Moose" controller (e.g.
154 "MyApp::C::Moose", the action "bar" will be "/moose/bar").
155
156 The "distance" a path has from an action that is contained in it is the
157 the difference in the number of slashes between the path of the action,
158 and the path to which the rule was applied.
159
160RULES
161 Easy Rules
162 There are several kinds of rules you can create without using the
163 complex interface described in "FLEXIBLE RULES".
164
165 The easy rules are all predicate list oriented. "allow_access_if" will
166 explicitly allow access if the predicate is true, and
167 "deny_access_unless" will explicitly disallow if the predicate is false.
168
169 Role Lists
170 __PACAKGE__->deny_access_unless_any( "/foo/bar", [qw/admin moose_trainer/] );
171
172 When the role is evaluated the
173 Catalyst::Plugin::Authorization::Roles will be used to check whether
174 the currently logged in user has the specified roles.
175
176 If "allow_access_if_any" is used, the presence of any of the roles
177 in the list will immediately permit access, and if
178 "deny_access_unless_any" is used, the lack of all of the roles will
179 immediately deny access.
180
181 Similarly, if "allow_access_if" is used, the presence of all the
182 roles will immediately permit access, and if "deny_access_unless" is
183 used, the lack of any of the roles will immediately deny access.
184
185 When specifying a role list without the
186 Catalyst::Plugin::Authorization::Roles plugin loaded the ACL engine
187 will throw an error.
188
189 Predicate Code Reference / Method Name
190 The code reference or method is invoked with the context and the
191 action objects. The boolean return value will determine the behavior
192 of the rule.
193
194 __PACKAGE__->allow_access_if( "/gorch", sub { ... } );
195 __PACKAGE__->deny_access_unless( "/moose", "method_name" );
196
197 When specifying a method name the rule engine ensures that it can be
198 invoked using "can" in UNIVERSAL.
199
200 Constant
201 You can use "undef", 0 and '' to use as a constant false predicate,
202 or 1 to use as a constant true predicate.
203
204 Flexible Rules
205 These rules are the most annoying to write but provide the most
206 flexibility.
207
208 All access control is performed using exceptions -
209 $Catalyst::Plugin::Authorization::ACL::Engine::DENIED, and
210 $Catalyst::Plugin::Authorization::ACL::Engine::ALLOWED (these can be
211 imported from the engine module).
212
213 If no rule decides to explicitly allow or deny access, access will be
214 permitted.
215
216 Here is a rule that will always break out of rule processing by either
217 explicitly allowing or denying access based on how much mojo the current
218 user has:
219
220 __PACKAGE__->acl_add_rule(
221 "/foo",
222 sub {
223 my ( $c, $action ) = @_;
224
225 if ( $c->user->mojo > 50 ) {
226 die $ALLOWED;
227 } else {
228 die $DENIED;
229 }
230 }
231 );
232
233HANDLING DENIAL
234 There are two plugin methods that can be called when a rule makes a
235 decision about an action:
236
237 acl_access_allowed
238 A no-op
239
240 acl_access_denied
241 Looks for a private action named "access_denied" from the denied
242 action's controller and outwards (much like "auto"), and if none is
243 found throws an access denied exception.
244
245 forcibly_allow_access
246 Within an "access_denied" action this will immediately cause the
247 blocked action to be executed anyway.
248
249 This means that you have several alternatives:
250
251 Provide an "access_denied" action
252 package MyApp::Controller::Foo;
253
254 sub access_denied : Private {
255 my ( $self, $c, $action ) = @_;
256
257 ...
258 $c->forcibly_allow_access
259 if $you->mean_it eq "really";
260 }
261
262 If you call "forcibly_allow_access" then the blocked action will be
263 immediately unblocked. Otherwise the execution of the action will cease,
264 and return to it's caller or end.
265
266 Cleanup in "end"
267 sub end : Private {
268 my ( $self, $c ) = @_;
269
270 if ( $c->error and $c->error->[-1] eq "access denied" ) {
271 $c->error(0); # clear the error
272
273 # access denied
274 } else {
275 # normal end
276 }
277 }
278
279 Override the plugin event handler methods
280 package MyApp;
281
282 sub acl_access_allowed {
283 my ( $c, $class, $action ) = @_;
284 ...
285 }
286
287 sub acl_access_denied {
288 my ( $c, $class, $action, $err ) = @_;
289 ...
290 }
291
292 $class is the controller class the $action object was going to be
293 executed in, and $err is the exception cought during rule evaluation, if
294 any (access is denied if a rule raises an exception).
295
296SEE ALSO
297 Catalyst::Plugin::Authentication,
298 Catalyst::Plugin::Authorization::Roles,
299 <http://catalyst.perl.org/calendar/2005/24>
300
301AUTHOR
302 Yuval Kogman <nothingmuch@woobling.org>
303
304CONTRIBUTORS
305 castaway: Jess Robinson
306
307 caelum: Rafael Kitover <rkitover@cpan.org>
308
309COPYRIGHT & LICENSE
310 Copyright (c) 2005 - 2009 the Catalyst::Plugin::Authorization::ACL
311 "AUTHOR" and "CONTRIBUTORS" as listed above.
312
313 This library is free software; you can redistribute it and/or modify it
314 under the same terms as Perl itself.
315
316