Repository navigation
CSP compatibility: inline styles/scripts and event handlers require disabling strict Content Security Policy #36
Description
Hi,
First: thanks for the gem. I tested solid_queue_monitor as a possible replacement for mission_control-jobs in a Rails app, and the feature set looks very good.
I ran into one integration issue: the current UI is not compatible with a strict Content Security Policy.
My app uses a CSP similar to:
config.content_security_policy do |policy|
policy.default_src :self
policy.font_src :self
policy.img_src :self, :data
policy.object_src :none
policy.script_src :self
policy.style_src :self
end
config.content_security_policy_nonce_generator = ->(request) { request.session.id.to_s }
config.content_security_policy_nonce_directives = ["script-src", "style-src"]With that setup, solid_queue_monitor loads but the UI is broken because the browser blocks:
- inline
<style>tags - inline
<script>tags - inline event handlers like
onclick/onchange - runtime inline style mutations via
element.style.*
From what I saw locally, this comes from the current self-contained rendering approach:
- CSS generated inline
- JS generated inline
- some presenters using inline handlers
- some JS toggling visibility/opacity with direct inline styles
My current workaround is to disable CSP only for the monitor controller:
Rails.application.config.to_prepare do
SolidQueueMonitor::ApplicationController.content_security_policy false
endThis works for evaluation and internal tooling, but it weakens defense in depth for that interface, so it is not ideal as a long-term solution.
Would you be open to discussing a CSP-compatible mode or refactor?
Possible directions:
- move CSS to an engine stylesheet asset
- move JS to engine JS assets
- replace inline event handlers with
addEventListener - replace
element.style.*mutations with CSS classes - optionally keep the current self-contained mode as a fallback for API-only / zero-setup installs
I understand why the gem is implemented this way: it makes installation extremely simple and keeps the UI self-contained. But CSP compatibility seems important for production Rails apps with stricter security defaults.
If this direction sounds reasonable, I’d be happy to help narrow down the incompatible pieces more precisely.
Thanks a lot!
Activity
vishaltps commentedon Apr 15, 2026
Hi @yann120 , thanks for the detailed write-up and for evaluating the gem! You're right that strict CSP compatibility matters for production Rails apps, and disabling CSP on the controller isn't a good long-term answer.
Honestly, CSP wasn't on my radar when I designed the gem, my focus was on making it truly drop-in (mount the engine, get a UI, no asset pipeline, no JS/CSS files to manage). That decision is what made everything inline in the first place, and it's also what's now causing the incompatibility you're seeing. Your issue is a good nudge to fix that; I should have considered stricter CSP setups earlier, especially since nonce-based CSP is increasingly the Rails default.
I took a pass through the codebase to map the incompatible pieces. The scope is roughly:
I'm planning to tackle this in two layers so the fix lands quickly without a risky big-bang refactor:
Phase 1: CSP-compatible without moving to assets
Phase 2 (optional): stricter 'self'-only
script_src :self(no nonces) work tooDoes Phase 1 cover your use case? Your snippet uses nonce directives for script-src and style-src, so nonce support should be sufficient, but happy to hear if you need pure 'self' compliance, which would push us to Phase 2 sooner.
Also very happy to accept help narrowing things down if you're up for it. I'll open a tracking PR shortly.
Thanks again!
yann120 commentedon Apr 15, 2026
Hi @vishaltps, thanks for your quick answer and the detailed breakdown, this makes sense.
Yes, Phase 1 should cover my use case. My app already uses nonce-based script-src and style-src, so adding nonces to the remaining inline <script> / <style> tags, removing inline event handlers, and eliminating inline style mutations or attributes in favor of CSS classes should be enough on my side.
I agree with the approach of landing that first before considering a larger asset-based refactor.
I would be happy to help you if you need 🙂
vishaltps commentedon Apr 20, 2026
@yann120 Can you please test the latest version and let me know if you find any issue with the CSP?
yann120 commentedon Apr 20, 2026
Hi @vishaltps, thanks for fixing this so fast!
I checked on local with the gem on the main branch, and it works perfectly after I removed my CSP workaround.
Thank you for fixing that! 👏🏻
vishaltps commentedon Apr 20, 2026
Thanks, closing the issue now.