Production engineering
Reveal answer and reasoning
CORS governs how participating browsers share responses across origins. It does not establish who sent a request, grant access to a business resource or prevent a nonbrowser client from reading a deliberately public response. This project therefore exposes public classroom data and reports authenticated=false, while middleware separately decides which Origin receives sharing headers. The allowed origin is fictional header data; the lab sends requests only to the owned loopback server.
Keep the response status, CORS headers and caller identity as three independently observed facts. A missing sharing header is not automatically an application-level403 or evidence that the handler never executed.
Program.cs registers a named classroom policy permitting the configured origin, GET and POST methods, and Content-Type as a requested header. UseCors applies it to the actual request pipeline. /cors/data returns public JSON and observes HttpContext.User independently. The test sends OPTIONS with Origin and Access-Control-Request-Method, then compares actual GET responses for allowed and other origins. Preflight permission describes the CORS policy; it does not create a POST route where only GET is mapped.
Inspect the applicable Access-Control headers as well as status, and do not confuse a policy capability with endpoint routing or business authorization.
What a strong answer covers
- CORS governs how participating browsers share responses across origins.
- Program.cs registers a named classroom policy permitting the configured origin, GET and POST methods, and Content-Type as a requested header.
- Origin is request metadata, not a reliable person or tenant identifier.
Common pitfall
Origin is request metadata, not a reliable person or tenant identifier. A nonbrowser client can supply it directly, and some cross-origin requests can reach a server even when a browser later hides the response from script. This fixture configures no authenticated business action or credentialed cross-origin cookie workflow. Allowing an origin does not make an otherwise unsafe operation safe, and denying sharing does not replace antiforgery checks where ambient credentials are used. A production design must also decide credential handling, allowed methods, request headers, exposed response headers and resource-specific authorization without folding them into one Boolean.
Follow-up questions
- Why does permitting POST in CORS policy not mean /cors/data has a POST handler?
- Which CORS headers concern permission to send a request, and which concern script access to a response?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.