Production engineering
Reveal answer and reasoning
Antiforgery validation checks a request token against the framework's relevant context, including its cookie. It addresses cross-site request forgery rather than authenticating a person or making a command single-use. The external fixture deliberately has an anonymous classroom counter, uses actual ASP.NET antiforgery services and increments only after validation succeeds. A valid pair can be submitted again and increment again. That reuse is expected behavior, not a cryptographic failure.
The key provider is ephemeral so its protected payloads cannot survive replacement of that provider instance; the development process restart test therefore has a different boundary from ordinary repeated valid requests.
Program.cs configures the X-CSRF-TOKEN header and a named classroom cookie, registers an ephemeral Data Protection provider and permits that cookie on the owned plain-HTTP development connection. /antiforgery/token calls GetAndStoreTokens and returns the request token while the response stores its paired cookie. /antiforgery/submit calls ValidateRequestAsync before incrementing submissions. Validation exceptions return400 and do not reach that increment. The actual repeated-valid-pair test can take the counter from one to two; missing or mismatched context leaves it unchanged. /antiforgery/count exposes that postcondition separately from response status, making handler execution directly observable in the fixture.
What a strong answer covers
- Antiforgery validation checks a request token against the framework's relevant context, including its cookie.
- Program.cs configures the X-CSRF-TOKEN header and a named classroom cookie, registers an ephemeral Data Protection provider and permits that cookie on the owned plain-HTTP development connection.
- The cookie is explicitly nonsecure for this Development-only loopback exercise, and there is no authenticated business permission.
Common pitfall
The cookie is explicitly nonsecure for this Development-only loopback exercise, and there is no authenticated business permission. Those choices must not be presented as production cookie guidance. A successful token check also does not consume a nonce or create a request receipt, so repeating an authorized business command would need its own semantics. Restarting the ephemeral provider invalidates old pairs rather than preserving a shared key ring across replicas. A deployed application must define TLS termination, persistent or shared key ownership, identity binding and authorization separately. No one response or token comparison establishes all those properties together.
Follow-up questions
- How would sharing Data Protection keys across replicas differ from using an idempotency key for one business command?
- Why should a repeated valid token increase the classroom counter twice even though a duplicate business command might replay only once?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.