access-granted 0.2 → 0.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 73df010b82397adef1ad1fbfdb345d0e5875ae86
-  data.tar.gz: f6db604ca6be5fc22d24225728b700df5ed4db5b
+  metadata.gz: d6d610eeb4a1e57538d942c6f1cd0bfe6958a852
+  data.tar.gz: 50ce2232aa01528cb8478a38e578a8424ca0e801
 SHA512:
-  metadata.gz: 98ae394fea6d7a5e4695e76746dc6e0701da2be4c21f9145edc979644e22faa2e3f5149bea758ee6799c2914e833d13bb678c051e7a8df8e35a6c42decae21a4
-  data.tar.gz: 92f00c7b8668b51f25b4041022e26f095d65e302b79a5853aa500901dd851735b107336fa39e03899e4be723dd29fb78c7506a0e458737a89917e91fb1b831df
+  metadata.gz: 0768c9dd24d77292180d8574f9155312c3a4028b2259d8125d8db36754e8a26c7bb448f88452f2b7588fa72edd9e46d68522ea1a3eb6e3a2b185ef766ecc292d
+  data.tar.gz: 7852d05613d5afa58e5cf6aa23a0432efab48ba0b7badc812047a107543e1c9784492ed591547e5f3cb649a0f58e2f53f75b8c1f964741451053eaea72111c49

data/README.md

@@ -12,22 +12,22 @@ Multi-role and whitelist based authorization gem for Rails. And it's lightweight
 
 ### Supported Ruby versions
 
-Guaranteed to work on all major Ruby versions MRI 1.9.3-2.2, Rubinius >= 2.X and JRuby >= 1.7.
+Because it has **zero** runtime dependencies it is guaranteed to work on all major Ruby versions MRI 1.9.3-2.2, Rubinius >= 2.X and JRuby >= 1.7.
 
 ## Summary
 
-AccessGranted is meant as a replacement for CanCan to solve three major problems:
+AccessGranted is meant as a replacement for CanCan to solve major problems:
 
 1. Performance
-  On average AccessGranted is 50-60% faster in resolving identical dependencies and takes less memory.
-  See [benchmarks](https://github.com/chaps-io/access-granted/blob/master/benchmarks).
 
-2. Built-in support for user roles
+  On average AccessGranted is 50-60% faster in resolving identical permissions and takes less memory.
+  See [benchmarks](https://github.com/chaps-io/access-granted/blob/master/benchmarks).
 
-  Easy to read access policy code where permissions are cleanly grouped into roles.
-  Additionally, permissions are forced to be unique in the scope of a role. This greatly simplifies resolving permissions and makes it faster.
+2. Roles
 
-3. white-list based
+  Adds support for roles, so no more `if`'s and `else`'s in your Policy file. This makes it extremely easy to maintain and read the code.
+  
+3. white-lists
 
   This means that you define what the user **can** do, which results in clean, readable policies regardless of app complexity.
   You don't have to worry about juggling `can`s and `cannot`s in a very convoluted way!
@@ -37,7 +37,7 @@ AccessGranted is meant as a replacement for CanCan to solve three major problems
 4. framework agnostic
 
   Permissions can work on basically any object and AccessGranted is framework-agnostic,
-  but it has Rails support of out the box :)
+  but it has Rails support out of the box :)
   It **does not depend on any libraries**, pure and clean Ruby code. Guaranteed to always work,
   even when software around changes.
 
@@ -88,7 +88,7 @@ end
 #### Defining roles
 
 Each `role` method accepts the name of the role you're creating and an optional matcher.
-Matchers are used to check if user belongs to that role and if the permissions inside should be executed against him.
+Matchers are used to check if user belongs to that role and if the permissions inside should be executed against it.
 
 The simplest role can be defined as follows:
 
