stffn-declarative_authorization 0.2.1

Sign up to get free protection for your applications and to get access to all the features.
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
+