chore(deps): upgrade omniauth-rails_csrf_protection to 2.0.1

[JSONbored]

Closes #2448

What

Bumps omniauth-rails_csrf_protection from 1.0.2 → 2.0.1. Only Gemfile.lock changes; no application code is modified.

Why

v1.0.2 unconditionally calls include ActiveSupport::Configurable inside TokenVerifier. Rails 8.1 deprecates this usage with a boot-time warning that it will be removed in Rails 8.2, blocking the upgrade path.

v2.0.1 detects the Rails version at load time:

• Rails ≥ 8.1: delegates config to ActionController::Base.config directly — no ActiveSupport::Configurable touched.
• Rails < 8.1: keeps the existing include so older installs are unaffected.

Test plan

• bin/rails test passes (no regressions introduced)
• Boot verified to emit no ActiveSupport::Configurable deprecation
• Sessions and OmniAuth auth flows covered by test/controllers/sessions_controller_test.rb (31 tests, all green)

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (1)

• Gemfile.lock is excluded by !**/*.lock

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0c701035-1373-483b-8c01-1db5a4f10c5c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[jjmata]

One thing worth checking before merging: this is a major version bump (1.0.2 → 2.0.1). The omniauth-rails_csrf_protection gem's 2.x series may have breaking changes around how it hooks into OmniAuth's request phase or how it validates CSRF tokens on the callback. It's worth reviewing the gem's CHANGELOG/release notes to confirm there are no behaviour changes that could affect login flows (OAuth, SAML, API key auth via OmniAuth). If CI exercises the auth flows end-to-end, those tests passing is a good signal; if not, a quick manual smoke-test of at least one OmniAuth-backed sign-in path before merging would be prudent.

---

Generated by Claude Code

[JSONbored]

Thanks @jjmata — reviewed the gem CHANGELOG and our usage; the bump is safe (and actually well-aligned with our stack). No code change needed.

What changed (1.0.2 → 2.0.1):

• 2.0.0 — requires OmniAuth ≥ 2.0 and switches to OmniAuth 2.0's request_validation_phase= hook (instead of the old before_request_phase= shim); the bump was driven by avoiding a Rails 8.1 deprecation (ActiveSupport::Configurable).
• 2.0.1 — fixes config delegation for Rails < 8.1 only.
• No change to the request-phase CSRF semantics — same protection, wired via OmniAuth 2.x's official config point.

Why it's fine for us:

• We're on rails 8.1.3 and omniauth 2.1.3, so both the ≥2.0 requirement and the Rails-8.1 path apply cleanly — this upgrade actually removes a deprecation rather than introducing risk.
• config/initializers/omniauth.rb only registers providers (google_oauth2 / github / openid_connect / saml) and on_failure; it never references before_request_phase/request_validation_phase, so the gem auto-wires the CSRF check and the swap is transparent to our config.

Auth coverage: oauth_basic_test, oauth_mobile_test, and sessions_controller_test run under test_unit, and test_system is end-to-end — all green on this PR. (A real external-provider round-trip obviously can't run in CI, but since the change is mechanism-level rather than semantic, login behavior is unchanged.)