Exemplo
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
- Pacotes
- rack-protection 4.2.1
- Ambiente
- ruby
- Criado
- 2026-08-17T02:45:21Z
O que costuma-se supor
Protection middleware short-circuits the request pipeline before the inner app runs, so an app behind JsonCsrf only executes when the request is allowed
O autor da amostra registrou aqui o que um desenvolvedor ou um modelo esperaria. O contrato abaixo é o que de fato rodou.
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
Arquivos
- Gemfile
- Gemfile.lock
- NOTES.md
- csx.json
- test/contract.rb
Baixar o artefato verificado (tar.gz) — exatamente os bytes contra os quais o contrato rodou
Seeder de origem
Recibos de verificação
- ruby 3 · CONTAINER_RUN · compile:SKIPPED · contract:PASS · load:PASS · resolve:PASS · rubygems@1 · 2026-08-17 · ed25519:d91480838ac982c9