public
Description: Yet another role-based authorization system for Rails
Homepage:
Clone URL: git://github.com/be9/acl9.git
oleg dashevskii (author)
Fri Oct 09 22:39:57 -0700 2009
acl9 / TODO
100644 43 lines (31 sloc) 1.337 kb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
* Complex roles with ANDing.
 
  Something like:
 
    access_control do
      allow all, :except => :destroy
      allow complex_role, :to => :destroy do
        is :strong
        is :decisive
        is :owner, :of => :object
        is_not :banned
        is_not :fake
      end
    end
 
* Acl9-based menu generator.
 
  If you get Access Denied on /secrets/index, probably you shouldn't see "Secrets" item
  in the menu at all.
 
  It can be very DRY. Say, we introduce :menu => true option to access_control method which
  will make it register a lambda (can see/cannot see) in some global hash (indexed by controller name).
 
  Then, given an URL, you'll be able to check it against this hash. /secrets/index is mapped to
  SecretsController#index, so you run access_control_hash['SecretsController'].call('index') and
  show the link only if true is returned.
 
  The problem here is with objects. SecretsController's access_control block can reference instance
  variables during the permission check, but we have only current instantiated controller which can be any.
 
  Another option is to distinguish visible part from access control part.
 
    menu do
      item 'Home', home_path
      item 'Secrets', secrets_path do
        allow :trusted
      end
 
      # ...
    end
 
  Here only "trusted" users will see "Secrets" item.