SluijsensandClaude Opus 5
29a93ef873
Prepares the single-host layout for deployment. The customer's public website moves from wwwroot/ to wwwroot/web/, so a CMS deploy can no longer overwrite content it does not own: with the website in its own directory, the release directory can be swapped without touching it. Each front-end gets its own file provider, and both tolerate a missing directory at startup — a fresh deployment has no website until a separate workspace deploys one, and the CMS must still serve /admin and the API. When the website's index.html is absent, an embedded placeholder is served instead of a 404, which also doubles as proof the CMS itself is running. The placeholder is embedded in the assembly rather than shipped into wwwroot/web/, because that directory is owned and overwritten by the website workspace. Adds GET /health for uptime monitoring. It reports infrastructure liveness only and is deliberately NOT the same thing as /api/v1/Availability/status or /api/v1/System/capabilities: those are CMS domain state that also serve the master/slave protocol. A healthy instance can be switched off by design, and a switched-on instance can be unhealthy, so conflating them would alert on business state and stay silent on real outages. /health is on the availability gate's bypass list for the same reason. Fixes a real defect in the gate's admin bypass. It parsed the bearer token with ReadJwtToken, which reads claims without verifying the signature, so an unauthenticated caller could forge an unsigned token carrying an Owner role claim and bypass the gate that suspends a customer's site. Protected endpoints still rejected them, so nothing leaked — but the gate itself was bypassable. The token is now fully validated against the same parameters as the bearer scheme, resolved from one shared source so the two cannot drift apart. Host wiring for these changes lands with the data-durability commit, since both units touch the same lines of Program.cs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HHoJpxYXzHACSQguHrC5fw
3.9 KiB
Functional Design Questions — U1 Hosting & Serving
Vul je keuze in achter elke [Answer]:-tag. Kies de laatste optie (Anders) als niets past.
Question 1 — Hoe implementeren we de FR-24-fix?
Context: dit is het conflict uit § 5.2 van het applicatieontwerp. AvailabilityMiddleware wordt geïnstalleerd door orchestrator.UseModules(app), wat vóór app.UseAuthentication() staat. Op dat moment is HttpContext.User dus nog leeg — de middleware kan niet simpelweg de al geauthenticeerde gebruiker uitlezen.
Dat is precies waarom de huidige code ReadJwtToken gebruikt: die werkt zonder authenticatie, maar valideert de handtekening niet.
A) Valideer het token in de middleware zelf, met dezelfde TokenValidationParameters als het bearer-schema — die parameters worden dan uit één gedeelde bron gehaald in plaats van gekopieerd. Afgebakend: alleen deze middleware verandert
B) Verplaats app.UseAuthentication() naar vóór orchestrator.UseModules(app), zodat de middleware HttpContext.User kan gebruiken. Kleinere wijziging in regels code, maar verandert de pipeline voor élke module — ook toekomstige
C) Laat de gate-bypass helemaal vervallen en gebruik in plaats daarvan een vaste bypass-prefix voor de admin-endpoints — geen tokenlogica meer in de middleware
X) Anders (beschrijf hieronder na de Answer:-tag)
Question 2 — Wat gebeurt er als wwwroot/web/ niet bestaat?
Context: bij een verse deploy is er nog geen publieke website — die komt uit een andere workspace. De CMS moet dan gewoon starten en /admin en /api/v1 blijven serveren. Maar wat krijgt een bezoeker op / te zien?
A) Een standaard 404 — er is niets, dus dat is het eerlijke antwoord
B) Een ingebouwde placeholderpagina met de melding dat er nog geen website is geplaatst, plus een verwijzing naar /admin — handig bij een verse installatie, en meteen bewijs dat de CMS draait
C) Een redirect naar /admin — de enige zinvolle bestemming zolang er geen website is
X) Anders (beschrijf hieronder na de Answer:-tag)
Question 3 — Moet de applicatie hierover iets loggen bij het opstarten?
Context: een ontbrekende wwwroot/web/ is bij een verse installatie normaal, maar op een draaiende productieomgeving zou het betekenen dat de website van de klant verdwenen is — precies het scenario dat we met de release-opzet proberen te voorkomen.
A) Waarschuwing bij opstarten als de map ontbreekt, met het verwachte pad erbij — zichtbaar in Sentry en de console, zonder het opstarten te blokkeren B) Alleen een informatieregel — het is een normale toestand bij een verse installatie C) Niets loggen — de 404 of placeholder zegt genoeg X) Anders (beschrijf hieronder na de Answer:-tag)
Question 4 — Wat geeft /health terug?
Context: het framework-standaardantwoord is platte tekst Healthy met status 200, of Unhealthy met 503. UptimeRobot heeft aan de statuscode genoeg.
A) De standaard platte tekst — minimaal, snel, en geeft niets prijs over de applicatie B) Een klein JSON-object met status en tijdstip — iets makkelijker te lezen bij handmatig controleren C) JSON met status, tijdstip, versie en geladen modules — dan zie je meteen of alle modules geladen zijn na een deploy X) Anders (beschrijf hieronder na de Answer:-tag)
Question 5 — Moet /admin zonder slash doorverwijzen naar /admin/?
Context: de admin-SPA is gebouwd met base: '/admin/'. Als iemand /admin intypt zonder afsluitende slash, worden relatieve verwijzingen in de pagina één niveau te hoog opgelost, waardoor de SPA stuk kan gaan. Een redirect naar /admin/ voorkomt dat.
A) Ja, redirect /admin naar /admin/ — voorkomt een categorie fouten die lastig te herkennen is
B) Nee, laat de SPA-fallback het afhandelen — minder magie in de pipeline
X) Anders (beschrijf hieronder na de Answer:-tag)