@@ -115,8 +115,8 @@ role :member do
 end
 ```
 
-The `{ is_admin: true }` hash is compared with the user's attributes to see if the role should be applied to him.
-So, if the user has an attribute `is_admin` set to `true`, then the role will be applied to him.
+The `{ is_admin: true }` hash is compared with the user's attributes to see if the role should be applied to it.
+So, if the user has an attribute `is_admin` set to `true`, then the role will be applied to it.
 
 **Note:** you can use more keys in the hash to check many attributes at once.
 
@@ -133,8 +133,8 @@ end
 
 #### Block conditions
 
-"But wait! User should also be able to edit his posts, and only his posts!" you are wondering.
-This can be done using a block condition in `can` method, like this:
+"But wait! User should also be able to edit his posts, and only his posts!", you are wondering.
+This can be done using a block condition in `can` method, like so:
 
 ```ruby
 role :member do
@@ -144,11 +144,11 @@ role :member do
 end
 ```
 
-When the given block evaluates to `true`, the user is then given the permission to update the post.
+When the given block evaluates to `true`, then user is given the permission to update the post.
 
 #### Roles in order of importance
 
-Additionally we can allow admins to update **all** posts despite them not being authors like this:
+Additionally, we can allow admins to update **all** posts despite them not being authors like so:
 
 
 ```ruby
@@ -218,6 +218,7 @@ class UsersController
     # (...)
   end
 end
+```
 
 #### Checking permissions in views
 
@@ -234,7 +235,7 @@ You can hide any part of the page from users without permissions like this:
 
 #### Customizing policy
 
-By default AccessGranted adds this method to your controllers:
+By default, AccessGranted adds this method to your controllers:
 
 ```ruby
   def current_policy
@@ -242,7 +243,7 @@ By default AccessGranted adds this method to your controllers:
   end
 ```
 
-If you have a different policy class or if your user is not stored in `current_user` variable, then you can override it in any controllers and modify the logic as you please.
+If you have a different policy class or if your user is not stored in `current_user` variable, then you can override it in any controller and modify the logic as you please.
 
 You can even have different policies for different controllers!
 
@@ -311,7 +312,7 @@ end
 
 ## Compatibility with CanCan
 
-This gem was created as a replacement for CanCan and therefore it requires minimum work to switch.
+This gem has been created as a replacement for CanCan and therefore it requires minimum work to switch.
 
 ### Main differences
 
@@ -322,10 +323,10 @@ This gem was created as a replacement for CanCan and therefore it requires minim
 
 2. Both `can?`/`cannot?` and `authorize!` methods work in Rails controllers and views, just like in CanCan.
    The only change you have to make is to replace all `can? :manage, Class` with the exact action to check against.
-   `can :manage` is still available for **defining** methods and serves as a shortcut for defining `:read`, `:create`, `:update`, `:destroy` all in one line.
+   `can :manage` is still available for **defining** methods and serves as a shortcut for defining `:create`, `:read`, `:update`, `:destroy` all in one line.
 
 3. Syntax for defining permissions in AccessPolicy file (Ability in CanCan) is exactly the same,
-   with added roles on top. See [Usage](#usage) below.
+   with roles added on top. See [Usage](#usage) below.
 
 
 ## Contributing

data/access-granted.gemspec

@@ -4,7 +4,7 @@ $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
 
 Gem::Specification.new do |spec|
   spec.name          = "access-granted"
-  spec.version       = "0.2"
+  spec.version       = "0.2.1"
   spec.authors       = ["Piotrek Okoński"]
   spec.email         = ["piotrek@okonski.org"]
   spec.description   = %q{Role based authorization gem}

data/benchmarks/README.md

@@ -1,6 +1,6 @@
 # Benchmark results
 
-Benchmarks ran on Ubuntu 15.10 64bit, i5 2500k @ 4.4Ghz, 16 GB RAM with Ruby 2.2.
+Benchmarks ran on Ubuntu 15.04 64bit, i5 2500k @ 4.4Ghz, 16 GB RAM with Ruby 2.2.
 
 ## permissions.rb
 

data/lib/access-granted.rb

@@ -13,3 +13,9 @@ if defined? ActionController::Base
     include AccessGranted::Rails::ControllerMethods
   end
 end
+
+if defined? ActionController::API
+  ActionController::API.class_eval do
+    include AccessGranted::Rails::ControllerMethods
+  end
+end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: access-granted
 version: !ruby/object:Gem::Version
-  version: '0.2'
+  version: 0.2.1
 platform: ruby
 authors:
 - Piotrek Okoński