Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

v6.2 auto-load prevents specific middleware placement

Aperta
  • Qualcosa non va?
#459 16 commenti 3 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
ruby
Ambito
backend

Direzione di ricerca

Start with lib/rack/attack.rb and the Railtie auto-load path described in the issue. Compare the proposed configuration option with the alternate require entry point, and review the behavior referenced in #457 and #442. Done means an advanced application can prevent automatic middleware insertion while the default behavior remains unchanged and duplicate loading is avoided.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: middleware type: feature request

Upon upgrading to 6.2.1 (from 6.1.0), we end up with Rack::Attack twice in our middleware stack.

Actual behavior:

$ rails middleware
...
use Rack::Head
use Rack::ConditionalGet
use Authenticator::PartOne
use Rack::Attack     # <--- our intended Rack::Attack instance
use Authenticator::PartTwo
use Rack::Attack     # <--- the duplicate now added in 6.2 that we don't want
run OurApp::Application.routes

Expected behavior:

$ rails middleware
...
use Authenticator::PartOne
use Rack::Attack     # <--- our intended Rack::Attack instance
use Authenticator::PartTwo
run OurApp::Application.routes

As you can see, our specific case involves a two-phase authentication middleware stack that is specifically designed to surround Rack::Attack, so we cannot move Rack::Attack to the end of the stack, where it installs itself by default.

I see that 6.2.1 was intended to turn the second instance into a no-op, but we'd much prefer avoiding the double load to begin with.

Given the need to configure Rack::Attack anyway, one could argue against auto-loading the middleware. However, I'd like to instead propose a couple of ways to allow disabling the auto-load for advanced configurations like ours, while preserving it as the new default behavior.

  1. Add a config option Rack::Attack.auto_load = true. Defaults to true. When false, the initializer would skip the auto-load.

  2. Rework the gem's default require by moving most of lib/rack/attack.rb into a new file. Replace the original file with nothing but:

require 'rack/attack/<newfile>'
require 'rack/attack/railtie' if defined?(::Rails)

This would allow advanced configurations to set the Gemfile as

gem 'rack-attack', require: 'rack/attack/<newfile>'

which would implicitly disable the auto-load railtie.

Either way preserves your new default while adding a path for more specific configuration for those of us with apps with advanced middleware configurations.

Are you open to either of the above solutions? If at least one is acceptable, I'm happy to prepare a PR accordingly if that'd be helpful.

FWIW, either of the above would also allow the removal of the already-called condition (return ... if ... env["rack.attack.called"]) added in #457, which I think may break/prevent PR #442.

Lingua principale
Ruby
Stelle
5.8k
Fork
347
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rack/rack-attack

Tutte le issue di rack/rack-attack

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.