feat: opt-in CSRF protection for dashboard actions

[TakuroOnoda]

Summary

Adds opt-in CSRF protection for the dashboard's destructive POST actions (retry / discard / pause / resume / execute / reject / remove / prune), gated behind a new csrf_protection_enabled config (default false).

Why opt-in (default off)

The gem renders raw HTML forms and doesn't assume a session store (it supports API-only apps).
Rails' CSRF tokens require a session, so enabling it by default would break session-less hosts.
Off by default = fully backward compatible.

Changes

• New SolidQueueMonitor.csrf_protection_enabled (default false).
• skip_before_action :verify_authenticity_token is now skipped only when protection is disabled. When enabled, unverified POSTs return 422; safe methods pass through.
• Destructive forms embed a token via a new csrf_token_field helper; the layout adds csrf_meta_tags. Both render nothing when disabled.
• Fixed the failed-jobs bulk submit to preserve the token (it previously stripped all hidden inputs).
• README / CHANGELOG / initializer template updated.

Enable

SolidQueueMonitor.setup do |config|
  config.csrf_protection_enabled = true
end

Requires a session store, same-origin mount, and a non-api_only app.

---

Thanks for building and maintaining such a clean, lightweight gem.
I've tried to keep this change minimal and fully backward compatible.
Hope it's a useful addition, and I'd love to hear your thoughts. 🙂

[TakuroOnoda]

Hi @vishaltps 👋 Whenever you get a chance, I'd love a review on this PR.
Happy to tweak anything to fit the project's direction.
Thanks!

[vishaltps]

Nice work on this, tested it locally against a session-backed app and the opt-in flow behaves exactly as described. 👍

One small, purely cosmetic note: the two helpers are both conditional on csrf_protection_enabled, but only one carries the _if_enabled suffix- csrf_meta_tags_if_enabled vs csrf_token_field. Would be nice to unify the naming so the pair reads consistently. Either direction works:

• drop the suffix → csrf_meta_tags_if_enabled becomes csrf_meta_tags (but that would shadow Rails' built-in helper, so probably not this one), or
• keep both explicit → e.g. csrf_token_field → csrf_token_field_if_enabled.

Given the shadowing concern, leaning toward making both explicit feels cleanest. Totally non-blocking - just a readability nit.

[TakuroOnoda]

@vishaltps
renamed csrf_token_field to csrf_token_field_if_enabled so the pair reads consistently.
b6eae16

Thanks for the review!

[vishaltps]

This shipped in v2.2.0 🎉

• 💎 RubyGems: https://rubygems.org/gems/solid_queue_monitor/versions/2.2.0
• 🏷️ Release notes: https://github.com/vishaltps/solid_queue_monitor/releases/tag/v2.2.0

Thanks for the thoughtful contribution, @TakuroOnoda the opt-in design and the attention to the trickier edges (the cross-origin asset guard and preserving the token through the bulk submit) made this a clean one to merge. Users can enable it with config.csrf_protection_enabled = true. 🙏