stffn-declarative_authorization 0.2.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
data/CHANGELOG ADDED
@@ -0,0 +1,49 @@
1
+ * Added a authorization rules browser. See README for more information [sb]
2
+
3
+ * Added Model.using_access_control? to check if a model has model security activated [sb]
4
+
5
+ * Changed Authorization::ObligationScope#map_table_alias_for [Brian Langenfeld]
6
+ * Fixed to prevent bad aliases from being produced.
7
+
8
+ * Changed Authorization::Attribute#validate? [Brian Langenfeld]
9
+ * Encountering a nil value when evaluating an attribute now raises a NilAttributeValueError, instead of an AuthorizationError. We leave it to the caller to decide what to do about it.
10
+
11
+ * Changed Authorization::Engine#permit! [Brian Langenfeld]
12
+ * We now convert incoming privileges to symbols (e.g. 'read' is made equivalent to :read). This ensures the privileges will match those defined in the authorization rules file.
13
+ * The method now properly infers context when checking against an association (e.g. user.posts). We do this by leveraging ActiveRecord builder method 'new' to instantiate a proper object we can work with.
14
+ * When testing rules for positive results (via Authorization::Attribute#validate?), we now rescue NilAttributeValueError exceptions, simply causing the rule to return a negative result (instead of barfing).
15
+
16
+ * Changed Authorization::ObligationScope#rebuild_join_options! [Brian Langenfeld]
17
+ * If we're dealing with multiple obligations we have to check (i.e. ones that result in OR'd conditions), we now use :include instead of :joins for our generated scope. This does seem like a kludge, but until ActiveRecord scopes support unions (for checking obligations individually and consolidating the results), we don't have much choice. Something to revisit later, for sure.
18
+
19
+ ** RELEASE 0.2 (February 2, 2009) **
20
+
21
+ * added negative operators: is_not, not_in, does_not_contain [sb]
22
+
23
+ * changed user.roles to user.role_symbols to reduce interferance with associations [sb]
24
+
25
+ * Ruby 1.9 and Rails 2.3 compatibility [sb]
26
+
27
+ * if_permitted_to for has_permission_on blocks for DRYer auth rules [sb]
28
+
29
+ * ObligationScope rewrite of query rewriting [Brian Langenfeld]
30
+
31
+ * changed exception hierarchy to begin at StandardError [sb]
32
+
33
+ * :is_in operator [sb]
34
+
35
+ * added has_role? helper [sb]
36
+
37
+ * made plugin thread-safe [sb]
38
+
39
+ * added maintenance and test helpers [sb]
40
+
41
+ * changed default permission denied response to 403 Forbidden [sb]
42
+
43
+ * descriptions for titles and roles [sb]
44
+
45
+ * fixed for PostgreSQL [Mark Mansour]
46
+
47
+ * improved DSL syntax: allow for array of contexts in has_permission_on [sb]
48
+
49
+ ** RELEASE 0.1 (August 22, 2008) **
data/MIT-LICENSE ADDED
@@ -0,0 +1,20 @@
1
+ Copyright (c) 2008 [name of plugin creator]
2
+
3
+ Permission is hereby granted, free of charge, to any person obtaining
4
+ a copy of this software and associated documentation files (the
5
+ "Software"), to deal in the Software without restriction, including
6
+ without limitation the rights to use, copy, modify, merge, publish,
7
+ distribute, sublicense, and/or sell copies of the Software, and to
8
+ permit persons to whom the Software is furnished to do so, subject to
9
+ the following conditions:
10
+
11
+ The above copyright notice and this permission notice shall be
12
+ included in all copies or substantial portions of the Software.
13
+
14
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
15
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
16
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
17
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
18
+ LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
19
+ OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
20
+ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
data/README.rdoc ADDED
@@ -0,0 +1,479 @@
1
+ = Declarative Authorization
2
+
3
+ The declarative authorization plugin offers an authorization mechanism inspired
4
+ by _RBAC_. The most notable distinction to existing authorization plugins is the
5
+ declarative authorization approach. That is, authorization rules are not
6
+ programmatically in between business logic but in an authorization configuration.
7
+
8
+ Currently, Rails authorization plugins only provide for programmatic
9
+ authorization rules. That is, the developer needs to specify which roles are
10
+ allowed to access a specific controller action or a part of a view, which is
11
+ not DRY. With a growing application code base and functions, as it happens
12
+ especially in agile development processes, it may be decided to introduce new
13
+ roles. Then, at several places of the source code the new group needs to be
14
+ added, possibly leading to omissions and thus hard to test errors. Another
15
+ aspect are changing authorization requirements in development or
16
+ even after taking the application into production. Then, privileges of
17
+ certain roles need to be easily adjusted when the original assumptions
18
+ concerning access control prove unrealistic. In these situations, a
19
+ declarative approach as offered by this plugin increases the development
20
+ and maintenance efficiency.
21
+
22
+ Plugin features
23
+ * Authorization at controller action level
24
+ * Authorization helpers for Views
25
+ * Authorization at model level
26
+ * Authorize CRUD (Create, Read, Update, Delete) activities
27
+ * Query rewriting to automatically only fetch authorized records
28
+ * DSL for specifying Authorization rules in an authorization configuration
29
+
30
+
31
+ Requirements
32
+ * An authentication mechanism
33
+ * User object in Controller#current_user
34
+ * User object needs to respond to a method :role_symbols that returns an
35
+ array of role symbols
36
+ See below for installation instructions.
37
+
38
+
39
+ = Authorization Data Model
40
+
41
+ ----- App domain ----|-------- Authorization conf ---------|------- App domain ------
42
+
43
+ includes includes
44
+ .--. .---.
45
+ | v | v
46
+ .------. can_play .------. has_permission .------------. requires .----------.
47
+ | User |----------->| Role |----------------->| Permission |<-----------| Activity |
48
+ '------' * * '------' * * '------------' 1 * '----------'
49
+ |
50
+ .-------+------.
51
+ 1 / | 1 \ *
52
+ .-----------. .---------. .-----------.
53
+ | Privilege | | Context | | Attribute |
54
+ '-----------' '---------' '-----------'
55
+
56
+ In the application domain, each *User* may be assigned to *Roles* that should
57
+ define the users' job in the application, such as _Administrator_. On the
58
+ right-hand side of this diagram, application developers specify which *Permissions*
59
+ are necessary for users to perform activities, such as calling a controller action,
60
+ viewing parts of a View or acting on records in the database. Note that
61
+ Permissions consist of an *Privilege* that is to be performed, such as _read_,
62
+ and a *Context* in that the Operation takes place, such as _companies_.
63
+
64
+ In the authorization configuration, Permissions are assigned to Roles and Role
65
+ and Permission hierarchies are defined. *Attributes* may be employed to allow
66
+ authorization according to dynamic information about the context and the
67
+ current user, e.g. "only allow access on employees that belong to the
68
+ current user's branch."
69
+
70
+
71
+ = Examples
72
+
73
+ A fully functional example application can be found at
74
+ http://github.com/stffn/decl_auth_demo_app
75
+
76
+ Details on the demonstrated methods can be found in the API docs, either
77
+ generated yourself or at http://www.tzi.org/~sbartsch/declarative_authorization
78
+
79
+ == Controller
80
+
81
+ If authentication is in place, enabling user-specific access control may be
82
+ as simple as one call to filter_access_to :all which simply requires the
83
+ according privileges for present actions. E.g. the privilege index_users is
84
+ required for action index. This works as a first default configuration
85
+ for RESTful controllers, with these privileges easily handled in the
86
+ authorization configuration, which will be described below.
87
+
88
+ class EmployeesController < ApplicationController
89
+ filter_access_to :all
90
+ def index
91
+ ...
92
+ end
93
+ ...
94
+ end
95
+
96
+ When custom actions are added to such a controller, it helps to define more
97
+ clearly which privileges are the respective requirements. That is when the
98
+ filter_access_to call may become more verbose:
99
+
100
+ class EmployeesController < ApplicationController
101
+ filter_access_to :all
102
+ # this one would be included in :all, but :read seems to be
103
+ # a more suitable privilege than :auto_complete_for_user_name
104
+ filter_access_to :auto_complete_for_employee_name, :require => :read
105
+ def auto_complete_for_employee_name
106
+ ...
107
+ end
108
+ ...
109
+ end
110
+
111
+ For some actions it might be necessary to check certain attributes of the
112
+ object the action is to be acting on. Then, the object needs to be loaded
113
+ before the action's access control is evaluated. On the other hand, some actions
114
+ might prefer the authorization to ignore specific attribute checks as the object is
115
+ unknown at checking time, so attribute checks and thus automatic loading of
116
+ objects needs to be enabled explicitly.
117
+
118
+ class EmployeesController < ApplicationController
119
+ filter_access_to :update, :attribute_check => true
120
+ def update
121
+ # @employee is already loaded from param[:id] because of :attribute_check
122
+ end
123
+ end
124
+
125
+ You can provide the needed object through before_filters. This way, you have
126
+ full control over the object that the conditions are checked against. Just make
127
+ sure, your before_filters occur before any of the filter_access_to calls.
128
+
129
+ class EmployeesController < ApplicationController
130
+ before_filter :new_employee_from_params, :only => :create
131
+ before_filter :new_employee, :only => [:index, :new]
132
+ filter_access_to :all, :attribute_check => true
133
+
134
+ def create
135
+ @employee.save!
136
+ end
137
+
138
+ protected
139
+ def new_employee_from_params
140
+ @employee = Employee.new(params[:employee])
141
+ end
142
+ end
143
+
144
+ If the access is denied, a +permission_denied+ method is called on the
145
+ current_controller, if defined, and the issue is logged.
146
+ For further customization of the filters and object loading, have a look at
147
+ the complete API documentation of filter_access_to in
148
+ Authorization::AuthorizationInController::ClassMethods.
149
+
150
+
151
+ == Views
152
+
153
+ In views, a simple permitted_to? helper makes showing blocks according to the
154
+ current user's privileges easy:
155
+
156
+ <% permitted_to? :create, :employees do %>
157
+ <%= link_to 'New', new_employee_path %>
158
+ <% end %>
159
+
160
+ Only giving a symbol :employees as context prevents any checks of attributes
161
+ as there is no object to check against. For example, in case of nested resources
162
+ a new object may come in handy:
163
+
164
+ <% permitted_to? :create, Branch.new(:company => @company) do
165
+ # or @company.branches.new
166
+ # or even @company.branches %>
167
+ <%= link_to 'New', new_company_branch_path(@company) %>
168
+ <% end %>
169
+
170
+ Lists are straight-forward:
171
+
172
+ <% for employee in @employees %>
173
+ <%= link_to 'Edit', edit_employee_path(employee) if permitted_to? :update, employee %>
174
+ <% end %>
175
+
176
+ See also Authorization::AuthorizationHelper.
177
+
178
+
179
+ == Models
180
+
181
+ There are two destinct features for model security built into this plugin:
182
+ authorizing CRUD operations on objects as well as query rewriting to limit
183
+ results according to certain privileges.
184
+
185
+ See also Authorization::AuthorizationInModel.
186
+
187
+ === Model security for CRUD opterations
188
+ To activate model security, all it takes is an explicit enabling for each
189
+ model that model security should be enforced on, i.e.
190
+
191
+ class Employee < ActiveRecord::Base
192
+ using_access_control
193
+ ...
194
+ end
195
+
196
+ Thus,
197
+ Employee.create(...)
198
+ fails, if the current user is not allowed to :create :employees according
199
+ to the authorization rules. For the application to find out about what
200
+ happened if an operation is denied, the filters throw
201
+ Authorization::NotAuthorized exceptions.
202
+
203
+ As access control on read are costly, with possibly lots of objects being
204
+ loaded at a time in one query, checks on read need to be actived explicitly by
205
+ adding the :include_read option.
206
+
207
+ === Query rewriting using named scopes
208
+ When retrieving large sets of records from databases, any authorization needs
209
+ to be integrated into the query in order to prevent inefficient filtering
210
+ afterwards and to use LIMIT and OFFSET in SQL statements. To keep authorization
211
+ rules out of the source code, this plugin offers query rewriting mechanisms
212
+ through named scopes. Thus,
213
+
214
+ Employee.with_permissions_to(:read)
215
+
216
+ returns all employee records that the current user is authorized to read. In
217
+ addition, just like normal named scopes, query rewriting may be chained with
218
+ the usual find method:
219
+
220
+ Employee.with_permissions_to(:read).find(:all, :conditions => ...)
221
+
222
+ If the current user is completely missing the permissions, an
223
+ Authorization::NotAuthorized exception is raised. Through
224
+ Model.obligation_conditions, application developers may retrieve
225
+ the conditions for manual rewrites.
226
+
227
+
228
+ == Authorization Rules
229
+
230
+ Authorization rules are defined in config/authorization_rules.rb. E.g.
231
+
232
+ authorization do
233
+ role :admin do
234
+ has_permission_on :employees, :to => [:create, :read, :update, :delete]
235
+ end
236
+ end
237
+
238
+ There is a default role :+guest+ that is used if a request is not associated
239
+ with any user or with a user without any roles. So, if your application has
240
+ public pages, :+guest+ can be used to allow access for users that are not
241
+ logged in. All other roles are application defined and need to be associated
242
+ with users by the application.
243
+
244
+ Privileges, such as :create, may be put into hierarchies to simplify
245
+ maintenance. So the example above has the same meaning as
246
+
247
+ authorization do
248
+ role :admin do
249
+ has_permission_on :employees, :to => :manage
250
+ end
251
+ end
252
+
253
+ privileges do
254
+ privilege :manage do
255
+ includes :create, :read, :update, :delete
256
+ end
257
+ end
258
+
259
+ Privilege hierarchies may be context-specific, e.g. applicable to :employees.
260
+
261
+ privileges do
262
+ privilege :manage, :employees, :includes => :increase_salary
263
+ end
264
+
265
+ For more complex use cases, authorizations need to be based on attributes. E.g.
266
+ if a branch admin should manage only employees of his branch (see
267
+ Authorization::Reader in the API docs for a full list of available operators):
268
+
269
+ authorization do
270
+ role :branch_admin do
271
+ has_permission_on :employees do
272
+ to :manage
273
+ # user refers to the current_user when evaluating
274
+ if_attribute :branch => is {user.branch}
275
+ end
276
+ end
277
+ end
278
+
279
+ To reduce redundancy in has_permission_on blocks, a rule may depend on
280
+ permissions on associated objects:
281
+
282
+ authorization do
283
+ role :branch_admin do
284
+ has_permission_on :branches, :to => :manage do
285
+ if_attribute :managers => contains {user}
286
+ end
287
+
288
+ has_permission_on :employees, :to => :manage do
289
+ if_permitted_to :manage, :branch
290
+ # instead of
291
+ #if_attribute :branch => {:managers => contains {user}}
292
+ end
293
+ end
294
+ end
295
+
296
+ Lastly, not only privileges may be organized in a hierarchy but roles as well.
297
+ Here, project manager inherit the permissions of employees.
298
+
299
+ role :project_manager do
300
+ includes :employee
301
+ end
302
+
303
+ See also Authorization::Reader.
304
+
305
+ == Testing
306
+
307
+ declarative_authorization provides a few helpers to ease the testing with
308
+ authorization in mind.
309
+
310
+ In your test_helper.rb, to enable the helpers add
311
+
312
+ require File.expand_path(File.dirname(__FILE__) +
313
+ "/../vendor/plugins/declarative_authorization/lib/maintenance")
314
+
315
+ class Test::Unit::TestCase
316
+ include Authorization::TestHelper
317
+ ...
318
+ end
319
+
320
+ Now, in unit tests, you may deactivate authorization if needed e.g. for test
321
+ setup and assume certain identities for tests:
322
+
323
+ class EmployeeTest < ActiveSupport::TestCase
324
+ def test_should_read
325
+ without_access_control do
326
+ Employee.create(...)
327
+ end
328
+ assert_nothing_raised do
329
+ with_user(admin) do
330
+ Employee.find(:first)
331
+ end
332
+ end
333
+ end
334
+ end
335
+
336
+ In functional tests, get, posts, etc. may be tested in the name of certain users:
337
+
338
+ get_with admin, :index
339
+ post_with admin, :update, :employee => {...}
340
+
341
+ See Authorization::TestHelper for more information.
342
+
343
+
344
+ = Installation of declarative_authorization
345
+
346
+ To install simply execute in your applications root directory
347
+ cd vendor/plugins && git clone git://github.com/stffn/declarative_authorization.git
348
+
349
+ Alternatively, download one of the released versions from Github at
350
+ http://github.com/stffn/declarative_authorization/downloads
351
+
352
+ Then,
353
+ * provide the requirements as noted below,
354
+ * create a basic config/authorization_rules.rb--you might want to take the
355
+ provided example authorization_rules.dist.rb in the plugin root as a starting
356
+ point,
357
+ * add +filter_access_to+, +permitted_to+? and model security as needed.
358
+
359
+ == Providing the Plugin's Requirements
360
+ The requirements are
361
+ * Rails >= 2.1 and Ruby >= 1.8.6, including 1.9
362
+ * An authentication mechanism
363
+ * A user object returned by controller.current_user
364
+ * An array of role symbols returned by user.role_symbols
365
+
366
+ Of the various ways to provide these requirements, here is one way employing
367
+ restful_authentication.
368
+
369
+ * Install restful_authentication
370
+ cd vendor/plugins && git clone git://github.com/technoweenie/restful-authentication.git restful_authentication
371
+ cd ../.. && ruby script/generate authenticated user sessions
372
+ * Move "include AuthenticatedSystem" to ApplicationController
373
+ * Add +filter_access_to+ calls as described above.
374
+ * If you'd like to use model security, add a before_filter that sets the user
375
+ globally to your ApplicationController. This is thread-safe.
376
+ before_filter :set_current_user
377
+ protected
378
+ def set_current_user
379
+ Authorization.current_user = current_user
380
+ end
381
+
382
+ * Add roles field to the User model through a :+has_many+ association
383
+ (this is just one possible approach; you could just as easily use
384
+ :+has_many+ :+through+ or a serialized roles array):
385
+ * create a migration for table roles
386
+ class CreateRoles < ActiveRecord::Migration
387
+ def self.up
388
+ create_table "roles" do |t|
389
+ t.column :title, :string
390
+ t.references :user
391
+ end
392
+ end
393
+
394
+ def self.down
395
+ drop_table "roles"
396
+ end
397
+ end
398
+
399
+ * create a model Role,
400
+ class Role < ActiveRecord::Base
401
+ belongs_to :user
402
+ end
403
+
404
+ * add +has_many+ :+roles+ to the User model and a roles method that returns the roles
405
+ as an Array of Symbols, e.g.
406
+ class User < ActiveRecord::Base
407
+ has_many :roles
408
+ def role_symbols
409
+ (roles || []).map {|r| r.title.to_sym}
410
+ end
411
+ end
412
+
413
+ * add roles to your User objects using e.g.
414
+ user.roles.create(:title => "admin")
415
+
416
+ Note: If you choose to generate an Account model for restful_authentication
417
+ instead of a User model as described below, you have to customize the
418
+ examples and create a ApplicationController#current_user method.
419
+
420
+
421
+ == Debugging Authorization
422
+
423
+ Currently, the main means of debugging authorization decisions is logging and
424
+ exceptions. Denied access to actions is logged to +warn+ or +info+, including
425
+ some hints about what went wrong.
426
+
427
+ All bang methods throw exceptions which may be used to retrieve more
428
+ information about a denied access than a Boolean value.
429
+
430
+
431
+ == Authorization Browser
432
+
433
+ If your authorization rules become more complex, you might be glad to use
434
+ the authorization rules browser that comes with declarative_authorization.
435
+ It has a syntax-highlighted and a graphical view with filtering of the current
436
+ authorization rules.
437
+
438
+ By default, it will only be available in development mode. To use it, add
439
+ the following lines to your authorization_rules.rb for the appropriate role:
440
+
441
+ has_permission_on :authorization_rules, :to => :read
442
+
443
+ Then, point your browser to
444
+ http://localhost/authorization_rules
445
+
446
+ The browser needs Rails 2.3 (for Engine support). The graphical view requires
447
+ Graphviz (which e.g. can be installed through the graphviz package under Debian
448
+ and Ubuntu) and is only tested under Linux.
449
+
450
+
451
+ = Help and Contact
452
+
453
+ We have an issue tracker[http://stffn.lighthouseapp.com/projects/20733-declarative_authorization]
454
+ for bugs and feature requests as well as a
455
+ Google Group[http://groups.google.com/group/declarative_authorization] for
456
+ discussions on the usage of the plugin. You are very welcome to contribute.
457
+ Just fork the git repository and create a new issue, send a pull request or
458
+ contact me personally.
459
+
460
+ Maintained by
461
+
462
+ Steffen Bartsch
463
+ TZI, Universität Bremen, Germany
464
+ sbartsch at tzi.org
465
+
466
+
467
+ = Contributors
468
+
469
+ Thanks to
470
+ * Brian Langenfeld
471
+ * Mark Mansour
472
+ * Mike Vincent
473
+
474
+
475
+ = Licence
476
+
477
+ Copyright (c) 2008 Steffen Bartsch, TZI, Universität Bremen, Germany
478
+ released under the MIT license
479
+
data/Rakefile ADDED
@@ -0,0 +1,35 @@
1
+ require 'rake'
2
+ require 'rake/testtask'
3
+ require 'rake/rdoctask'
4
+
5
+ desc 'Default: run unit tests.'
6
+ task :default => :test
7
+
8
+ desc 'Test the authorization plugin.'
9
+ Rake::TestTask.new(:test) do |t|
10
+ t.libs << 'lib'
11
+ t.pattern = 'test/**/*_test.rb'
12
+ t.verbose = true
13
+ end
14
+
15
+ desc 'Generate documentation for the authorization plugin.'
16
+ Rake::RDocTask.new(:rdoc) do |rdoc|
17
+ rdoc.rdoc_dir = 'rdoc'
18
+ rdoc.title = 'Authorization'
19
+ rdoc.options << '--line-numbers' << '--inline-source'
20
+ rdoc.options << '--charset' << 'utf-8'
21
+ rdoc.rdoc_files.include('README.rdoc')
22
+ rdoc.rdoc_files.include('CHANGELOG')
23
+ rdoc.rdoc_files.include('lib/**/*.rb')
24
+ end
25
+
26
+ # load up garlic if it's here
27
+ if File.directory?(File.join(File.dirname(__FILE__), 'garlic'))
28
+ require File.join(File.dirname(__FILE__), 'garlic/lib/garlic_tasks')
29
+ require File.join(File.dirname(__FILE__), 'garlic')
30
+ end
31
+
32
+ desc "clone the garlic repo (for running ci tasks)"
33
+ task :get_garlic do
34
+ sh "git clone git://github.com/ianwhite/garlic.git garlic"
35
+ end
@@ -0,0 +1,20 @@
1
+ authorization do
2
+ role :guest do
3
+ # add permissions for guests here, e.g.
4
+ #has_permission_on :conferences, :to => :read
5
+ end
6
+
7
+ # permissions on other roles, such as
8
+ #role :admin do
9
+ # has_permission_on :conferences, :to => :manage
10
+ #end
11
+ end
12
+
13
+ privileges do
14
+ # default privilege hierarchies to facilitate RESTful Rails apps
15
+ privilege :manage, :includes => [:create, :read, :update, :delete]
16
+ privilege :read, :includes => [:index, :show]
17
+ privilege :create, :includes => :new
18
+ privilege :update, :includes => :edit
19
+ privilege :delete, :includes => :destroy
20
+ end
data/garlic_example.rb ADDED
@@ -0,0 +1,20 @@
1
+ garlic do
2
+ repo 'rails', :url => 'git://github.com/rails/rails'#, :local => "~/dev/vendor/rails"
3
+ repo 'declarative_authorization', :path => '.'
4
+
5
+ target 'edge'
6
+ target '2.1-stable', :branch => 'origin/2-1-stable'
7
+ target '2.2.0-RC1', :tag => 'v2.2.0'
8
+
9
+ all_targets do
10
+ prepare do
11
+ plugin 'declarative_authorization', :clone => true
12
+ end
13
+
14
+ run do
15
+ cd "vendor/plugins/declarative_authorization" do
16
+ sh "rake"
17
+ end
18
+ end
19
+ end
20
+ end
data/init.rb ADDED
@@ -0,0 +1,15 @@
1
+ require File.dirname(__FILE__) + "/lib/rails_legacy.rb"
2
+ require File.dirname(__FILE__) + "/lib/helper.rb"
3
+ require File.dirname(__FILE__) + "/lib/in_controller.rb"
4
+ require File.dirname(__FILE__) + "/lib/in_model.rb"
5
+ require File.dirname(__FILE__) + "/lib/obligation_scope.rb"
6
+
7
+ min_rails_version = "2.1.0"
8
+ if Rails::VERSION::STRING < min_rails_version
9
+ raise "declarative_authorization requires Rails #{min_rails_version}. You are using #{Rails::VERSION::STRING}."
10
+ end
11
+
12
+ ActionController::Base.send :include, Authorization::AuthorizationInController
13
+ ActionController::Base.helper Authorization::AuthorizationHelper
14
+
15
+ ActiveRecord::Base.send :include, Authorization::AuthorizationInModel
metadata ADDED
@@ -0,0 +1,68 @@
1
+ --- !ruby/object:Gem::Specification
2
+ name: stffn-declarative_authorization
3
+ version: !ruby/object:Gem::Version
4
+ version: 0.2.1
5
+ platform: ruby
6
+ authors:
7
+ - Steffen Bartsch
8
+ autorequire:
9
+ bindir: bin
10
+ cert_chain: []
11
+
12
+ date: 2009-02-13 00:00:00 -08:00
13
+ default_executable:
14
+ dependencies:
15
+ - !ruby/object:Gem::Dependency
16
+ name: rails
17
+ type: :runtime
18
+ version_requirement:
19
+ version_requirements: !ruby/object:Gem::Requirement
20
+ requirements:
21
+ - - ">="
22
+ - !ruby/object:Gem::Version
23
+ version: 2.1.0
24
+ version:
25
+ description:
26
+ email: sbartsch@tzi.org
27
+ executables: []
28
+
29
+ extensions: []
30
+
31
+ extra_rdoc_files: []
32
+
33
+ files:
34
+ - CHANGELOG
35
+ - MIT-LICENSE
36
+ - README.rdoc
37
+ - Rakefile
38
+ - authorization_rules.dist.rb
39
+ - garlic_example.rb
40
+ - init.rb
41
+ has_rdoc: true
42
+ homepage: http://github.com/stffn/declarative_authorization
43
+ post_install_message:
44
+ rdoc_options: []
45
+
46
+ require_paths:
47
+ - lib
48
+ required_ruby_version: !ruby/object:Gem::Requirement
49
+ requirements:
50
+ - - ">="
51
+ - !ruby/object:Gem::Version
52
+ version: 1.8.6
53
+ version:
54
+ required_rubygems_version: !ruby/object:Gem::Requirement
55
+ requirements:
56
+ - - ">="
57
+ - !ruby/object:Gem::Version
58
+ version: "0"
59
+ version:
60
+ requirements: []
61
+
62
+ rubyforge_project:
63
+ rubygems_version: 1.2.0
64
+ signing_key:
65
+ specification_version: 2
66
+ summary: declarative_authorization is a Rails plugin for authorization based on readable authorization rules.
67
+ test_files: []
68
+