pastore 0.0.4 → 0.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 77eb4179686bdc087cb3b82d5187714473d61d178a690ece61d23f4f238fc973
-  data.tar.gz: 66432435a048060675f5f61b966a99e917a8a810c8d713736202e334e510d42c
+  metadata.gz: cbd91d887bce717ba67bfec4b7468fb2e637471bbde99a4b5f84fddb96c3b775
+  data.tar.gz: 7a935d0e120b5f15f89bddb2bde47d1df126686355fc6210e07611117273c9b4
 SHA512:
-  metadata.gz: 929a9b868a8d659728e7ebe2688fdec531ba9b718c195d40aeb2bb3ac313d59bac4c6ab6e3180f58a43af82930a7ae45bc5409ef0bfa439c4d4055d281d203a6
-  data.tar.gz: ea444e38cad30fb09fd6cfcf86fab000abcba0f3451ec2834e35bb13b7dca8fd062dc74d56879cf8f0c779e2b4fccb9d674dc34e7e2e36c238d4da6c330bb9cc
+  metadata.gz: cd68dd37a52969a086bd6349ed71fb14f7c4fc6ee21e224d939b9316b34d13b98382042737a8111c9a4ff3d843bcd33df364c7db917255505a1b15f0d28df4dc
+  data.tar.gz: 13a30ad866732985887d329f6df15af4e4f79b48436cf71eab89dec6939ff1e186ae7d404223f094fbc4f0d05ab2a5b970a37c2fe761aaf27a6d0a00871f2109

data/.vscode/launch.json

@@ -0,0 +1,22 @@
+{
+  // Use IntelliSense to learn about possible attributes.
+  // Hover to view descriptions of existing attributes.
+  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "type": "rdbg",
+      "name": "RSpec",
+      "request": "launch",
+      "command": "bundle exec rspec",
+      "script": "${file}:${lineNumber}",
+      "args": [],
+      "askParameters": false
+    },
+    {
+      "type": "rdbg",
+      "name": "Attach with rdbg",
+      "request": "attach"
+    }
+  ]
+}

data/CHANGELOG.md

@@ -1,5 +1,30 @@
 ## [Unreleased]
 
-## [0.1.0] - 2023-01-26
+## [0.2.0] - 2023-02-16
 
-- Initial release
+- [NEW] Implemented the feature which allows to get the current role with `#current_role` method inside controllers actions.
+
+## [0.1.1] - 2023-02-14
+
+- [FIX] Accept `Array` values as valid falues for `:object` params.
+
+## [0.1.0] - 2023-02-13
+
+- [NEW] Implemented `Pastore::Params` feature for params validation.
+
+## [0.0.4] - 2023-02-02
+
+- [FIX] Correctly inherit default guards strategy from parent class.
+
+## [0.0.3] - 2023-02-02
+
+- [FIX] Correctly handle guards callback inheritance.
+
+## [0.0.2] - 2023-02-01
+
+- [NEW] Added some RSpec tests.
+- [NEW] Setup automated tests.
+
+## [0.0.1] - 2023-01-31
+
+- [NEW] First implementation of `Pastore::Guards` feature.

data/Gemfile

@@ -5,8 +5,11 @@ source 'https://rubygems.org'
 # Specify your gem's dependencies in pastore.gemspec
 gemspec
 
-gem 'faker'
-gem 'rake'
-gem 'rspec-rails'
-gem 'shoulda-matchers'
-gem 'pry'
+group :test do
+  gem 'faker'
+  gem 'pry'
+  gem 'rake'
+  gem 'rspec-rails'
+  gem 'shoulda-matchers'
+  gem 'simplecov'
+end

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    pastore (0.0.4)
+    pastore (0.2.0)
       rails (>= 4.0)
 
 GEM
@@ -78,6 +78,7 @@ GEM
     crass (1.0.6)
     date (3.3.2)
     diff-lcs (1.5.0)
+    docile (1.4.0)
     erubi (1.11.0)
     faker (3.1.0)
       i18n (>= 1.8.11, < 2)
@@ -96,7 +97,6 @@ GEM
     marcel (1.0.2)
     method_source (1.0.0)
     mini_mime (1.1.2)
-    mini_portile2 (2.8.0)
     minitest (5.17.0)
     net-imap (0.3.2)
       date
