You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a2c78ae
Browse filesBrowse the repository at this point in the historyBrowse files
A nested id_token or refresh_token is always a secret, so only the generic callback names (code, state, session_state, nonce) need the top-level limit that keeps host attributes like data.attributes.state visible.
Co-Authored-By: Clanker
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,4 +2,4 @@
2
2
3
3
## Unreleased
4
4
5
-
- Fix: the OIDC `filter_parameters`entry now matches only the exact top-level keys `code`, `code_verifier`, `state`, `session_state`, `nonce`, `id_token`, `access_token` and `refresh_token`, so host params such as `code_id`, `state_eq` or `order[state]` are no longer filtered from logs. If you relied on the old substring match to hide params like `invite_code` or `reset_code`, add them to your own `filter_parameters`.
5
+
- Fix: the OIDC `filter_parameters`entries now match exact keys instead of substrings. `code_verifier`, `id_token`, `access_token` and `refresh_token` are filtered at any depth; `code`, `state`, `session_state` and `nonce` only at the top level. Host params such as `code_id`, `state_eq` or `order[state]` are no longer filtered from logs. If you relied on the old substring match to hide params like `invite_code` or `reset_code`, add them to your own `filter_parameters`.
Copy file name to clipboardExpand all lines: README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,7 +83,7 @@ The gem's Rails engine handles several things so host apps don't have to:
83
83
***Login view override** — the engine prepends an SSO-only login page (no email/password fields) to the sessions controller's view path. If your host app ships its own `app/views/active_admin/devise/sessions/new.html.erb`, the gem detects it and backs off — your view wins.
84
84
***Session routes** — the engine mounts `GET /admin/login` (renders the SSO landing page) and `DELETE /admin/logout` under `devise_scope`, with the scope name derived from `config.admin_user_class`. Devise normally generates session routes as a side effect of `:database_authenticatable`; without that module the route helpers would not exist and ActiveAdmin's login redirect would 404.
85
85
***Path prefix** — the engine registers the strategy with `path_prefix: '/admin/auth'` so the middleware intercepts requests under ActiveAdmin's mount point, and sets `Devise.omniauth_path_prefix` to the prefix Devise declares its routes with. Compatible with Rails 7.2+ and Rails 8's lazy route loading.
86
-
***Parameter filtering** — top-level `code`, `code_verifier`, `state`, `session_state`, `nonce`, `id_token`, `access_token` and `refresh_token` params are added to `Rails.application.config.filter_parameters`. Only those exact top-level keys are matched, so host params like `code_id`, `state_eq` or `order[state]` stay visible.
86
+
***Parameter filtering** — the OIDC keys are added to `Rails.application.config.filter_parameters` as exact-key matches. `code_verifier`, `id_token`, `access_token` and `refresh_token` are filtered at any depth. The generic `code`, `state`, `session_state` and `nonce`are filtered only as top-level params, where the callback sends them, so host params like `code_id`, `state_eq` or `order[state]` stay visible.
87
87
88
88
## Configuration
89
89
@@ -410,7 +410,7 @@ The gem also adds a unique `(provider, uid)` partial index in its own install mi
410
410
411
411
### What's filtered from logs
412
412
413
-
The engine adds the top-level OIDC callback keys (`code`, `code_verifier`, `state`, `session_state`, `nonce`, `id_token`, `access_token`, `refresh_token`) to `Rails.application.config.filter_parameters`, so a mid-callback crash can't dump them into production logs. Only those exact top-level keys are matched:`code_id`, `state_eq` and nested params like `order[state]` are not filtered. Your own `filter_parameters` entries are preserved.
413
+
The engine adds the OIDC keys to `Rails.application.config.filter_parameters`, so a mid-callback crash can't dump them into production logs. Keys are matched exactly. `code_verifier`, `id_token`, `access_token` and `refresh_token` are filtered at any depth; `code`, `state`, `session_state` and `nonce` only as top-level params. So`code_id`, `state_eq` and nested params like `order[state]` are not filtered. Your own `filter_parameters` entries are preserved.
0 commit comments