layered-resource-rails 0.3.0 → 0.3.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: bfe32848fe680ff7bcbafa8c72d1d7c46a83fb48c3a440411eae26f5fe766cb3
-  data.tar.gz: 9c47bbcff2783c5423cc1d0d7360d27934ed18debbb3bedda72af65b8995b312
+  metadata.gz: 8bc9f9c8cd7248c93dcfe75e5af6c62e73f15e12f7a6a2092b213bbf3c5ffaf3
+  data.tar.gz: bc8992afbc303af01d63f9a0d86e01e3141e5cff9b47b4f6d61db7b7d68c560a
 SHA512:
-  metadata.gz: 5b79478c63e11f9cd96af0df6aa89ed46e8f133ac90c2f05842d0a2f19cec7156faf70aa9f75c803a4c7655b20e771c0e11c0d6d95c2bba927582d1a30b9116b
-  data.tar.gz: 013feae5be9a1c9e717434411d7f9d2de288cff2669400ae14477a27cdc104098a0d78d45584366da675be3892dec955fd3ba6104a1f1a3f3e0903fc00518c7c
+  metadata.gz: 91a5a65b3a8b3ac9108046f040e9b38d5ad58e79cd457343cea5d25cedf8c37a16d4077fcaf7d12f5a7da0ecbfa07e293c88169342048f82bc508df47d1606f1
+  data.tar.gz: eaf791793476475fc62b310fe841c186fb23561302aad6e26a06fe0f6f4c975de37e32f1fdc4360af9b3f1eb1ad41a48a34587af9939e5a72603ebed08246ede

data/.claude/skills/layered-resource-rails/SKILL.md