@@ -108,8 +108,7 @@ GEM
     net-smtp (0.3.3)
       net-protocol
     nio4r (2.5.8)
-    nokogiri (1.13.10)
-      mini_portile2 (~> 2.8.0)
+    nokogiri (1.13.10-x86_64-linux)
       racc (~> 1.4)
     pry (0.14.2)
       coderay (~> 1.1)
@@ -164,6 +163,12 @@ GEM
     rspec-support (3.12.0)
     shoulda-matchers (5.3.0)
       activesupport (>= 5.2.0)
+    simplecov (0.22.0)
+      docile (~> 1.1)
+      simplecov-html (~> 0.11)
+      simplecov_json_formatter (~> 0.1)
+    simplecov-html (0.12.3)
+    simplecov_json_formatter (0.1.4)
     thor (1.2.1)
     timeout (0.3.1)
     tzinfo (2.0.5)
@@ -183,6 +188,7 @@ DEPENDENCIES
   rake
   rspec-rails
   shoulda-matchers
+  simplecov
 
 BUNDLED WITH
    2.3.24

data/README.md

@@ -1,229 +1,44 @@
 # Pastore
 
+[![Maintainability](https://api.codeclimate.com/v1/badges/8f203ba7696c063e9cd2/maintainability)](https://codeclimate.com/github/demetra-it/pastore/maintainability)
+[![Test Coverage](https://api.codeclimate.com/v1/badges/8f203ba7696c063e9cd2/test_coverage)](https://codeclimate.com/github/demetra-it/pastore/test_coverage)
+
 Pastore is a powerful gem for Rails that simplifies the process of validating parameters and controlling access to actions in your controllers.
 With Pastore, you can easily define validations for your parameters, ensuring that they meet specific requirements before being passed to your controller actions.
 Additionally, Pastore allows you to easily control access to your actions, ensuring that only authorized users can access sensitive information.
 With its intuitive interface and robust features, Pastore is a must-have tool for any Rails developer looking to improve the security and reliability of their application.
 
-## Installation
-
-Install the gem and add to the application's Gemfile by executing:
-
-    bundle add pastore
-
-If bundler is not being used to manage dependencies, install the gem by executing:
-
-    gem install pastore
-
-## Usage
-
-Pastore gem implements 2 main features: `Guards` and `Validators`. Guards are intended to be used for action access control, while Validators are intended to be used for actions params validation.
-
-### Guards usage
-
-`Guards` feature allows you to define access control logic for actions in Rails controllers. To use the `Guards` you have to include `Pastore::Guards` into your Rails controller.
-
-##### Setup
-
-The best way to start using the `Guards` feature is to add the following code to your `ApplicationController`:
-
-```ruby
-# app/controllers/application_controller.rb
-
-class ApplicationController < ActionController::API
-  include Pastore::Guards
-
-  # Specify the logic for current user's role detection, which will be used to check
-  # if current user is authorized to access a specific action.
-  detect_role do
-    current_user&.role
-  end
-end
-```
-
-In this way all your controllers will inherit the authorization settings from `ApplicationController`. Then in your controller you can do something like this:
-
-```ruby
-class MyController < ApplicationController
-  # By default a :deny strategy is used, so with #permit_role we're going
-  # to specify which roles are allowed to access this action.
-  permit_role :admin, :user, :pm
-  def index
-    # ... action code ...
-  end
-
-  # Without a `permit_role` definition the access to this action will be denied to everyone.
-  def not_allowed_action
-    # ... action code ...
-  end
-end
-```
-
-If you want to use `Guards` only in specific controllers, just include `Pastore::Guards` and define `detect_role` in your controller:
+## Requirements
 
-```ruby
-class CustomController < ApplicationController
-  include Pastore::Guards
+- Ruby >= 2.6
+- Rails >= 5.x
 
-  detect_role do
-    current_user&.role
-  end
+## Installation
 
-  permit_role :admin, :supervisor
-  def index
-    # ... action code ...
-  end
-end
-```
+Install the gem and add to the application's Gemfile by executing:
 
-#### Custom authorization logic
-
-If checking user's role is not enough, you can use the `authorize_with` helper, which will allow you to specify a custom access logic by providing a method name (where custom logic is defined) or a block to use for access verification. As a result your block or method should return `true` if access is granted, or `false` otherwise.
-
-```ruby
-class MyController < ApplicationController
-  # You can override the role detection logic inside a controller if it's necessary by
-  # using the `detect_role` helper.
-  detect_role do
-    current_user&.selected_role
-  end
-
-  # If you want to use a custom/dynamic authorization logic, you can
-  # specify your own implementation in a method.
-  authorize_with :custom_authorization
-  def index
-    # ... action code ...
-  end
-
-  # You can also specify the authorization logic in a block.
-  authorize_with { custom_authorized? }
-  def show
-    # ... action code ...
-  end
-
-  # Allow only users with `admin` role to access this action.
-  permit_role :admin
-  def update
-  end
-
-  private
-
-  # Specify a custom authorization logic (return `true` if successful and `false` when forbidden).
-  def custom_authorization
-    # ... your custom authorization logic here ...
-  end
-end
+```bash
+bundle add pastore
 ```
 
-#### Using `allow` strategy
-
-**!!! WARNING !!!** Be careful when using `allow` strategy, because when enabled it grants access to every action in the controller, which could potentially lead to security issues.
-
-By default `Pastore::Guards` will use `deny` strategy, which means that the access is denied by default, and the only way to access it is through explicit authorization.
-
-Sometimes you might prefer a `allow` strategy instead, in order to allow access to any action within the controller, and manually restrict access to specified actions and roles.
-
-For doing so you can use `use_allow_strategy!`, which changes the default strategy. In this case you should use `deny_role` to disable the access for a specific role or overwrite authorization strategy for specific actions with `authorize_with` helper.
-
-
-
-```ruby
-class MyController < ApplicationController
-  # By default allow access to any action within the controller by any role.
-  use_allow_strategy!
-
-  # In this case we're using the :allow strategy, so if we want to exclude a specific role
-  # we can do it by using #deny_role method.
-  deny_role :user
-  def index
-    # ... action code ...
-  end
-
-  # Check access by using a custom method
-  authorize_with :custom_autorization
-  def restricted_access_action
-    # ... action code ...
-  end
-
-  # Check access by using a block
-  authorize_with { current_user&.role == 'admin' }
-  def restricted_access_action2
-    # ... action code ...
-  end
-
-  private
+If bundler is not being used to manage dependencies, install the gem by executing:
 
-  # Specify a custom authorization logic (return `true` if successful and `false` when forbidden).
-  def custom_autorization
-    # ... custom authorization logic ...
-  end
-end
+```bash
+gem install pastore
 ```
 
-#### Using `skip_guards`
-
-Sometime you may want to disable the `Guards` feature for specific actions. For doing so you can use the `skip_guards` helper, which allows you to specify the list of actions for which guards check have to be disabled. In the example below the access to `index` and `show` actions is granted by `skip_guards` which bypasses the guards check. `skip_guards` have priority over `permit_role`, `deny_role` and `authorize_with`, so using those helpers on actions with disabled guards will have no effect and the access will be granted anyway.
-
-```ruby
-class CustomController < ApplicationController
-  use_deny_strategy!
-  skip_guards :index, :show
+## Usage
 
-  def index
-    # ... action code ...
-  end
+Pastore gem implements 2 main features: `Guards` and `Params`. Guards are intended to be used for action access control, while `Params` are intended to be used for actions params validation.
 
-  authorize_with { false } # this will be ignored because of `skip_guards`
-  def show
-    # ... action code ...
-  end
-end
-```
-
-You can also use `skip_guards` helper with `:except` key, which is useful when you need to disable
-guards for all the actions except a few:
-
-```ruby
-class CustomController < ApplicationController
-  # disable guards for :action_one and :action_two
-  skip_guards except: %i[action_one action_two]
-
-  # Guards DISABLED
-  def index
-    # ... action code ...
-  end
-
-  # Guards ENABLED
-  def action_one
-    # ... action code ...
-  end
-
-  # Guards ENABLED
-  def action_two
-    # ... action code ...
-  end
-
-  # Guards DISABLED
-  def action_three
-    # ... action code ...
-  end
-end
-```
+You can find more about `Params` and `Guards` by following the links below:
 
-#### `Pastore::Guards` features
+* **[Guards docs](./docs/Guards.md)**
+* **[Params docs](./docs/Params.md)**
 
-Below you can find the list of methods implemented by `Pastore::Guards`, that can be used inside
-your Rails Controller.
+## `Pastore::Params` usage
 
-| Method | Description |
-|--------|-------------|
-| `use_deny_strategy!` | Set to `deny` the default authorization strategy, which meands that by default the access to the actions will be denied |
-| `use_allow_strategy!` | Set to `allow` the default authorization strategy, which automatically authorizes the access to all the actions. **!!! WARNING !!!** Be careful when using `allow` strategy, because that way any user can access any action of your controller, including guest users if not filtered before. |
-| `detect_role(&block)` | Allows to specify the logic for user role detection. This block will be automatically called to get current user's role information. |
-| `permit_role(*roles)` | Specifies the roles that are allowed to access the action that follows. |
-| `deny_role(*roles)` | Specifies the roles that are not allowed to access the action that follows. |
-| <code>authorize_with(Symbol\|&block)</code> | Allows to specify a custom authorization logic to use for action access check. Accepts a method name or a block. |
-| <code>skip_guards(*Symbol\|*String, except: *Symbol\|*String)</code> | Allows to disable guards for specific actions. Accepts a list of actions for which to disable guards (e.g. `skip_guards :index, 'show'`), but can be also used to disable guards for all the actions except specified (e.g. `skip_guards except: :index`). |
+`Pastore::Params` is the module that provides the features for params validation in Rails controllers. It allows you to define the params with their data type (`string`, `number`, `boolean`, `date` and `object`), specify which params are mandatory and cannot be blank.
 
 ## Contributing
 

data/docs/Guards.md

@@ -0,0 +1,203 @@
+# `Pastore::Guards`
+
+`Guards` feature allows you to define access control logic for actions in Rails controllers. To use the `Guards` you have to include `Pastore::Guards` into your Rails controller.
+
+## Setup
+
+The best way to start using the `Guards` feature is to add the following code to your `ApplicationController`:
+
+```ruby
+# app/controllers/application_controller.rb
+
+class ApplicationController < ActionController::API
+  include Pastore::Guards
+
+  # Specify the logic for current user's role detection, which will be used to check
+  # if current user is authorized to access a specific action.
+  detect_role do
+    current_user&.role
+  end
+end
+```
+
+In this way all your controllers will inherit the authorization settings from `ApplicationController`. Then in your controller you can do something like this:
+
+```ruby
+class MyController < ApplicationController
+  # By default a :deny strategy is used, so with #permit_role we're going
+  # to specify which roles are allowed to access this action.
+  permit_role :admin, :user, :pm
+  def index
+    # ... action code ...
+  end
+
+  # Without a `permit_role` definition the access to this action will be denied to everyone.
+  def not_allowed_action
+    # ... action code ...
+  end
+end
+```
+
+If you want to use `Guards` only in specific controllers, just include `Pastore::Guards` and define `detect_role` in your controller:
+
+```ruby
+class CustomController < ApplicationController
+  include Pastore::Guards
+
+  detect_role do
+    current_user&.role
+  end
+
+  permit_role :admin, :supervisor
+  def index
+    # ... action code ...
+  end
+end
+```
+
+## Custom authorization logic
+
+If checking user's role is not enough, you can use the `authorize_with` helper, which will allow you to specify a custom access logic by providing a method name (where custom logic is defined) or a block to use for access verification. As a result your block or method should return `true` if access is granted, or `false` otherwise.
+
+```ruby
+class MyController < ApplicationController
+  # You can override the role detection logic inside a controller if it's necessary by
+  # using the `detect_role` helper.
+  detect_role do
+    current_user&.selected_role
+  end
+
+  # If you want to use a custom/dynamic authorization logic, you can
+  # specify your own implementation in a method.
+  authorize_with :custom_authorization
+  def index
+    # ... action code ...
+  end
+
+  # You can also specify the authorization logic in a block.
+  authorize_with { custom_authorized? }
+  def show
+    # ... action code ...
+  end
+
+  # Allow only users with `admin` role to access this action.
+  permit_role :admin
+  def update
+  end
+
+  private
+
+  # Specify a custom authorization logic (return `true` if successful and `false` when forbidden).
+  def custom_authorization
+    # ... your custom authorization logic here ...
+  end
+end
+```
+
+## Using `allow` strategy
+
+**!!! WARNING !!!** Be careful when using `allow` strategy, because when enabled it grants access to every action in the controller, which could potentially lead to security issues.
+
+By default `Pastore::Guards` will use `deny` strategy, which means that the access is denied by default, and the only way to access it is through explicit authorization.
+
+Sometimes you might prefer a `allow` strategy instead, in order to allow access to any action within the controller, and manually restrict access to specified actions and roles.
+
+For doing so you can use `use_allow_strategy!`, which changes the default strategy. In this case you should use `deny_role` to disable the access for a specific role or overwrite authorization strategy for specific actions with `authorize_with` helper.
+
+```ruby
+class MyController < ApplicationController
+  # By default allow access to any action within the controller by any role.
+  use_allow_strategy!
+
+  # In this case we're using the :allow strategy, so if we want to exclude a specific role
+  # we can do it by using #deny_role method.
+  deny_role :user
+  def index
+    # ... action code ...
+  end
+
+  # Check access by using a custom method
+  authorize_with :custom_autorization
+  def restricted_access_action
+    # ... action code ...
+  end
+
+  # Check access by using a block
+  authorize_with { current_user&.role == 'admin' }
+  def restricted_access_action2
+    # ... action code ...
+  end
+
+  private
+
+  # Specify a custom authorization logic (return `true` if successful and `false` when forbidden).
+  def custom_autorization
+    # ... custom authorization logic ...
+  end
+end
+```
+
+## Using `skip_guards`
+
+Sometime you may want to disable the `Guards` feature for specific actions. For doing so you can use the `skip_guards` helper, which allows you to specify the list of actions for which guards check have to be disabled. In the example below the access to `index` and `show` actions is granted by `skip_guards` which bypasses the guards check. `skip_guards` have priority over `permit_role`, `deny_role` and `authorize_with`, so using those helpers on actions with disabled guards will have no effect and the access will be granted anyway.
+
+```ruby
+class CustomController < ApplicationController
+  use_deny_strategy!
+  skip_guards :index, :show
+
+  def index
+    # ... action code ...
+  end
+
+  authorize_with { false } # this will be ignored because of `skip_guards`
+  def show
+    # ... action code ...
+  end
+end
+```
+
+You can also use `skip_guards` helper with `:except` key, which is useful when you need to disable
+guards for all the actions except a few:
+
+```ruby
+class CustomController < ApplicationController
+  # disable guards for :action_one and :action_two
+  skip_guards except: %i[action_one action_two]
+
+  # Guards DISABLED
+  def index
+    # ... action code ...
+  end
+
+  # Guards ENABLED
+  def action_one
+    # ... action code ...
+  end
+
+  # Guards ENABLED
+  def action_two
+    # ... action code ...
+  end
+
+  # Guards DISABLED
+  def action_three
+    # ... action code ...
+  end
+end
+```
+
+## `Pastore::Guards` features
+
+Below you can find the list of methods implemented by `Pastore::Guards`, that can be used inside
+your Rails Controller.
+
+| Method | Description |
+|--------|-------------|
+| `use_deny_strategy!` | Set to `deny` the default authorization strategy, which meands that by default the access to the actions will be denied |
+| `use_allow_strategy!` | Set to `allow` the default authorization strategy, which automatically authorizes the access to all the actions. **!!! WARNING !!!** Be careful when using `allow` strategy, because that way any user can access any action of your controller, including guest users if not filtered before. |
+| `detect_role(&block)` | Allows to specify the logic for user role detection. This block will be automatically called to get current user's role information. |
+| `permit_role(*roles)` | Specifies the roles that are allowed to access the action that follows. |
+| `deny_role(*roles)` | Specifies the roles that are not allowed to access the action that follows. |
+| <code>authorize_with(Symbol\|&block)</code> | Allows to specify a custom authorization logic to use for action access check. Accepts a method name or a block. |
+| <code>skip_guards(*Symbol\|*String, except: *Symbol\|*String)</code> | Allows to disable guards for specific actions. Accepts a list of actions for which to disable guards (e.g. `skip_guards :index, 'show'`), but can be also used to disable guards for all the actions except specified (e.g. `skip_guards except: :index`). |