bullet_train-scope_validator 1.0.1 → 1.0.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: ea9dcbec389cebbb7a24a9d868f080a27a11c29a39276e0dae7416b00265af9f
-  data.tar.gz: 379772ea2451665352e8a824c60e71d246fbdaeb3dd400d68f8025250243866d
+  metadata.gz: f7deee0cb7bca1d0e45c645f5845e598c6b7efa35da8d5bd21c9d2f3c0c0c0ee
+  data.tar.gz: 255b5f4fce08fa730d3280254b9d3b149775e849cf118410d73d59f901aa25cd
 SHA512:
-  metadata.gz: f991bdb484df712fa4020f39690a6d62b900a5c8d62e629bc00b7d8bd124346fe2a3652e1be0a230dbf7aa21a1352791f3727474d1aebc9aaf22735b57ccf2c7
-  data.tar.gz: 8f7a628c033553e81313e42912567d16237212e284ff0eb7a270a22fa1ccbd026fb24734c53c7e56a3405f252372fde56075d154cb52bafca4a76698b5dd3325
+  metadata.gz: 5f5b4778c1f8b4d48fa0ace2026f36fa7690f2b5692bbfec4fdb0a9cb8ebf8ebce7cb1b0df7c8a7a50f08f548c06d2448642798b644606df43abdaf1e777583e
+  data.tar.gz: 92c1011af64d3647dfc3ed183fafded26b962f0fce604f96b5928fdbe710b16e4addfd599b86f57a2343f0a7b9d79584dace0fadc9f5b6077ced4e86595080e2

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    bullet_train-scope_validator (1.0.1)
+    bullet_train-scope_validator (1.0.2)
 
 GEM
   remote: https://rubygems.org/

data/README.md

@@ -1,13 +1,10 @@
 # Bullet Train Scope Validator
 
-Bullet Train Scope Validator provides a simple pattern for protecting `belongs_to` associations from malicious ID
-stuffing. It was created by [Andrew Culver](https://twitter.com/andrewculver).
+Bullet Train Scope Validator provides a simple pattern for protecting `belongs_to` associations from malicious ID stuffing. It was created by [Andrew Culver](https://twitter.com/andrewculver) and extracted from [Bullet Train](https://bullettrain.co).
 
 ## Illustrating the Problem
 
-By default in a multitenant Rails application, unless special care is given to validating the ID assigned to a
-`belongs_to` association, malicious users can stuff arbitrary IDs into their request and cause an application to bleed
-data from other tenants.
+By default in a multitenant Rails application, unless special care is given to validating the ID assigned to a `belongs_to` association, malicious users can stuff arbitrary IDs into their request and cause an application to bleed data from other tenants.
 
 Consider the following example from a customer relationship management (CRM) system that two competitive companies use:
 
@@ -49,9 +46,7 @@ class DealsController < ApplicationController
 end
 ```
 
-☝️ Note that Strong Parameters allows `customer_id` to be set by incoming requests and isn't responsible for validating
-the value. We also wouldn't _want_ Strong Parameters to be responible for this, since we'd end up with duplicate
-validation logic in our API controllers and other places. This is a responsibility of the model.
+☝️ Note that Strong Parameters allows `customer_id` to be set by incoming requests and isn't responsible for validating the value. We also wouldn't _want_ Strong Parameters to be responible for this, since we'd end up with duplicate validation logic in our API controllers and other places. This is a responsibility of the model.
 
 ### Example Form
 
@@ -75,8 +70,7 @@ A malicious user can:
  - Inspect the DOM and replace the `<select>` element for `customer_id` with an `<input type="text">` element.
  - Set the value to any number, particularly numbers that are IDs they know don't belong to their account.
  - Submit the form to create the deal.
- - When the deal is shown, it will say "We have a deal with Nintendo!", where "Nintendo" is actually the customer of
-   another team in the system. ☠️ We've bled customer data across our application's tenant boundary.
+ - When the deal is shown, it will say "We have a deal with Nintendo!", where "Nintendo" is actually the customer of another team in the system. ☠️ We've bled customer data across our application's tenant boundary.
 
 ## Usage
 
@@ -105,13 +99,13 @@ class Deal < ApplicationRecord
 end
 ```
 
-Finally, we can also DRY up our form to use the same definition of valid options:
+If you're wondering what the connection between `validates :customer, scope: true` and `def valid_customers` is, it's just a convention that the former will call the latter based on the name of the attibute being validated. We've favored a full-blown method definition for this instead of simply passing in a proc into the validator because having a method allows us to also DRY up our form view to use the same definition of valid options, like so:
 
 ```
 <%= form.collection_select(:customer_id, form.object.valid_customers, :id, :name) %>
 ```
 
-That's it. You're done! Any attempts to stuff IDs will be met with an "invalid" Active Record error message.
+So with that, you're done! Any attempts to stuff IDs will be met with an "invalid" Active Record error message.
 
 ## Contributing
 

data/lib/bullet_train/scope_validator/version.rb

@@ -2,6 +2,6 @@
 
 module BulletTrain
   module ScopeValidator
-    VERSION = "1.0.1"
+    VERSION = "1.0.2"
   end
 end

data/lib/bullet_train/scope_validator.rb

@@ -2,6 +2,8 @@
 
 require_relative "scope_validator/version"
 
+require_relative "../validators/scope_validator"
+
 module BulletTrain
   module ScopeValidator
     class Error < StandardError; end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: bullet_train-scope_validator
 version: !ruby/object:Gem::Version
-  version: 1.0.1
+  version: 1.0.2
 platform: ruby
 authors:
 - Andrew Culver
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2022-01-15 00:00:00.000000000 Z
+date: 2022-01-16 00:00:00.000000000 Z
 dependencies: []
 description: Protect `belongs_to` attributes from ID stuffing.
 email: