SluijsensandClaude Sonnet 5
fa389e42ee
Unit 1 of the slpsoftware-api feature (FR-1/FR-2/FR-3): a new Client project in the Clients solution folder, intended to eventually become the deployed API for test.slpsoftware.nl/slpsoftware.nl, hosting the same four modules as SlpModularCms.Api plus a future Offerings module. - Extracts SlpModularCms.Api/Program.cs's hosting-pipeline composition into SlpModularCms.Core.Hosting.CmsHost (ConfigureServices/ConfigurePipeline), shared by both Client projects so they cannot drift apart - Moves StaticContentExtensions.cs + WebsitePlaceholder.html from Api into Core, since CmsHost cannot live in Api but Core cannot depend on Api - Adds SlpModularCms.Api.SlpSoftware with its own isolated local dev database and dev ports (5286/7223, distinct from Api's and Api.Slave's) - Adds SlpModularCms.Api.Tests with WebApplicationFactory-based pipeline regression tests (security headers, health check, SPA fallback, rate limiting), scoped to Api per NFR Design - Adds a frontend dev:slpsoftware pnpm script mirroring dev:slave - Fixes GlobalExceptionHandler logging routine 401s (e.g. an expired/missing refresh token) as unhandled errors -- pre-existing, unrelated to this feature's own scope, found while testing the new instance Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
SlpModularCms.Api
AIDLC Context
Als ontwikkelaar wil ik een modulaire CMS API bouwen. Deze API zal een raamwerk hebben met veelgebruikte functionaliteiten en gebruikersbeheer. Het doel is dat ik deze API kan gebruiken voor klanten om websites en applicaties te bouwen. Elke klant kan andere wensen hebben, maar per branch of type website zullen er altijd functionaliteiten zijn die hetzelfde zijn. Extra functionaliteiten moeten dus met modules worden geïmplementeerd, zodat ze eenvoudig kunnen worden toegevoegd of verwijderd. Om mijzelf in te dekken wil ik iets inbouwen zodat ik modules op afstand kan uitzetten of dat ik de CMS kan blokkeren in het geval dat een klant zich niet aan de afspraak houd zoals een betaling niet doen of andere dingen.
Dit betekent dat er standaard iets moet worden ingebouwd dat de API een controle uitvoert met een call naar een zogenoemde "master"-API om te controleren of alles nog beschikbaar is. Misschien moet het zelfs bij de master worden opgeslagen in de database én bij de client zelf. De "master"-API moet een module krijgen waarin alles wordt opgeslagen en waarin de API kan controleren of de klant nog toegang heeft tot de CMS, maar deze module mag later pas. Voor de MVP wil ik het raamwerk hebben met authenticatie, authorisatie en gebruikersbeheer voor gebruikers.
Zodra dat staat kan er gekeken worden naar een simpele eerste module.
Daarna kan de module voor de "master"-API worden geïmplementeerd waar ook de connectie tussen "master"- en client-API moet worden bedacht. Hier kan later over worden nagedacht, maar den kaan iets als client-secret pairs.