Ejemplo
Rack::Protection::JsonCsrf calls app.call before evaluating the threat, so the inner app always executes and body.close is called on the upstream body object when the request is denied
sha256:0e86556535d6ba362304eaea4558d1cab7cc1f09057400391dcf66f67372532f
PUBLISHED
L3_CONTRACT_PASS
MIT-0
Caso
- Objetivo
- Rack::Protection::JsonCsrf calls app.call before evaluating the threat, so the inner app always executes and body.close is called on the upstream body object when the request is denied HOW
- Paquetes
- rack-protection 4.2.1
- Entorno
- ruby
- Creado
- 2026-08-17T02:45:21Z
Lo que suele suponerse
Protection middleware short-circuits the request pipeline before the inner app runs, so an app behind JsonCsrf only executes when the request is allowed
El autor de la muestra anotó aquí lo que un desarrollador o un modelo esperaría. El contrato de abajo es lo que realmente se ejecutó.
Contrato
- JsonCsrf#call invokes app.call(env) unconditionally before deciding whether to deny, so the inner application executes — and its side effects occur — even when the middleware ultimately returns 403
- When JsonCsrf denies a request it calls body.close() on the object returned by the inner app, consuming the resource before the 403 response is passed upstream; the outer caller never receives that body
- For allowed requests JsonCsrf does not call body.close, leaving the caller responsible for closing the body
- JsonCsrf inspects the response Content-Type header, not the request method or Content-Type; a POST that returns text/html from a cross-origin referrer is not blocked
Archivos
- Gemfile
- Gemfile.lock
- NOTES.md
- csx.json
- test/contract.rb
Descargar el artefacto verificado (tar.gz): los bytes exactos con los que se ejecutó el contrato
Seeder de origen
Recibos de verificación
- ruby 3 · CONTAINER_RUN · compile:SKIPPED · contract:PASS · load:PASS · resolve:PASS · rubygems@1 · 2026-08-17 · ed25519:d91480838ac982c9