Production engineering
using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Threading;
using System.Threading.Tasks;
var origins=new HashSet<string>(new[]{"https://client.example"},StringComparer.Ordinal); Console.WriteLine("browser allowed:"+origins.Contains("https://client.example")); Console.WriteLine("browser allowed:"+origins.Contains("https://other.example")); Console.WriteLine("server authenticated:"+false);
Reveal answer and reasoning
The output lines, in order, are “browser allowed:True”; “browser allowed:False”; “server authenticated:False”. The portable .NET9 console program places https://client.example in an ordinal HashSet and performs two membership tests. The configured origin produces browser allowed:True, the other origin produces browser allowed:False, and the separately supplied authentication flag prints server authenticated:False. These are ordinary set and Boolean operations over fixed strings. The program does not implement browser same-origin enforcement, preflight parsing or any authentication handler.
The exact string comparison also should not be expanded into a complete URL-origin parser. It is a small domain observation supporting the separation of sharing policy from identity in the external experiment.
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.
What a strong answer covers
- Exact output: browser allowed:True | browser allowed:False | server authenticated:False
- The portable .NET9 console program places https://client.example in an ordinal HashSet and performs two membership tests.
- 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.