How can I password-protect my /sidekiq route (i.e. require authentication for the Sidekiq::Web tool)? How can I password-protect my /sidekiq route (i.e. require authentication for the Sidekiq::Web tool)? ruby ruby

How can I password-protect my /sidekiq route (i.e. require authentication for the Sidekiq::Web tool)?


Put the following into your sidekiq initializer

require 'sidekiq'require 'sidekiq/web'Sidekiq::Web.use(Rack::Auth::Basic) do |user, password|  # Protect against timing attacks:  # - See https://codahale.com/a-lesson-in-timing-attacks/  # - See https://thisdata.com/blog/timing-attacks-against-string-comparison/  # - Use & (do not use &&) so that it doesn't short circuit.  # - Use digests to stop length information leaking  Rack::Utils.secure_compare(::Digest::SHA256.hexdigest(user), ::Digest::SHA256.hexdigest(ENV["SIDEKIQ_USER"])) &  Rack::Utils.secure_compare(::Digest::SHA256.hexdigest(password), ::Digest::SHA256.hexdigest(ENV["SIDEKIQ_PASSWORD"]))end

And in the routes file:

authenticate :user do  mount Sidekiq::Web => '/sidekiq'end


Sorry to late to the party, but Sidekiq's wiki recommends the following for Devise:

To allow any authenticated User:

# config/routes.rbauthenticate :user do  mount Sidekiq::Web => '/sidekiq'end

To restrict access to User.admin?

# config/routes.rbauthenticate :user, lambda { |u| u.admin? } do  mount Sidekiq::Web => '/sidekiq'end

This wiki post also has many other security schemes.

This was tested using Rails 5.1.3, Devise 4.3 and Sidekiq 5.0


See "Security" under https://github.com/mperham/sidekiq/wiki/Monitoring

Sidekiq::Web uses Rack::Protection to protect your application against typical web attacks (such as CSRF, XSS, etc). Rack::Protection would invalidate your session and raise Forbidden error if it finds that your request doesn't satisfy security requirements. One of the possible situations is having your application working behind a reverse proxy and not passing important headers to it (X-Forwarded-For,X-Forwarded-Proto). Such situation and solution could be found in this article and issue #2560...