@@ -177,7 +177,7 @@ Inference by column type: `enum`/`belongs_to` -> multi-select (`_in`; `multiple:
 
 **Long option lists switch control.** A select-type filter renders as the plain list (multi-select: checkboxes + Apply; single-choice: instant-apply links) up to `Layered::Resource.filter_combobox_threshold` options (10), and as a type-ahead **combobox** past it — a checkbox list of every user is no way to pick one. A single-choice combobox posts a scalar (no `[]`), so `_eq` gets the value rather than an array. The count is taken per request, after a `collection:` callable resolves, so the control follows the data; the decision lives in `layered_filter_control` (the view helper), not in `resolved_filters`, for exactly that reason. Declaring `as:` pins the control and opts out: `as: :select` keeps the list however long, `as: :combobox` uses the combobox however short.
 
-**Remote options.** `url:` fetches the options from an endpoint as the user types instead of rendering a collection — such a filter is always a combobox (nothing to render or count). Give it as a callable (`-> { user_options_path }`) so it resolves per request in the view, where route helpers exist. The endpoint is an ordinary host-app action including `Layered::Ui::ComboboxOptions` and returning `l_ui_combobox_options(scope, label:, search:)` — the gem never routes it, so it's authorised however any index is. Since the browser has no collection to look a label up in, an active remote filter's values are labelled server-side from the records (same `name`/`title`/`label`/`email` fallbacks), so the tag reads "User: Alice" not "User: 12"; a `url:` over a plain column has no records and its values label themselves. `min_chars:` and `text:` pass through too; the write-side options (`create:`, `create_name:`, `reorder:`) deliberately don't — a filter picks among values that already exist.
+**Remote options.** `url:` fetches the options from an endpoint as the user types instead of rendering a collection — such a filter is always a combobox (nothing to render or count). Give it as a callable (`-> { user_options_path }`) so it resolves per request in the view, where route helpers exist. The endpoint is an ordinary host-app action including `Layered::Ui::ComboboxOptions` and returning `l_ui_combobox_options(scope, label:, search:)` — the gem never routes it, so it's authorised however any index is. Since the browser has no collection to look a label up in, an active remote filter's values are labelled server-side from the records (same `name`/`title`/`label`/`email` fallbacks), so the tag reads "User: Alice" not "User: 12"; a `url:` over a plain column has no records and its values label themselves. The label lookup is confined to records the resource's `scope(controller)` references (via the foreign key), so a hand-edited id outside it - e.g. another tenant's user - labels itself instead of leaking a name; the cost is that an in-scope option with no matching records also shows its raw id. `min_chars:` and `text:` pass through too; the write-side options (`create:`, `create_name:`, `reorder:`) deliberately don't — a filter picks among values that already exist.
 
 **The blank a combobox posts.** `l_ui_combobox` emits a leading blank hidden input so clearing every token submits an empty collection rather than omitting the key. Ransack prunes blanks from an `_in` array itself, and `layered_filter_query_params` prunes them too — an array left with nothing becomes an explicit `""`, the same shape the Clear link writes, so the tag reads as inactive *and* a `default:` doesn't immediately re-apply.
 

data/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 All notable changes to this project will be documented in this file. This project follows [Semantic Versioning](https://semver.org/).
 
+## [0.3.1] - 2026-10-04
+
+### Security
+
+- A remote (`url:`) `belongs_to` filter no longer labels records outside the resource's `scope`. Its current values come from the query string, and the labels for the tag and combobox tokens were looked up with an unscoped `klass.where(id: ...)`, so hand-editing the id (`?q[user_id_in][]=`) revealed the name or e-mail of any record, including another tenant's. The lookup now only reads records the resource's `scope(controller)` references through the foreign key. Any other value shows its raw id instead.
+
 ## [0.3.0] - 2026-09-21
 
 ### Changed

data/README.md

@@ -564,7 +564,7 @@ end
 
 A remote combobox has no collection in the browser to look a label up in, so an active filter's current values are labelled server-side from the records themselves (the same `name`/`title`/`label`/`email` fallbacks) — the tag reads "User: Alice", not "User: 12". A `url:` on a plain column has no records to read, so its values label themselves.
 
-> **Label lookups are not scoped.** Whatever scoping the `url:` endpoint applies covers the options it *serves*; it does not cover the labels. Current values arrive in the query string, and the gem labels them with an unscoped `klass.where(id: ...)` — so hand-editing `?q[user_id_in][]=` to an id outside the endpoint's scope still renders that record's label in the tag and the combobox token. This is the same position a `belongs_to` filter's default `klass.all` options take, and it discloses one label at a time; treat it as a reason not to rely on a filter's option scoping to keep an association's names or e-mail addresses private.
+Current values arrive in the query string, so they can be hand-edited to any id — and the gem can't see whatever scoping the `url:` endpoint applies. Labels are therefore only read for records the resource's own `scope` references (users with a post the viewer can see, say); any other value labels itself. A guessed `?q[user_id_in][]=` for another tenant's user shows "User: 42", not their name. The flip side is that a value from the endpoint with no matching records in scope also shows its id, next to an empty table. (A `belongs_to` filter *without* `url:` renders `klass.all` as its options — pass a scoped `collection:` if those labels are private.)
 
 `min_chars:` and `text:` pass through to `l_ui_combobox` alongside `url:`. The write-side combobox options (`create:`, `create_name:`, `reorder:`) don't: a filter picks among values that already exist.
 

data/app/helpers/layered/resource/filters_helper.rb

@@ -286,15 +286,23 @@ module Layered
 
       # Value => label for the filter's currently-set values. A remote filter
       # has no collection to read them from, so an association's are looked up
-      # by id; anything else (a remote filter over a plain column) resolves to
+      # by key; anything else (a remote filter over a plain column) resolves to
       # nothing and the value stands in for its own label.
+      #
+      # The values come straight from the query string, and the gem can't see
+      # whatever scoping the `url:` endpoint applies, so the lookup is confined
+      # to records the resource's own `scope` references: a hand-edited id for,
+      # say, another tenant's user labels itself rather than disclosing that
+      # user's name.
       def layered_filter_option_labels(filter, values)
         if filter[:url].present?
           reflection = filter[:reflection]
           return {} if reflection.nil?
 
-          reflection.klass.where(id: values)
-                    .to_h { |record| [record.id.to_s, layered_filter_record_label(record)] }
+          primary_key = reflection.association_primary_key
+          referenced = @resource.scope(controller).unscope(:order).select(reflection.foreign_key)
+          reflection.klass.where(primary_key => values).where(primary_key => referenced)
+                    .to_h { |record| [record.public_send(primary_key).to_s, layered_filter_record_label(record)] }
         else
           layered_filter_collection(filter).to_h { |label, value| [value, label] }
         end

data/lib/layered/resource/version.rb

@@ -1,5 +1,5 @@
 module Layered
   module Resource
-    VERSION = "0.3.0"
+    VERSION = "0.3.1"
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: layered-resource-rails
 version: !ruby/object:Gem::Version
-  version: 0.3.0
+  version: 0.3.1
 platform: ruby
 authors:
 - layered.ai
@@ -288,7 +288,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 4.0.6
+rubygems_version: 3.6.9
 specification_version: 4
 summary: Convention-over-configuration CRUD for Rails 8+ with Ransack and Pagy built
   in.