Initial commit with inital CMS
This commit is contained in:
+30
@@ -0,0 +1,30 @@
|
||||
# Business Rules — Unit 04: API Shell & Integration
|
||||
|
||||
Dit document beschrijft de integratie-regels en de orkestratie van de modules.
|
||||
|
||||
## 1. Module Discovery (BR-SHELL-01)
|
||||
|
||||
- **Scanning**: De API Shell scant bij het opstarten naar alle geladen assemblies die voldoen aan het patroon `SlpModularCms.Modules.*`.
|
||||
- **Interface**: Alleen klassen die `IModule` implementeren worden geregistreerd.
|
||||
- **Validatie**: Indien een module niet voldoet aan de eisen (bijv. ontbrekende naam of versie), wordt dit gelogd als een fout en wordt de module niet geladen.
|
||||
|
||||
## 2. Dependency Injection & Pipeline (BR-SHELL-02)
|
||||
|
||||
- **Gecentraliseerde Registratie**: De `ModuleOrchestrator` roept `RegisterServices` aan op alle gevonden modules voordat de applicatie start.
|
||||
- **Middleware Pipeline**: De `ModuleOrchestrator` roept `UseModule` aan om modules de kans te geven hun middleware te registreren in de HTTP pipeline.
|
||||
- **Core First**: Core services (Identity, Logging) worden altijd geregistreerd vóórdat de modules aan de beurt zijn.
|
||||
|
||||
## 3. API Versioning & Routing (BR-SHELL-03)
|
||||
|
||||
- **Gecentraliseerde Prefix**: Alle API endpoints krijgen de prefix `/api/v1/`.
|
||||
- **Afdwingen**: Dit wordt globaal geconfigureerd in de Shell zodat individuele modules hier geen rekening mee hoeven te houden in hun route attributen.
|
||||
|
||||
## 4. Swagger Documentatie (BR-SHELL-04)
|
||||
|
||||
- **Tagging**: De Shell groepeert endpoints automatisch per module op basis van de module naam die in de `IModule` interface is opgegeven.
|
||||
- **Security**: Swagger wordt geconfigureerd om JWT Bearer tokens te ondersteunen voor het testen van beveiligde endpoints.
|
||||
|
||||
## 5. Cross-Module Communicatie (BR-SHELL-05)
|
||||
|
||||
- **Ontkoppeling**: Modules communiceren niet direct met elkaar via projectreferenties.
|
||||
- **Interfaces**: Communicatie verloopt uitsluitend via interfaces die gedefinieerd zijn in `SlpModularCms.Core`.
|
||||
+47
@@ -0,0 +1,47 @@
|
||||
# Business Logic Model — Unit 04: API Shell & Integration
|
||||
|
||||
Dit document beschrijft de startup flow en de orkestratie logica van de shell.
|
||||
|
||||
## 1. Startup Orkestratie Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Program as Program.cs
|
||||
participant Orc as ModuleOrchestrator
|
||||
participant Core as Core Services
|
||||
participant Mod as Modules (IModule)
|
||||
|
||||
Program->>Orc: DiscoverModules()
|
||||
Orc-->>Program: List<IModule>
|
||||
|
||||
Program->>Core: RegisterCoreServices(Identity, DB, JWT)
|
||||
|
||||
loop Per Module
|
||||
Program->>Mod: RegisterServices(IServiceCollection)
|
||||
end
|
||||
|
||||
Program->>Program: Build App
|
||||
|
||||
Program->>Program: UseExceptionHandler()
|
||||
|
||||
loop Per Module
|
||||
Program->>Mod: UseModule(IApplicationBuilder)
|
||||
end
|
||||
|
||||
Program->>Program: UseAuthentication/Authorization()
|
||||
Program->>Program: MapControllers()
|
||||
Program->>Program: Run()
|
||||
```
|
||||
|
||||
## 2. API Versioning Logic
|
||||
|
||||
De versioning wordt toegepast via een globale `RoutePrefix` of door gebruik te maken van de `Microsoft.AspNetCore.Mvc.Versioning` library.
|
||||
- **Base Path**: `/api/v1`
|
||||
- **Fallback**: Verzoeken zonder versie-indicator in het pad worden standaard naar v1 gerouteerd.
|
||||
|
||||
## 3. Dynamische Swagger Groepering
|
||||
|
||||
1. Swagger scan de controllers van alle geladen assemblies.
|
||||
2. Voor elke controller wordt gekeken naar de assembly waarin deze is gedefinieerd.
|
||||
3. Indien de assembly toebehoort aan een module (bijv. `SlpModularCms.Modules.Availability`), wordt de module naam als 'Tag' toegevoegd aan alle endpoints van die controller.
|
||||
4. Swagger UI toont de endpoints gegroepeerd onder deze tags.
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
# Orchestration Design — Unit 04: API Shell & Integration
|
||||
|
||||
Dit document beschrijft de technische implementatie van de module orkestratie.
|
||||
|
||||
## 1. ModuleOrchestrator
|
||||
|
||||
De orchestrator is verantwoordelijk voor de lifecycle van modules.
|
||||
|
||||
- **Discovery**:
|
||||
- Gebruikt Reflection om alle typen in geladen assemblies te scannen.
|
||||
- Filtert op klassen die `IModule` implementeren en niet abstract zijn.
|
||||
- **Error Handling (Soft Fail)**:
|
||||
- Bij het laden van een module wordt de aanroep van `RegisterServices` en `UseModule` omgeven door een `try-catch` blok.
|
||||
- Fouten worden gelogd als `Error` naar de `ILogger`.
|
||||
- De orkestratie gaat door naar de volgende module om de algehele beschikbaarheid te maximaliseren.
|
||||
|
||||
## 2. Route Conventions
|
||||
|
||||
De `/api/v1/` prefix wordt afgedwongen via een custom `IApplicationModelConvention`:
|
||||
|
||||
```csharp
|
||||
public class ApiPrefixConvention : IApplicationModelConvention
|
||||
{
|
||||
public void Apply(ApplicationModel application)
|
||||
{
|
||||
foreach (var controller in application.Controllers)
|
||||
{
|
||||
foreach (var selector in controller.Selectors)
|
||||
{
|
||||
// Voeg prefix toe aan bestaande route
|
||||
var routePrefix = new AttributeRouteModel(new RouteAttribute("api/v1"));
|
||||
selector.AttributeRouteModel = selector.AttributeRouteModel != null
|
||||
? AttributeRouteModel.CombineAttributeRouteModels(routePrefix, selector.AttributeRouteModel)
|
||||
: routePrefix;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 3. Swagger & Security Design
|
||||
|
||||
Swagger wordt geconfigureerd in `Program.cs`:
|
||||
|
||||
- **Groepering**: Gebruik van `DocInclusionPredicate` om controllers te taggen op basis van hun assembly prefix (bijv. `Availability`).
|
||||
- **JWT Support**:
|
||||
- `AddSecurityDefinition("Bearer", ...)`
|
||||
- `AddSecurityRequirement(...)`
|
||||
- **Pad**: Beschikbaar op `/swagger` via `app.UseSwaggerUI(c => c.RoutePrefix = "swagger")`.
|
||||
|
||||
## 4. CORS Global Configuration
|
||||
|
||||
De Shell leest de `CorsSettings` uit `appsettings.json` en configureert een globale policy:
|
||||
|
||||
```json
|
||||
{
|
||||
"CorsSettings": {
|
||||
"AllowedOrigins": ["https://portal.slp-modular.local"],
|
||||
"AllowAnyHeader": true,
|
||||
"AllowAnyMethod": true
|
||||
}
|
||||
}
|
||||
```
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# NFR Requirements — Unit 04: API Shell & Integration
|
||||
|
||||
Dit document specificeert de non-functionele vereisten voor de API Shell.
|
||||
|
||||
## 1. Performance (SHELL-PERF)
|
||||
|
||||
- **SHELL-PERF-01: Startup Tijd**:
|
||||
- Hoewel de startup tijd niet kritisch is (> 5 sec toegestaan), moet de `ModuleOrchestrator` efficiënt scannen om onnodige vertragingen te voorkomen.
|
||||
- **SHELL-PERF-02: Pipeline Efficiency**:
|
||||
- De orkestratie van middleware mag geen significante overhead toevoegen aan de verwerking van individuele requests.
|
||||
|
||||
## 2. Beveiliging (SHELL-SEC)
|
||||
|
||||
- **SHELL-SEC-01: CORS**:
|
||||
- CORS moet worden geconfigureerd via `appsettings.json`. De default instelling voor productie moet strikt zijn (geen wildcards).
|
||||
- **SHELL-SEC-02: HTTPS**:
|
||||
- De API Shell moet HTTPS afdwingen via `app.UseHttpsRedirection()`.
|
||||
- **SHELL-SEC-03: JWT Configuratie**:
|
||||
- De Shell is verantwoordelijk voor het correct configureren van de `JwtBearerAuthentication` met de keys en settings die in Unit 02 zijn gedefinieerd.
|
||||
|
||||
## 3. Bruikbaarheid (SHELL-USAB)
|
||||
|
||||
- **SHELL-USAB-01: Swagger**:
|
||||
- Swagger UI moet volledig interactief zijn, inclusief ondersteuning voor JWT Bearer authenticatie (Authorize knop).
|
||||
- Alle endpoints moeten duidelijk gedocumenteerd zijn met hun verwachte input en output modellen.
|
||||
|
||||
## 4. Onderhoudbaarheid (SHELL-MAINT)
|
||||
|
||||
- **SHELL-MAINT-01: Logging Aggregatie**:
|
||||
- Alle logs van modules moeten worden geaggregeerd naar de centrale logging provider van de Shell.
|
||||
- Contextuele informatie (zoals de module naam) moet aan de logs worden toegevoegd voor betere traceerbaarheid.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
# Tech Stack Decisions — Unit 04: API Shell & Integration
|
||||
|
||||
Dit document beschrijft de definitieve technische keuzes voor Unit 04.
|
||||
|
||||
## 1. API Framework & Routing
|
||||
|
||||
- **Host**: ASP.NET Core 10.
|
||||
- **Versioning**: `Asp.Versioning.Mvc` (v1 in path).
|
||||
- **CORS**: `Microsoft.AspNetCore.Cors`.
|
||||
|
||||
## 2. API Documentatie
|
||||
|
||||
- **Swagger Provider**: `Swashbuckle.AspNetCore`.
|
||||
- **UI**: `SwaggerUI`.
|
||||
- **Beveiliging**: Geconfigureerd met `OpenApiSecurityScheme` (Type: `ApiKey`, In: `Header`, Name: `Authorization`, Scheme: `Bearer`).
|
||||
|
||||
## 3. Module Discovery
|
||||
|
||||
- **Scanning Mechanism**: Reflection via `AppDomain.CurrentDomain.GetAssemblies()` gecombineerd met `Assembly.Load` voor DLL's die nog niet geladen zijn maar wel de prefix hebben.
|
||||
|
||||
## 4. Configuratie Beheer
|
||||
|
||||
- **Options Pattern**: Gebruik van `IOptions` voor alle shell-specifieke instellingen (CORS, Versioning, Swagger).
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# Business Rules — Unit 03: Availability Module
|
||||
|
||||
Dit document beschrijft de functionele logica voor de beschikbaarheidscontrole en de remote shutdown functionaliteit.
|
||||
|
||||
## 1. Beschikbaarheidsstatus (BR-AVAIL-01)
|
||||
|
||||
- **Status Typen**:
|
||||
- `Available`: Het systeem is volledig operationeel.
|
||||
- `Maintenance`: Het systeem is in onderhoud; alleen beheerders hebben toegang.
|
||||
- `Degraded`: Sommige functies zijn beperkt, maar het systeem is in principe bereikbaar.
|
||||
- `NotAvailable`: Het systeem is volledig afgesloten (Remote Shutdown).
|
||||
- **Default (MVP)**: In de MVP versie retourneert de `StubAvailabilityService` altijd `Available`, tenzij handmatig anders geconfigureerd in `appsettings.json`.
|
||||
|
||||
## 2. Remote Shutdown Handhaving (BR-AVAIL-02)
|
||||
|
||||
- **Mechanisme**: Een globale middleware controleert bij elk inkomend request de status via de `IAvailabilityService`.
|
||||
- **Gedrag**:
|
||||
- Als status == `NotAvailable` -> Retourneer `503 Service Unavailable`.
|
||||
- Als status == `Maintenance` -> Blokkeer requests voor reguliere gebruikers; sta alleen toe voor gebruikers met de rol `Owner` of `Administrator`.
|
||||
- **Response**: De response moet het gestandaardiseerde `ApiErrorResponse` formaat gebruiken (U01).
|
||||
|
||||
## 3. Publieke Status (BR-AVAIL-03)
|
||||
|
||||
- **Endpoint**: `GET /api/availability/status` moet voor iedereen bereikbaar zijn (geen authenticatie vereist).
|
||||
- **Informatie**: Het endpoint retourneert de huidige status en een timestamp van de laatste controle.
|
||||
|
||||
## 4. Beheerder Bypass (BR-AVAIL-04)
|
||||
|
||||
- **Rechten**: Gebruikers met de rol `Owner` of `Administrator` kunnen de blokkades van de Availability Middleware omzeilen om onderhoudstaken uit te voeren.
|
||||
- **Identificatie**: De bypass is gebaseerd op de JWT claims (`role`).
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Domain Entities — Unit 03: Availability Module
|
||||
|
||||
Dit document beschrijft de data structuren voor de beschikbaarheidsmodule.
|
||||
|
||||
## 1. AvailabilityResponse (DTO)
|
||||
|
||||
Model voor de publieke status check.
|
||||
|
||||
- **Status**: De huidige `AvailabilityStatus` (Enum uit U01).
|
||||
- **CheckedAt**: Tijdstip van de status check.
|
||||
- **Message**: Optionele tekstuele toelichting (bijv. "Onderhoud gepland tot 14:00").
|
||||
|
||||
## 2. AvailabilitySettings (Configuration)
|
||||
|
||||
Model voor de configuratie in `appsettings.json`.
|
||||
|
||||
- **DefaultStatus**: De status die geretourneerd wordt door de stub.
|
||||
- **MaintenanceMessage**: Bericht dat getoond wordt tijdens onderhoud.
|
||||
- **AllowedRolesForMaintenance**: Lijst van rollen die toegang hebben tijdens onderhoud (default: `Owner`, `Administrator`).
|
||||
|
||||
## 3. AvailabilityState (In-Memory)
|
||||
|
||||
Indien we in de MVP de status dynamisch willen kunnen aanpassen zonder restart:
|
||||
|
||||
- **CurrentStatus**: `AvailabilityStatus`.
|
||||
- **StatusChangedAt**: DateTimeOffset.
|
||||
- **Reason**: String.
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
# Business Logic Model — Unit 03: Availability Module
|
||||
|
||||
Dit document beschrijft de processen voor beschikbaarheidscontrole.
|
||||
|
||||
## 1. Availability Middleware Flow
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Inkomend Request] --> B{Is Endpoint /status?}
|
||||
B -- Ja --> C[Laat door naar Controller]
|
||||
B -- Nee --> D{Check Status via IAvailabilityService}
|
||||
D --> E{Status == Available?}
|
||||
E -- Ja --> C
|
||||
E -- Nee --> F{Status == Maintenance?}
|
||||
F -- Ja --> G{Heeft Rol Admin/Owner?}
|
||||
G -- Ja --> C
|
||||
G -- Nee --> H[Retourneer 503 + ApiErrorResponse]
|
||||
F -- Nee --> H
|
||||
```
|
||||
|
||||
## 2. Status Check Flow
|
||||
|
||||
1. **Client** roept `GET /api/availability/status` aan.
|
||||
2. **AvailabilityController** roept `IAvailabilityService.IsAvailableAsync()` aan.
|
||||
3. **Service** haalt status op (in MVP uit config of in-memory state).
|
||||
4. **Controller** bouwt response:
|
||||
```json
|
||||
{
|
||||
"status": "Available",
|
||||
"checkedAt": "2026-06-12T01:15:00Z",
|
||||
"message": "System is running normally."
|
||||
}
|
||||
```
|
||||
|
||||
## 3. Remote Shutdown Logic (Toekomst)
|
||||
|
||||
Hoewel de MVP een stub gebruikt, is het logic model voorbereid op een externe trigger:
|
||||
- Een administratieve actie zet een vlag in de database/cache.
|
||||
- De `IAvailabilityService` detecteert deze wijziging.
|
||||
- De Middleware reageert direct op alle volgende requests.
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
# Controller Design — Unit 03: Availability Module
|
||||
|
||||
Dit document beschrijft de endpoints van de `AvailabilityController`.
|
||||
|
||||
## 1. Publieke Status Endpoint
|
||||
|
||||
- **Method**: `GET`
|
||||
- **Path**: `/api/availability/status`
|
||||
- **Auth**: Geen (AllowAnonymous)
|
||||
- **Response**: `AvailabilityResponse`
|
||||
- **Logic**: Roept `IAvailabilityService.IsAvailableAsync()` aan en mapt de status naar het response object.
|
||||
|
||||
## 2. Status Update Endpoint (Beheer)
|
||||
|
||||
- **Method**: `POST`
|
||||
- **Path**: `/api/availability/admin/status`
|
||||
- **Auth**: `OwnerOnly` Policy (Unit 02)
|
||||
- **Request Body**:
|
||||
```json
|
||||
{
|
||||
"newStatus": "Maintenance",
|
||||
"reason": "Gepland database onderhoud"
|
||||
}
|
||||
```
|
||||
- **Logic**:
|
||||
1. Valideert de nieuwe status.
|
||||
2. Werkt de database record bij via de `IAvailabilityService`.
|
||||
3. Maakt een audit log aan (Unit 02).
|
||||
- **Response**: `200 OK`.
|
||||
|
||||
## 3. Integratie met Audit Log
|
||||
|
||||
Bij elke statuswijziging wordt de `IAuditService` aangeroepen met de volgende gegevens:
|
||||
- **ActorId**: De ID van de Owner.
|
||||
- **Action**: `SystemStatusChanged`.
|
||||
- **Details**: `OldStatus: Available, NewStatus: Maintenance, Reason: ...`
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
# Middleware Design — Unit 03: Availability Module
|
||||
|
||||
Dit document beschrijft de technische implementatie van de Availability Middleware.
|
||||
|
||||
## 1. Middleware Registratie
|
||||
|
||||
De middleware wordt in de `Program.cs` van de API Shell (U04) geregistreerd:
|
||||
|
||||
```csharp
|
||||
app.UseExceptionHandler(); // Eerst de exception handler (U01)
|
||||
app.UseAvailability(); // Daarna de availability check
|
||||
// ... andere middleware (Auth, Routing, etc)
|
||||
```
|
||||
|
||||
## 2. AvailabilityMiddleware Logica
|
||||
|
||||
- **Bypass voor Status Endpoint**: Het pad `/api/availability/status` wordt altijd doorgelaten zonder check.
|
||||
- **Check Fase**:
|
||||
- De middleware roept `IAvailabilityService.IsAvailableAsync()` aan.
|
||||
- Indien status == `Available` -> `_next(context)`.
|
||||
- **Bypass voor Admins/Owners**:
|
||||
- Indien status == `Maintenance` of `NotAvailable`:
|
||||
- De middleware inspecteert het JWT token in de `Authorization` header handmatig (omdat de globale Authentication middleware nog niet is uitgevoerd op dit punt).
|
||||
- Indien de claim `role` gelijk is aan `Owner` of `Administrator` -> `_next(context)`.
|
||||
- Anders -> Retourneer `503 Service Unavailable` met `ApiErrorResponse`.
|
||||
|
||||
## 3. PersistentAvailabilityService
|
||||
|
||||
Implementatie van de interface uit Unit 01.
|
||||
|
||||
- **Database Opslag**: Maakt gebruik van de `ApplicationDbContext` (Unit 02).
|
||||
- **Circuit Breaker**:
|
||||
- Houdt in een statische variabele de `_lastErrorTime` en `_cachedStatus` bij.
|
||||
- Indien `DateTimeOffset.UtcNow - _lastErrorTime < 30 seconden` -> Retourneer de `_cachedStatus` (default: `Available`) zonder de database te pollen.
|
||||
- **Logging**: Elke blokkade wordt gelogd met het IP-adres van de client en het gevraagde pad.
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# NFR Requirements — Unit 03: Availability Module
|
||||
|
||||
Dit document specificeert de non-functionele vereisten voor de beschikbaarheidsmodule.
|
||||
|
||||
## 1. Performance (AVAIL-PERF)
|
||||
|
||||
- **AVAIL-PERF-01: Middleware Latency**:
|
||||
- De Availability Middleware mag maximaal 5ms toevoegen aan de totale requestduur.
|
||||
- Dit vereist een geoptimaliseerde database check (indexering op de status tabel).
|
||||
- **AVAIL-PERF-02: Real-time Check**:
|
||||
- Er wordt GEEN caching toegepast in de middleware (conform gebruikerskeuze). Elke request voert een actuele check uit om maximale consistentie te waarborgen.
|
||||
|
||||
## 2. Betrouwbaarheid & Persistentie (AVAIL-REL)
|
||||
|
||||
- **AVAIL-REL-01: Persistent Status**:
|
||||
- De beschikbaarheidsstatus moet in de database worden opgeslagen, zodat deze behouden blijft na een herstart van de applicatie.
|
||||
- **AVAIL-REL-02: Fallback**:
|
||||
- Indien de database onbereikbaar is, moet de `IAvailabilityService` terugvallen op een "Veilige" status (bijv. `Available` of de laatst bekende status in het geheugen) om een lock-out te voorkomen.
|
||||
|
||||
## 3. Beveiliging (AVAIL-SEC)
|
||||
|
||||
- **AVAIL-SEC-01: Access Control**:
|
||||
- Alleen gebruikers met de rol `Owner` kunnen de globale beschikbaarheidsstatus van de API wijzigen via een beveiligd endpoint.
|
||||
- **AVAIL-SEC-02: Maintenance Bypass**:
|
||||
- De bypass voor beheerders (zoals gedefinieerd in Functional Design) moet strikt gecontroleerd worden op basis van JWT claims.
|
||||
|
||||
## 4. Onderhoudbaarheid (AVAIL-MAINT)
|
||||
|
||||
- **AVAIL-MAINT-01: Audit Trail**:
|
||||
- Elke wijziging van de beschikbaarheidsstatus moet worden gelogd in de `AuditLogs` tabel (Unit 02), inclusief de reden en de uitvoerder.
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
# Tech Stack Decisions — Unit 03: Availability Module
|
||||
|
||||
Dit document beschrijft de definitieve technische keuzes voor Unit 03.
|
||||
|
||||
## 1. Opslag (Persistence)
|
||||
|
||||
- **Provider**: Microsoft SQL Server (conform NFR-01).
|
||||
- **Entiteit**: `GlobalAvailabilityState` (Single record).
|
||||
|
||||
## 2. Middleware Implementatie
|
||||
|
||||
- **Type**: Custom Middleware in de `SlpModularCms.Api` (Shell).
|
||||
- **Dependency**: Maakt gebruik van de `IAvailabilityService` uit Unit 01.
|
||||
|
||||
## 3. Interfaces & DI
|
||||
|
||||
- **Service**: `PersistentAvailabilityService` (Implementeert `IAvailabilityService`).
|
||||
- **Lifetime**: `Scoped` (voor database toegang per request).
|
||||
|
||||
## 4. Configuratie
|
||||
|
||||
- **Options Pattern**: Gebruik van `IOptions<AvailabilitySettings>` voor de fallback status en andere drempelwaarden.
|
||||
|
||||
## 5. Monitoring
|
||||
|
||||
- **Logging**: Gebruik van `ILogger` voor het loggen van statuswijzigingen en middleware blokkades (Warning niveau).
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# Business Logic Model — Unit 01: Core Base
|
||||
|
||||
Dit document beschrijft de functionele workflows en dataflows binnen het Core Framework.
|
||||
|
||||
## 1. Module Levenscyclus Model
|
||||
|
||||
Het framework beheert modules via de volgende logische stappen:
|
||||
|
||||
1. **Discovery**: De API Shell identificeert potentiële modules (via referentie of DLL scan).
|
||||
2. **Registration**: De Core valideert de `ModuleInfo`.
|
||||
- Controleert BR-CORE-01 (Uniciteit & Metadata).
|
||||
3. **Service Registration**: De Core roept `RegisterServices` aan.
|
||||
- Modules voegen hun services toe aan de globale DI-container.
|
||||
4. **Middleware Configuration**: De Core roept `ConfigureMiddleware` aan tijdens de startup van de webhost.
|
||||
|
||||
## 2. Globale Availability Orchestratie Model
|
||||
|
||||
Het proces van statuscontrole verloopt als volgt:
|
||||
|
||||
- **Centrale Controle**: De Core Base definieert de `IAvailabilityService` interface. De API Shell gebruikt één centrale implementatie om de status van de gehele API te bepalen.
|
||||
- **Binaire Status**: Het resultaat is een binaire status (beschikbaar/niet beschikbaar) voor de volledige API suite, niet opgedeeld per individuele module.
|
||||
- **Reporting**: De resultaten worden gerapporteerd in een enkel `AvailabilityDetails` object.
|
||||
|
||||
## 3. Exception-to-Response Flow
|
||||
|
||||
Flow van een foutieve actie naar een response:
|
||||
|
||||
1. **Event**: Een actie in een module of de Core gooit een domein-exception.
|
||||
2. **Capture**: Globale middleware (in de Shell, maar gedefinieerd in Core) vangt de exception op.
|
||||
3. **Transformation**: De exception wordt gemapt naar een `ApiErrorResponse` volgens BR-CORE-03.
|
||||
4. **Response**: De client ontvangt een gestandaardiseerde JSON body met de relevante HTTP status code (bijv. 404 voor `ModuleNotFoundException`).
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
# Business Rules — Unit 01: Core Base
|
||||
|
||||
Dit document beschrijft de validatieregels en logica voor het Core Framework.
|
||||
|
||||
## 1. Module Registratie Regels (BR-CORE-01)
|
||||
|
||||
- **Uniciteit**: Elke module moet een unieke `Name` hebben. Registratie van een tweede module met dezelfde naam moet resulteren in een `DuplicateModuleException`.
|
||||
- **Verplichte Metadata**: Registratie faalt als `Name`, `Version` of `Description` leeg zijn.
|
||||
- **Dependency Resolutie**:
|
||||
- Als een module afhankelijkheden opgeeft, moet het framework controleren of deze modules ook geladen zijn.
|
||||
- Bij ontbrekende afhankelijkheden moet een waarschuwing worden gelogd, maar mag de applicatie in de MVP fase wel doorstarten (soft dependency).
|
||||
|
||||
## 2. Globale Availability Regels (BR-CORE-02)
|
||||
|
||||
- **API-breed**: De beschikbaarheidscontrole is een binaire status voor de gehele API Shell.
|
||||
- **Implementatie Verplichting**: Er moet één actieve implementatie van `IAvailabilityService` geregistreerd zijn in de API Shell.
|
||||
- **Gedrag**: Indien de service niet bereikbaar is (bijv. door Master-API uitval in de toekomst), wordt de gehele API als "niet beschikbaar" beschouwd voor niet-beheerders.
|
||||
|
||||
## 3. Error Handling Conversie (BR-CORE-03)
|
||||
|
||||
- **Gedetailleerde Mapping**: Elke domein-specifieke exception moet worden vertaald naar een `ApiErrorResponse` met specifieke details.
|
||||
- `ModuleNotFoundException` -> Details bevatten de gezochte `ModuleName`.
|
||||
- `UnauthorizedAccessException` -> Details bevatten de vereiste rol en de huidige rol van de gebruiker.
|
||||
- `ValidationException` -> Details bevatten een lijst van velden die niet voldeden aan de regels.
|
||||
- **Privacy**: In productie-omgevingen moeten stacktraces worden verwijderd uit de `Details` dictionary.
|
||||
+49
@@ -0,0 +1,49 @@
|
||||
# Domain Entities — Unit 01: Core Base
|
||||
|
||||
Dit document beschrijft de domein-modellen en interfaces voor het Core Framework.
|
||||
|
||||
## 1. Module Interfaces & Entiteiten
|
||||
|
||||
### IModule
|
||||
Het basiscontract voor elke module in het systeem.
|
||||
```csharp
|
||||
public interface IModule
|
||||
{
|
||||
ModuleInfo GetInfo();
|
||||
void RegisterServices(IServiceCollection services);
|
||||
void ConfigureMiddleware(IApplicationBuilder app);
|
||||
}
|
||||
```
|
||||
|
||||
### ModuleInfo (Record)
|
||||
Metadata van een module, verplicht op te geven bij registratie.
|
||||
- `string Name`: Unieke identifier van de module.
|
||||
- `string Version`: Semantische versie (bijv. 1.0.0).
|
||||
- `string Description`: Korte omschrijving van het doel.
|
||||
- `IEnumerable<string> Dependencies`: Lijst met namen van modules waar deze module van afhankelijk is.
|
||||
|
||||
## 2. Availability Interfaces & Entiteiten
|
||||
|
||||
### IAvailabilityService
|
||||
Service die de status van een component bewaakt.
|
||||
```csharp
|
||||
public interface IAvailabilityService
|
||||
{
|
||||
Task<bool> IsAvailableAsync();
|
||||
Task<AvailabilityDetails> GetDetailsAsync();
|
||||
}
|
||||
```
|
||||
|
||||
### AvailabilityDetails (Record)
|
||||
Gedetailleerde statusinformatie.
|
||||
- `bool IsAvailable`: Globale status van de API.
|
||||
- `DateTime LastChecked`: Tijdstip van de laatste controle.
|
||||
- `IDictionary<string, string> Metadata`: Extra statusinformatie (bijv. latency, Master-API status).
|
||||
|
||||
## 3. Error Handling Models
|
||||
|
||||
### ApiErrorResponse
|
||||
Basismodel voor foutmeldingen.
|
||||
- `string ErrorCode`: Functionele code (bijv. "MODULE_NOT_FOUND").
|
||||
- `string Message`: Mensvriendelijke beschrijving.
|
||||
- `IDictionary<string, object> Details`: Specifieke debug- of context-informatie per exception type.
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# Availability Service Design — Unit 01: Core Base
|
||||
|
||||
Dit document beschrijft de technische details voor de beschikbaarheidscontrole (NFR-AVAIL-01).
|
||||
|
||||
## 1. Configuratie
|
||||
|
||||
De timeout wordt globaal geconfigureerd in `appsettings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"AvailabilitySettings": {
|
||||
"TimeoutSeconds": 2,
|
||||
"DefaultStatusOnFailure": "Unknown"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 2. IAvailabilityService Interface
|
||||
|
||||
Gedefinieerd in U01:
|
||||
|
||||
```csharp
|
||||
public interface IAvailabilityService
|
||||
{
|
||||
/// <summary>
|
||||
/// Controleert de algemene beschikbaarheid van de API.
|
||||
/// Gebruikt de geconfigureerde globale timeout.
|
||||
/// </summary>
|
||||
Task<AvailabilityStatus> IsAvailableAsync();
|
||||
}
|
||||
```
|
||||
|
||||
## 3. Implementatie Details
|
||||
|
||||
- **Timeout Mechanisme**: De implementatie maakt intern gebruik van `Task.WaitAsync(TimeSpan)` of een intern aangemaakte `CancellationTokenSource` met de tijd uit de configuratie.
|
||||
- **Fallback**: Bij een `TimeoutException` of een andere interne fout tijdens de check, wordt de status gerapporteerd die in de configuratie is vastgelegd (bijv. "Unknown").
|
||||
- **Logging**: Elke mislukte check of timeout moet worden gelogd met een `Warning` niveau, inclusief de verstreken tijd.
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
# Exception Handling Design — Unit 01: Core Base
|
||||
|
||||
Dit document beschrijft de technische implementatie van de globale foutafhandeling (NFR-SEC-01).
|
||||
|
||||
## 1. IExceptionHandler Implementatie
|
||||
|
||||
We maken gebruik van de `IExceptionHandler` interface (.NET 8+).
|
||||
|
||||
### Component: `GlobalExceptionHandler`
|
||||
- **Verantwoordelijkheid**: Het vangen van ongehandled exceptions en het omzetten naar een gestandaardiseerd `ApiErrorResponse`.
|
||||
- **Logic**:
|
||||
- Logt de volledige exception (inclusief stacktrace) naar `ILogger<GlobalExceptionHandler>`.
|
||||
- Bepaalt de HTTP Status Code op basis van het type exception (bijv. `ValidationException` -> 400, `NotFoundException` -> 404, de rest -> 500).
|
||||
- Bouwt het `ApiErrorResponse` object.
|
||||
|
||||
## 2. ApiErrorResponse Structuur
|
||||
|
||||
Conform NFR-SEC-01 wordt gevoelige informatie gefilterd in productie.
|
||||
|
||||
```csharp
|
||||
public record ApiErrorResponse(
|
||||
string Message,
|
||||
string? Detail = null,
|
||||
string? TraceId = null
|
||||
);
|
||||
```
|
||||
|
||||
### Gedrag per omgeving:
|
||||
- **Development**: `Message` bevat de exception message, `Detail` bevat de stacktrace.
|
||||
- **Production**: `Message` bevat een generieke foutmelding of een veilige publieke melding, `Detail` is `null`. `TraceId` wordt altijd meegegeven voor correlatie in logs.
|
||||
|
||||
## 3. Registratie
|
||||
|
||||
In `Program.cs` (U04) of via een extensie-methode in de Core Base:
|
||||
```csharp
|
||||
services.AddExceptionHandler<GlobalExceptionHandler>();
|
||||
services.AddProblemDetails();
|
||||
```
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
# Module Discovery Design — Unit 01: Core Base
|
||||
|
||||
Dit document beschrijft het ontwerp van de dynamische module discovery (NFR-PERF-01).
|
||||
|
||||
## 1. Naamconventie
|
||||
|
||||
Het systeem scant automatisch naar assemblies die voldoen aan het volgende patroon:
|
||||
`SlpModularCms.Modules.*.dll`
|
||||
|
||||
## 2. Discovery Logica
|
||||
|
||||
De `ModuleOrchestrator` (onderdeel van U04, maar gebruikmakend van interfaces uit U01) voert de volgende stappen uit tijdens het opstarten:
|
||||
|
||||
1. **Assembly Loading**: Zoekt in de applicatie-directory naar DLL's die voldoen aan de naamconventie.
|
||||
2. **Type Scanning**: In elke geladen assembly wordt gezocht naar klassen die de `IModule` interface implementeren.
|
||||
3. **Registration**: De gevonden module-entry klassen worden geïnstantieerd en hun `RegisterServices(IServiceCollection services)` methode wordt aangeroepen.
|
||||
|
||||
### Performance Optimalisatie:
|
||||
- Om de opstarttijd te minimaliseren (NFR-PERF-01), worden alleen assemblies gescand die voldoen aan de prefix.
|
||||
- De resultaten van de discovery kunnen indien nodig worden gecached, hoewel de overhead bij een beperkt aantal modules verwaarloosbaar is (< 100ms).
|
||||
|
||||
## 3. IModule Interface
|
||||
|
||||
Gedefinieerd in de Core Base (U01):
|
||||
|
||||
```csharp
|
||||
public interface IModule
|
||||
{
|
||||
string Name { get; }
|
||||
string Version { get; }
|
||||
void RegisterServices(IServiceCollection services);
|
||||
void UseModule(IApplicationBuilder app);
|
||||
}
|
||||
```
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# Testing Strategy Design — Unit 01: Core Base
|
||||
|
||||
Dit document beschrijft de testaanpak voor de Core Base componenten (NFR-MAINT-02).
|
||||
|
||||
## 1. Tooling
|
||||
|
||||
- **Framework**: xUnit.
|
||||
- **Data Generatie**: AutoFixture.
|
||||
- **Mocks**: NSubstitute (optioneel, indien nodig voor interfaces).
|
||||
- **Assertions**: FluentAssertions.
|
||||
|
||||
## 2. AutoFixture Patronen
|
||||
|
||||
Om consistentie te waarborgen gebruiken we de volgende patronen:
|
||||
|
||||
### Customizations
|
||||
Voor domein-specifieke types (zoals `ModuleInfo`) maken we gebruik van `ICustomization` klassen om realistische data te genereren.
|
||||
|
||||
```csharp
|
||||
public class ModuleCustomization : ICustomization
|
||||
{
|
||||
public void Customize(IFixture fixture)
|
||||
{
|
||||
fixture.Customize<ModuleInfo>(composer =>
|
||||
composer.With(m => m.Version, "1.0.0"));
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Base Test Class
|
||||
We overwegen een base class voor unit tests die de `IFixture` configureert met de benodigde customizations.
|
||||
|
||||
## 3. Test Dekking Targets
|
||||
|
||||
- **Exception Mapping**: 100% dekking van alle bekende exception types naar de juiste HTTP status codes en response formaten.
|
||||
- **Availability Fallback**: Tests die vertraging simuleren om te verifiëren dat de timeout en fallback status correct werken.
|
||||
- **Module Discovery**: Integratietesten (met in-memory assemblies) om te verifiëren dat de conventie-gebaseerde scanning correct werkt.
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# NFR Requirements — Unit 01: Core Base
|
||||
|
||||
Dit document beschrijft de non-functional requirements voor het Core Framework.
|
||||
|
||||
## 1. Schaalbaarheid & Performance (NFR-PERF)
|
||||
|
||||
- **Dynamische Module Discovery**: Het systeem moet een onbekend aantal modules kunnen ondersteunen zonder significante degradatie van de opstarttijd.
|
||||
- **Middleware Overhead**: Een overhead van > 50ms voor globale exception handling en logging is acceptabel bevonden om robuustheid en detailniveau te waarborgen.
|
||||
- **Resource Management**: Interfaces in de Core Base moeten `async` zijn waar I/O verwacht wordt (bijv. `IAvailabilityService`) om threadpool starvation te voorkomen.
|
||||
|
||||
## 2. Security & Privacy (NFR-SEC)
|
||||
|
||||
- **Informatiebeveiliging in Responses**: De `ApiErrorResponse` mag in productieomgevingen onder geen beding de volgende informatie bevatten:
|
||||
- Stacktraces.
|
||||
- Interne server IP-adressen.
|
||||
- Lokale bestandspaden van de server.
|
||||
- **Isolatie**: Hoewel modules in dezelfde procesruimte draaien, moet de Core Base interfaces bieden die een duidelijke scheiding van verantwoordelijkheden afdwingen.
|
||||
|
||||
## 3. Availability & Reliability (NFR-AVAIL)
|
||||
|
||||
- **Check Timeout**: De `IAvailabilityService.IsAvailableAsync()` methode moet een instelbare timeout hebben, met een standaardwaarde tussen 1 en 2 seconden.
|
||||
- **Graceful Degradation**: Bij het falen van de beschikbaarheidscontrole moet het systeem een veilige fallback status rapporteren (bijv. "Onbekend" of "Niet beschikbaar" voor reguliere gebruikers).
|
||||
|
||||
## 4. Onderhoudbaarheid & Testbaarheid (NFR-MAINT)
|
||||
|
||||
- **Consistentie**: Gebruik van gestandaardiseerde .NET patronen voor DI en Logging.
|
||||
- **Test Dekking**: Cruciale cross-cutting concerns (zoals exception mapping) moeten gedekt zijn met unit tests die gebruik maken van geautomatiseerde data generatie.
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
# Tech Stack Decisions — Unit 01: Core Base
|
||||
|
||||
Dit document legt de gekozen technologieën en bibliotheken vast voor de implementatie van Unit 01.
|
||||
|
||||
## 1. Core Framework & Runtime
|
||||
|
||||
- **Runtime**: .NET 10.
|
||||
- **Project Type**: Class Library (voor Core).
|
||||
|
||||
## 2. Cross-Cutting Concerns
|
||||
|
||||
- **Dependency Injection**: Standaard `Microsoft.Extensions.DependencyInjection`. Er is momenteel geen behoefte aan externe containers zoals Autofac.
|
||||
- **Logging**: Standaard `Microsoft.Extensions.Logging`. Implementaties (zoals Serilog voor file/cloud logging) kunnen later in de API Shell (U04) worden geconfigureerd.
|
||||
|
||||
## 3. Testing Stack
|
||||
|
||||
- **Unit Testing Framework**: `xUnit`.
|
||||
- **Assertions**: `FluentAssertions` voor leesbare en expressieve checks.
|
||||
- **Data Generation**: `AutoFixture` voor het genereren van test data en het ondersteunen van geautomatiseerde scenario's (ter vervanging/aanvulling van formele PBT met FsCheck, conform gebruikersvoorkeur).
|
||||
|
||||
## 4. Architecturale Patronen
|
||||
|
||||
- **Interfaces & Records**: Veelal gebruik van `record` types voor DTO's en metadata (zoals `ModuleInfo`) voor onveranderlijkheid (immutability).
|
||||
- **Middleware**: Gebruik van het standard .NET Middleware patroon voor globale exception handling.
|
||||
@@ -0,0 +1,33 @@
|
||||
# Construction Phase Final Report - SlpModularCms.Api
|
||||
|
||||
## Project Overzicht
|
||||
- **Project**: SlpModularCms.Api
|
||||
- **Status**: VOLTOOID
|
||||
- **Datum**: 2026-06-12
|
||||
|
||||
## Voltooide Units
|
||||
1. **Unit 01: Core Base**
|
||||
- Kern interfaces (`IModule`, `IAvailabilityService`).
|
||||
- Globale exception handling (.NET 8+ stijl).
|
||||
- Project structuur (`src/` folder) en test setup.
|
||||
2. **Unit 02: Identity & RBAC**
|
||||
- ASP.NET Core Identity integratie met hiërarchische rollen (Owner, Admin, User).
|
||||
- JWT Authenticatie en Refresh Token mechanisme (SQL Server persistent).
|
||||
- Uitnodigingsflow voor nieuwe gebruikers.
|
||||
3. **Unit 03: Availability Module**
|
||||
- Dynamische statuscontrole (Available, Maintenance, Degraded).
|
||||
- Persistentie in database met Circuit Breaker fallback.
|
||||
- Middleware integratie met bypass voor beheerderstaken.
|
||||
4. **Unit 04: API Shell & Integration**
|
||||
- Dynamische module discovery via assembly scanning.
|
||||
- Globale API versioning (`/api/v1/`).
|
||||
- Scalar OpenAPI documentatie op `/scalar`.
|
||||
- CORS en Security headers geconfigureerd.
|
||||
|
||||
## Verificatie Resultaten
|
||||
- **Build**: Succesvol (0 errors).
|
||||
- **Unit Tests**: 21 tests geslaagd (100% pass rate).
|
||||
- **Integratie**: Succesvol (Module discovery en routing geverifieerd).
|
||||
|
||||
## Conclusie
|
||||
De CONSTRUCTION PHASE is formeel afgerond. Alle functionele en niet-functionele vereisten voor de MVP zijn geïmplementeerd en geverifieerd. Het systeem is klaar voor de OPERATIONS PHASE of verdere functionele uitbreidingen.
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
# Business Rules — Unit 02: Identity & RBAC
|
||||
|
||||
Dit document beschrijft de validatieregels en logica voor identiteitsbeheer en autorisatie.
|
||||
|
||||
## 1. Hiërarchische Rollen (BR-ID-01)
|
||||
|
||||
- **Hiërarchie**: Owner (100) > Administrator (50) > User (10).
|
||||
- **Beperking**: Een gebruiker kan alleen acties uitvoeren op gebruikers met een **lagere** rol in de hiërarchie.
|
||||
- Uitzondering: Een Owner kan acties uitvoeren op andere Owners (bijv. de-activeren, mits niet de laatste Owner).
|
||||
- Een Administrator kan een User beheren, maar geen andere Administrator of Owner.
|
||||
- **Rolverandering**: Een gebruiker kan een andere gebruiker nooit een rol toekennen die hoger is dan zijn eigen rol.
|
||||
|
||||
## 2. Gebruikerscreatie & Uitnodiging (BR-ID-02)
|
||||
|
||||
- **Geen Zelfregistratie**: Het systeem staat geen publieke registratie toe.
|
||||
- **Uitnodigingsflow**:
|
||||
1. Administrator/Owner maakt een uitnodiging aan (e-mail + rol).
|
||||
2. Systeem genereert een `InvitationToken` met een beperkte geldigheidsduur (bijv. 24 uur).
|
||||
3. Gebruiker moet via een specifiek endpoint (`POST /api/setup/complete-invitation`) zijn wachtwoord instellen met dit token.
|
||||
4. Na succesvolle instelling wordt het token ongeldig en het account geactiveerd.
|
||||
|
||||
## 3. Bootstrapping (BR-ID-03)
|
||||
|
||||
- **Setup Endpoint**: Bij een lege database is een eenmalig endpoint `POST /api/setup/init` beschikbaar.
|
||||
- **Eerste Owner**: Dit endpoint accepteert de gegevens voor de eerste Owner. Na succesvolle aanmaak wordt dit endpoint permanent geblokkeerd of verwijderd uit de routing.
|
||||
|
||||
## 4. Authenticatie & Sessies (BR-ID-04)
|
||||
|
||||
- **Wachtwoord Hashen**: Wachtwoorden moeten gehasht worden volgens de ASP.NET Core Identity standaard (PBKDF2 met HMAC-SHA256).
|
||||
- **Refresh Tokens**:
|
||||
- Refresh tokens zijn gekoppeld aan een specifieke gebruiker en client/apparaat.
|
||||
- Refresh tokens kunnen maar één keer worden gebruikt (Rotation-principe).
|
||||
- Bij gebruik van een oud refresh token worden alle actieve sessies van die gebruiker ongeldig gemaakt (beveiligingsmaatregel tegen token diefstal).
|
||||
|
||||
## 5. Module-specifieke Rechten (BR-ID-05)
|
||||
|
||||
- **Fine-grained Access**: Naast de globale rollen kunnen Beheerders specifieke rechten per module toekennen aan Users.
|
||||
- **Default**: Zonder expliciete module-rechten heeft een User alleen leesrechten of basisrechten binnen een module (afhankelijk van de module-implementatie).
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# Domain Entities — Unit 02: Identity & RBAC
|
||||
|
||||
Dit document beschrijft de data-entiteiten die nodig zijn voor identiteitsbeheer.
|
||||
|
||||
## 1. ApplicationUser
|
||||
|
||||
Breidt de standaard `IdentityUser` uit.
|
||||
|
||||
- **Email**: Unieke identifier.
|
||||
- **Role**: De primaire hiërarchische rol (`Owner`, `Administrator`, `User`).
|
||||
- **IsActive**: Boolean status.
|
||||
- **CreatedAt**: Tijdstip van aanmaak.
|
||||
- **ModulePermissions**: Navigatie-eigenschap naar module-specifieke rechten.
|
||||
|
||||
## 2. RefreshToken
|
||||
|
||||
- **Id**: Guid.
|
||||
- **Token**: De gehashte token string.
|
||||
- **UserId**: Link naar de `ApplicationUser`.
|
||||
- **ExpiryDate**: Wanneer het token verloopt.
|
||||
- **IsUsed**: Boolean (voor re-use detection).
|
||||
- **IsRevoked**: Boolean (handmatige intrekking).
|
||||
- **CreatedByIp**: IP adres voor audit trail.
|
||||
|
||||
## 3. Invitation
|
||||
|
||||
- **Email**: Adres waar de uitnodiging naar verzonden is.
|
||||
- **Role**: De toegekende rol na acceptatie.
|
||||
- **Token**: Unieke GUID/String.
|
||||
- **ExpiryDate**: Geldigheidsduur van de uitnodiging.
|
||||
- **IsAccepted**: Boolean.
|
||||
|
||||
## 4. ModulePermission
|
||||
|
||||
- **UserId**: Link naar `ApplicationUser`.
|
||||
- **ModuleName**: Naam van de module.
|
||||
- **Permission**: De specifieke string-gebaseerde permissie (bijv. "Write", "Admin").
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
# Business Logic Model — Unit 02: Identity & RBAC
|
||||
|
||||
Dit document beschrijft de processen en datastromen voor authenticatie en autorisatie.
|
||||
|
||||
## 1. Authenticatie Flow (JWT)
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Client
|
||||
participant AuthController
|
||||
participant AuthService
|
||||
participant UserManager
|
||||
participant Database
|
||||
|
||||
Client->>AuthController: Login(Email, Password)
|
||||
AuthController->>AuthService: AuthenticateAsync(Email, Password)
|
||||
AuthService->>UserManager: FindByEmailAsync(Email)
|
||||
UserManager->>Database: Get User
|
||||
Database-->>UserManager: User Data
|
||||
UserManager->>UserManager: CheckPasswordAsync(User, Password)
|
||||
AuthService->>AuthService: GenerateTokens(User)
|
||||
AuthService->>Database: Save RefreshToken
|
||||
AuthService-->>AuthController: AccessToken, RefreshToken
|
||||
AuthController-->>Client: 200 OK (Tokens)
|
||||
```
|
||||
|
||||
## 2. Uitnodigingsproces
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Admin/Owner] -->|Create Invitation| B(InvitationService)
|
||||
B -->|Generate Token| C(InvitationToken)
|
||||
C -->|Save to DB| D[(Database)]
|
||||
B -->|Send Email| E[User]
|
||||
E -->|Click Link| F[Setup Page]
|
||||
F -->|Submit Password + Token| G(SetupController)
|
||||
G -->|Validate Token| B
|
||||
B -->|Create Account| H(UserManager)
|
||||
H -->|Activate User| D
|
||||
```
|
||||
|
||||
## 3. Hiërarchische Autorisatie Logic
|
||||
|
||||
De autorisatie wordt afgehandeld via ASP.NET Core `AuthorizationPolicies`.
|
||||
|
||||
- **Policy: `RequireLowerRole`**:
|
||||
- Haalt de rol van de huidige gebruiker (X) en de doelgebruiker (Y) op.
|
||||
- Vergelijkt de numerieke waarden van de rollen.
|
||||
- Slaagt alleen als `RoleValue(X) > RoleValue(Y)` (of `X == Y` en `X == Owner`).
|
||||
|
||||
## 4. Token Refresh Logic
|
||||
|
||||
1. Client stuurt `Expired Access Token` + `Refresh Token`.
|
||||
2. Systeem controleert of `Refresh Token` bestaat in de database en niet verlopen is.
|
||||
3. Systeem controleert of `Refresh Token` al eerder is gebruikt (Re-use detection).
|
||||
4. Indien geldig:
|
||||
- Genereer nieuw `Access Token`.
|
||||
- Genereer nieuw `Refresh Token` (Rotation).
|
||||
- Verwijder/Invalideer het oude `Refresh Token`.
|
||||
5. Indien ongeldig of re-use:
|
||||
- Trek alle tokens van de gebruiker in.
|
||||
- Retourneer `401 Unauthorized`.
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
# Auth Service Design — Unit 02: Identity & RBAC
|
||||
|
||||
Dit document beschrijft de `IAuthService` die verantwoordelijk is voor token-management.
|
||||
|
||||
## 1. Interface definitie
|
||||
|
||||
```csharp
|
||||
public interface IAuthService
|
||||
{
|
||||
Task<TokenResponse> AuthenticateAsync(string email, string password);
|
||||
Task<TokenResponse> RefreshTokenAsync(string accessToken, string refreshToken);
|
||||
Task RevokeTokenAsync(string refreshToken);
|
||||
}
|
||||
```
|
||||
|
||||
## 2. JWT Configuratie
|
||||
|
||||
- **Signing Key**: Wordt uit de environment variable `JWT_SIGNING_KEY` gelezen.
|
||||
- **Issuer/Audience**: Worden geconfigureerd in `appsettings.json`.
|
||||
- **Claims**:
|
||||
- `sub`: UserId.
|
||||
- `email`: Gebruikers e-mail.
|
||||
- `role`: Gebruikers rol (bijv. "Administrator").
|
||||
- `exp`: Expiration time.
|
||||
|
||||
## 3. Refresh Token Rotation Logic
|
||||
|
||||
Bij een refresh request:
|
||||
1. Valideer de `refreshToken` string tegen de database.
|
||||
2. Controleer op Re-use: Indien de `IsUsed` vlag al op `true` staat, trek dan **alle** tokens van die gebruiker in (NFR-ID-SEC-03).
|
||||
3. Indien geldig:
|
||||
- Markeer huidig token als `IsUsed = true`.
|
||||
- Genereer een nieuw cryptografisch veilig geheim (32 bytes Base64).
|
||||
- Sla het nieuwe token op met een nieuwe `ExpiryDate`.
|
||||
- Retourneer het nieuwe `AccessToken` en `RefreshToken`.
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# Authorization Design — Unit 02: Identity & RBAC
|
||||
|
||||
Dit document beschrijft de technische implementatie van de hiërarchische autorisatie.
|
||||
|
||||
## 1. HierarchicalRoleRequirement
|
||||
|
||||
We maken gebruik van een custom requirement om rollen te vergelijken.
|
||||
|
||||
```csharp
|
||||
public class HierarchicalRoleRequirement : IAuthorizationRequirement
|
||||
{
|
||||
public HierarchicalRoleRequirement(string minimumRequiredRole)
|
||||
{
|
||||
MinimumRequiredRole = minimumRequiredRole;
|
||||
}
|
||||
|
||||
public string MinimumRequiredRole { get; }
|
||||
}
|
||||
```
|
||||
|
||||
## 2. HierarchicalRoleHandler
|
||||
|
||||
De handler valideert of de rollen-hiërarchie wordt gerespecteerd.
|
||||
|
||||
- **Logic**:
|
||||
1. Haal de rol-claim op van de huidige gebruiker.
|
||||
2. Haal de doel-gebruiker op uit de route of body.
|
||||
3. Vergelijk de numerieke waarden van beide rollen.
|
||||
4. Slaag alleen als de huidige gebruiker een hogere of gelijke rol heeft (afhankelijk van de actie).
|
||||
|
||||
## 3. Setup Endpoint Protection
|
||||
|
||||
Het `SetupController.Init` endpoint controleert direct in de database of er al een Owner bestaat:
|
||||
|
||||
```csharp
|
||||
[HttpPost("init")]
|
||||
public async Task<IActionResult> Init(SetupRequest request)
|
||||
{
|
||||
var anyOwner = await _userManager.GetUsersInRoleAsync("Owner");
|
||||
if (anyOwner.Any())
|
||||
{
|
||||
return Forbidden("Systeem is reeds geïnitialiseerd.");
|
||||
}
|
||||
// Verwerk creatie...
|
||||
}
|
||||
```
|
||||
|
||||
## 4. Module-specifieke Policies
|
||||
|
||||
Er worden dynamische policies aangemaakt voor module-permissies:
|
||||
- Patroon: `Module:{ModuleName}:{Permission}` (bijv. `Module:Blog:Delete`).
|
||||
- De handler controleert de `ModulePermissions` tabel voor de huidige gebruiker.
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# Database Design — Unit 02: Identity & RBAC
|
||||
|
||||
Dit document beschrijft de database schema configuratie voor de identiteitsmodule.
|
||||
|
||||
## 1. DbContext Mapping (Identity)
|
||||
|
||||
De `ApplicationDbContext` erft over van `IdentityDbContext<ApplicationUser, IdentityRole<Guid>, Guid>`.
|
||||
In `OnModelCreating` worden de tabelnamen geconfigureerd:
|
||||
|
||||
```csharp
|
||||
protected override void OnModelCreating(ModelBuilder builder)
|
||||
{
|
||||
base.OnModelCreating(builder);
|
||||
|
||||
builder.Entity<ApplicationUser>(entity => { entity.ToTable("Users"); });
|
||||
builder.Entity<IdentityRole<Guid>>(entity => { entity.ToTable("Roles"); });
|
||||
builder.Entity<IdentityUserRole<Guid>>(entity => { entity.ToTable("UserRoles"); });
|
||||
builder.Entity<IdentityUserClaim<Guid>>(entity => { entity.ToTable("UserClaims"); });
|
||||
builder.Entity<IdentityUserLogin<Guid>>(entity => { entity.ToTable("UserLogins"); });
|
||||
builder.Entity<IdentityRoleClaim<Guid>>(entity => { entity.ToTable("RoleClaims"); });
|
||||
builder.Entity<IdentityUserToken<Guid>>(entity => { entity.ToTable("UserTokens"); });
|
||||
}
|
||||
```
|
||||
|
||||
## 2. Aanvullende Tabellen
|
||||
|
||||
### RefreshTokens
|
||||
- **Tabel**: `RefreshTokens`
|
||||
- **PK**: `Id` (Guid)
|
||||
- **FK**: `UserId` -> `Users.Id`
|
||||
- **Index**: `Token` (Unique)
|
||||
|
||||
### Invitations
|
||||
- **Tabel**: `Invitations`
|
||||
- **PK**: `Id` (Guid)
|
||||
- **Index**: `Token` (Unique)
|
||||
- **Email**: `NVARCHAR(256)`
|
||||
|
||||
### ModulePermissions
|
||||
- **Tabel**: `ModulePermissions`
|
||||
- **Composite PK**: `(UserId, ModuleName, Permission)`
|
||||
- **FK**: `UserId` -> `Users.Id`
|
||||
|
||||
## 3. Auditing (NFR-ID-SEC-03)
|
||||
|
||||
Er wordt een aparte `AuditLogs` tabel aangemaakt voor het loggen van mutaties:
|
||||
- `Id` (Guid)
|
||||
- `Timestamp` (DateTimeOffset)
|
||||
- `ActorId` (Guid - De uitvoerder)
|
||||
- `Action` (String - bijv. "RoleChange", "UserCreated")
|
||||
- `EntityId` (Guid - Het doelobject)
|
||||
- `Details` (JSON/String - Oude vs Nieuwe waarden)
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
# Invitation Design — Unit 02: Identity & RBAC
|
||||
|
||||
Dit document beschrijft de technische implementatie van het uitnodigingssysteem.
|
||||
|
||||
## 1. IInvitationService
|
||||
|
||||
```csharp
|
||||
public interface IInvitationService
|
||||
{
|
||||
Task<string> CreateInvitationAsync(string email, string role);
|
||||
Task<bool> ValidateInvitationAsync(string token);
|
||||
Task CompleteInvitationAsync(string token, string password);
|
||||
}
|
||||
```
|
||||
|
||||
## 2. Token Generatie
|
||||
|
||||
Het `InvitationToken` wordt gegenereerd met de `RandomNumberGenerator`:
|
||||
|
||||
```csharp
|
||||
public string GenerateSecureToken()
|
||||
{
|
||||
var bytes = new byte[32];
|
||||
RandomNumberGenerator.Fill(bytes);
|
||||
return Convert.ToBase64String(bytes);
|
||||
}
|
||||
```
|
||||
|
||||
## 3. Workflow Details
|
||||
|
||||
1. **Creatie**:
|
||||
- Een `Invitation` record wordt aangemaakt in de database.
|
||||
- Het `Token` wordt gehasht opgeslagen (net als een wachtwoord) om misbruik bij database-lekken te voorkomen.
|
||||
2. **Validatie**:
|
||||
- Het systeem zoekt het record op basis van de token-string.
|
||||
- Controleert `ExpiryDate` en `IsAccepted`.
|
||||
3. **Afronding**:
|
||||
- Bij `CompleteInvitationAsync` wordt de `ApplicationUser` aangemaakt via de `UserManager`.
|
||||
- De rol wordt toegekend.
|
||||
- Het uitnodigingsrecord wordt gemarkeerd als `IsAccepted = true`.
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
# NFR Requirements — Unit 02: Identity & RBAC
|
||||
|
||||
Dit document specificeert de non-functionele vereisten voor identiteitsbeheer en autorisatie.
|
||||
|
||||
## 1. Beveiliging (Security)
|
||||
|
||||
- **ID-SEC-01: Wachtwoordbeleid**:
|
||||
- Minimale lengte: 8 tekens.
|
||||
- Geen verplichte complexiteitseisen (hoofdletters/cijfers), focus op lengte voor gebruiksvriendelijkheid.
|
||||
- **ID-SEC-02: Token Lifecycle**:
|
||||
- Access Token (JWT) vervaltijd: 1 uur.
|
||||
- Refresh Token vervaltijd: 7 dagen.
|
||||
- **ID-SEC-03: Audit Logging**:
|
||||
- Verplichte persistente logging van:
|
||||
- Gebruikerscreatie en uitnodigingen.
|
||||
- Rolwijzigingen.
|
||||
- Activatie/Deactivatie van accounts.
|
||||
- Mislukte login pogingen.
|
||||
- **ID-SEC-04: Data Privacy**:
|
||||
- Wachtwoorden worden nooit in plain-text opgeslagen.
|
||||
- Persoonlijke gegevens (PII) worden alleen via HTTPS ontsloten.
|
||||
|
||||
## 2. Performance
|
||||
|
||||
- **ID-PERF-01: Token Validatie**:
|
||||
- De validatie van het JWT token bij elk request mag niet meer dan 5ms overhead toevoegen.
|
||||
- **ID-PERF-02: Database Querying**:
|
||||
- Het ophalen van een gebruiker inclusief rollen en permissies moet binnen 20ms gebeuren (geïndexeerd op Email).
|
||||
|
||||
## 3. Onderhoudbaarheid (Maintainability)
|
||||
|
||||
- **ID-MAINT-01: Database Schema**:
|
||||
- Gebruik van schone tabelnamen zonder `AspNet` prefix (bijv. `Users`, `Roles`, `UserRoles`).
|
||||
- **ID-MAINT-02: EF Core Migrations**:
|
||||
- Alle wijzigingen aan het identiteitsschema worden via code-first migrations bijgehouden.
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
# Tech Stack Decisions — Unit 02: Identity & RBAC
|
||||
|
||||
Dit document beschrijft de definitieve technische keuzes voor Unit 02.
|
||||
|
||||
## 1. Core Frameworks
|
||||
|
||||
- **Identity**: Microsoft.AspNetCore.Identity.
|
||||
- **ORM**: Entity Framework Core.
|
||||
- **Database**: Microsoft SQL Server.
|
||||
|
||||
## 2. Authenticatie & Autorisatie
|
||||
|
||||
- **JWT Library**: Microsoft.AspNetCore.Authentication.JwtBearer.
|
||||
- **Policy Engine**: Native ASP.NET Core Authorization Policies & RequirementHandlers.
|
||||
- **Hashing**: PBKDF2 (standaard Identity).
|
||||
|
||||
## 3. Database Schema Mapping
|
||||
|
||||
Conform ID-MAINT-01 worden de standaard Identity tabellen hernoemd in de `OnModelCreating` van de `DbContext`:
|
||||
|
||||
| Standaard Naam | Nieuwe Naam |
|
||||
|---|---|
|
||||
| AspNetUsers | Users |
|
||||
| AspNetRoles | Roles |
|
||||
| AspNetUserRoles | UserRoles |
|
||||
| AspNetUserClaims | UserClaims |
|
||||
| AspNetUserLogins | UserLogins |
|
||||
| AspNetRoleClaims | RoleClaims |
|
||||
| AspNetUserTokens | UserTokens |
|
||||
|
||||
## 4. Testing Tools
|
||||
|
||||
- **Unit Tests**: xUnit + FluentAssertions + NSubstitute.
|
||||
- **Data Generation**: AutoFixture.
|
||||
- **PBT**: FsCheck (alleen voor token-logic en mapping functies, conform NFR-06).
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
# Code Generation Plan — Unit 04: API Shell & Integration
|
||||
|
||||
Dit plan beschrijft de stappen voor de implementatie van de API Shell in `SlpModularCms.Api`.
|
||||
|
||||
## Implementatie Stappen
|
||||
|
||||
### 1. Voorbereiding & NuGet
|
||||
- [x] Toevoegen van NuGet packages aan `SlpModularCms.Api`:
|
||||
- `Asp.Versioning.Mvc`
|
||||
- `Swashbuckle.AspNetCore`
|
||||
- `Microsoft.AspNetCore.Authentication.JwtBearer`
|
||||
- [x] Referenties toevoegen naar:
|
||||
- `SlpModularCms.Core`
|
||||
- `SlpModularCms.Modules.Availability` (Indien niet dynamisch geladen)
|
||||
|
||||
### 2. Orkestratie & Infrastructuur
|
||||
- [x] Implementeren van de `ApiPrefixConvention`.
|
||||
- [x] Implementeren van de `ModuleOrchestrator` (Service Discovery).
|
||||
- [x] Implementeren van extensie methoden voor `IServiceCollection` en `IApplicationBuilder`.
|
||||
|
||||
### 3. Program.cs Configuratie
|
||||
- [x] Configureren van de Exception Handler middleware (Unit 01).
|
||||
- [x] Configureren van de Availability middleware (Unit 03).
|
||||
- [x] Configureren van JWT Bearer authenticatie (Unit 02).
|
||||
- [x] Configureren van de `ModuleOrchestrator` in de startup flow.
|
||||
- [x] Opzetten van Swagger met JWT support en module tagging.
|
||||
|
||||
### 4. Validatie
|
||||
- [x] Opstarten van de API en verifiëren van de `/swagger` pagina.
|
||||
- [x] Verifiëren dat `/api/v1/availability/status` werkt.
|
||||
|
||||
## Volgende Stappen
|
||||
Na de implementatie volgt de finale integratietest.
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# Functional Design Plan — Unit 04: API Shell & Integration
|
||||
|
||||
Dit plan beschrijft de stappen voor het functioneel ontwerpen van de API Shell (Unit 04), die alle modules samenbrengt.
|
||||
|
||||
## Functional Design Stappen
|
||||
- [x] Ontwerpen van de `ModuleOrchestrator` voor dynamische discovery en registratie.
|
||||
- [x] Definiëren van de globale `Program.cs` structuur (Dependency Injection & Pipeline).
|
||||
- [x] Uitwerken van de JWT Bearer configuratie en Swagger integratie.
|
||||
- [x] Ontwerpen van de globale foutafhandeling integratie (GlobalExceptionHandler).
|
||||
- [x] Opstellen van de integratie-regels voor cross-module communicatie.
|
||||
|
||||
## Vragen voor Functional Design (Unit 04)
|
||||
|
||||
### 1. Swagger Documentatie
|
||||
**Vraag 1.1**: Hoe moeten de verschillende modules in Swagger worden weergegeven?
|
||||
- A) **Gecombineerd**: Eén grote lijst met alle endpoints van alle modules door elkaar.
|
||||
- B) **Gegroepeerd per Module**: Gebruik Swagger 'Docs' of 'Tags' om endpoints per module (bijv. Identity, Availability) te groeperen.
|
||||
|
||||
### 2. Startup Volgorde
|
||||
**Vraag 2.1**: Moeten modules in een specifieke volgorde geladen worden?
|
||||
- A) Nee, de volgorde is willekeurig (behalve Core).
|
||||
- B) Ja, we hebben een expliciete `LoadOrder` eigenschap nodig in de `IModule` interface.
|
||||
|
||||
### 3. API Versiebeheer
|
||||
**Vraag 3.1**: Moeten we API Versioning (bijv. `/api/v1/...`) direct integreren in de Shell?
|
||||
- A) Ja, configureer globale versiebeheer (v1) voor de hele API.
|
||||
- B) Nee, voor de MVP is geen versiebeheer nodig in het pad.
|
||||
|
||||
## Volgende Stappen
|
||||
Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/api-shell/functional-design/`.
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# NFR Design Plan — Unit 04: API Shell & Integration
|
||||
|
||||
Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor de API Shell (Unit 04).
|
||||
|
||||
## NFR Design Stappen
|
||||
- [x] Ontwerpen van de `ModuleOrchestrator` scanning logica.
|
||||
- [x] Uitwerken van de Swagger configuratie voor JWT en module groepering.
|
||||
- [x] Definiëren van de API Versioning configuratie (v1 prefix).
|
||||
- [x] Ontwerpen van de globale CORS policy configuratie.
|
||||
- [x] Vastleggen van de `Program.cs` extensie methoden voor module registratie.
|
||||
|
||||
## Vragen voor NFR Design (Unit 04)
|
||||
|
||||
### 1. Module Discovery Foutafhandeling
|
||||
**Vraag 1.1**: Wat moet er gebeuren als een module niet geladen kan worden (bijv. door een ontbrekende afhankelijkheid)?
|
||||
- A) **Fail Fast**: De hele API weigert op te starten. Meest veilig voor consistentie.
|
||||
- B) **Soft Fail**: Log de fout, sla de module over en start de rest van de API wel op.
|
||||
|
||||
### 2. Route Prefixing
|
||||
**Vraag 2.1**: Hoe moeten we de `/api/v1/` prefix afdwingen?
|
||||
- A) **Expliciet**: In elke Controller route attribuut (bijv. `[Route("api/v1/[controller]")]`).
|
||||
- B) **Globaal**: Via een `IApplicationModelConvention` in de Shell die alle routes automatisch prefixen.
|
||||
|
||||
### 3. Swagger Documentatie Locatie
|
||||
**Vraag 3.1**: Waar moet de Swagger UI bereikbaar zijn?
|
||||
- A) In de root (`/`).
|
||||
- B) Op het standaard pad (`/swagger`).
|
||||
|
||||
## Volgende Stappen
|
||||
Na beantwoording van deze vragen worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/api-shell/nfr-design/`.
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# NFR Requirements Plan — Unit 04: API Shell & Integration
|
||||
|
||||
Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor de API Shell (Unit 04).
|
||||
|
||||
## NFR Assessment Stappen
|
||||
- [x] Vaststellen van de performance targets voor de startup tijd (module discovery).
|
||||
- [x] Definiëren van de security baseline voor CORS en HTTPS.
|
||||
- [x] Keuze van de tech stack voor API Versioning en Swagger documentatie.
|
||||
- [x] Bepalen van de logging aggregatie strategie (centraal vs per module).
|
||||
|
||||
## NFR Vragen voor Unit 04
|
||||
|
||||
### 1. Startup Performance
|
||||
**Vraag 1.1**: Wat is de maximaal acceptabele startup tijd van de API (inclusief module scanning)?
|
||||
- A) **Snel**: < 2 seconden.
|
||||
- B) **Gemiddeld**: 2-5 seconden.
|
||||
- C) **Niet kritisch**: > 5 seconden (geschikt voor monolithische startup).
|
||||
|
||||
### 2. CORS Beleid
|
||||
**Vraag 2.1**: Hoe strikt moet het CORS beleid zijn voor de MVP?
|
||||
- A) **Permissief**: Sta alle origins toe (`*`).
|
||||
- B) **Standaard**: Alleen specifieke, geconfigureerde origins toestaan via `appsettings.json`.
|
||||
- C) **Strikt**: Geen CORS ondersteuning (alleen same-origin).
|
||||
|
||||
### 3. API Documentatie
|
||||
**Vraag 3.1**: Welke Swagger UI functies moeten ingeschakeld worden?
|
||||
- A) **Volledig**: Inclusief "Try it out" en JWT Bearer authenticatie ondersteuning.
|
||||
- B) **Read-only**: Alleen documentatie, geen interactie mogelijk.
|
||||
|
||||
## Volgende Stappen
|
||||
Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/api-shell/nfr-requirements/`.
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
# Code Generation Plan — Unit 03: Availability Module
|
||||
|
||||
Dit plan beschrijft de stappen voor de implementatie van de Availability Module (Unit 03).
|
||||
|
||||
## Implementatie Stappen
|
||||
|
||||
### 1. Project Creatie
|
||||
- [x] Aanmaken van `src/SlpModularCms.Modules.Availability` (Class Library).
|
||||
- [x] Toevoegen aan de solution.
|
||||
- [x] Referentie toevoegen naar `SlpModularCms.Core`.
|
||||
|
||||
### 2. Domein Model & Data
|
||||
- [x] Implementeren van de `GlobalAvailabilityState` entiteit.
|
||||
- [x] Toevoegen van de entiteit aan de `ApplicationDbContext` (via een gedeeld interface of direct). *Noot: De DbContext zit in Core, dus we moeten mogelijk de entiteit ook in Core plaatsen of de DbContext uitbreiden via een module-extensie.*
|
||||
|
||||
### 3. Services & Middleware
|
||||
- [x] Implementeren van `PersistentAvailabilityService` (in de module).
|
||||
- [x] Implementeren van de `AvailabilityMiddleware` (in de module of Shell).
|
||||
- [x] Implementeren van de `AvailabilityController`.
|
||||
|
||||
### 4. Testing
|
||||
- [x] Aanmaken van `SlpModularCms.Modules.Availability.Tests`.
|
||||
- [x] Testen van de middleware blokkade en de circuit breaker logica.
|
||||
|
||||
## Volgende Stappen
|
||||
Na de project-setup volgt de implementatie van de service en middleware.
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# Functional Design Plan — Unit 03: Availability Module
|
||||
|
||||
Dit plan beschrijft de stappen voor het functioneel ontwerpen van de Availability Module (Unit 03).
|
||||
|
||||
## Functional Design Stappen
|
||||
- [x] Definiëren van de `StubAvailabilityService` gedrag (altijd beschikbaar in MVP).
|
||||
- [x] Ontwerpen van de `AvailabilityController` voor publieke status check.
|
||||
- [x] Uitwerken van de "Remote Shutdown" interface (placeholder).
|
||||
- [x] Opstellen van de business rules voor beschikbaarheids-gebaseerde toegang.
|
||||
|
||||
## Vragen voor Functional Design (Unit 03)
|
||||
|
||||
### 1. Beschikbaarheidsstatus
|
||||
**Vraag 1.1**: Welke informatie moet het publieke `GET /api/availability/status` endpoint teruggeven?
|
||||
- A) **Simpel**: Alleen een boolean `isAvailable`.
|
||||
- B) **Gedetailleerd**: Een status string (`Available`, `Maintenance`, `Degraded`) en een timestamp.
|
||||
- C) **Extended**: Inclusief versie informatie van de API en geladen modules.
|
||||
|
||||
### 2. Remote Shutdown Mechanisme
|
||||
**Vraag 2.1**: Voor de toekomstige "remote shutdown" functionaliteit (FR-05): hoe moet dit mechanisme in de architectuur verankerd worden?
|
||||
- A) **Middleware**: Een globale middleware die de `IAvailabilityService` checkt bij elk request en 503 Service Unavailable retourneert indien niet beschikbaar.
|
||||
- B) **Filter**: Een globaal Action Filter voor controllers.
|
||||
- C) **Manual Check**: Modules checken zelf de status indien nodig (niet aanbevolen voor consistentie).
|
||||
|
||||
### 3. Bypass voor Beheerders
|
||||
**Vraag 3.1**: Mogen Beheerders en Owners de API nog wel gebruiken als de status op "Niet Beschikbaar" staat (bijv. voor onderhoud)?
|
||||
- A) Ja, Beheerders/Owners moeten altijd toegang hebben om het systeem te kunnen herstellen.
|
||||
- B) Nee, als het systeem uit staat, staat het voor iedereen uit.
|
||||
|
||||
## Volgende Stappen
|
||||
Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/availability-module/functional-design/`.
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# NFR Design Plan — Unit 03: Availability Module
|
||||
|
||||
Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor Unit 03.
|
||||
|
||||
## NFR Design Stappen
|
||||
- [x] Ontwerpen van de `AvailabilityMiddleware` en de bypass logica.
|
||||
- [x] Definiëren van de `PersistentAvailabilityService` implementatie.
|
||||
- [x] Uitwerken van het database schema voor de globale status.
|
||||
- [x] Ontwerpen van de `AvailabilityController` endpoints (publiek status, beheer status).
|
||||
- [x] Vastleggen van de integratie met de `AuditLogs` (Unit 02).
|
||||
|
||||
## Vragen voor NFR Design (Unit 03)
|
||||
|
||||
### 1. Middleware Registratie
|
||||
**Vraag 1.1**: Waar moet de `AvailabilityMiddleware` in de pipeline worden geplaatst?
|
||||
- A) **Helemaal vooraan**: Zelfs vóór de exception handler en logging (maximaal effectief, maar minder informatie bij fouten).
|
||||
- B) **Na de Exception Handler**: Fouten in de check worden dan netjes afgevangen door de globale handler (Aanbevolen).
|
||||
- C) **Na Authentication**: Dan weten we al wie de gebruiker is (nodig voor de bypass check), maar dan is de authenticatie overhead al geweest voor geblokkeerde requests.
|
||||
|
||||
### 2. Status Update Endpoint
|
||||
**Vraag 2.1**: Hoe moet het endpoint voor het wijzigen van de status beveiligd worden?
|
||||
- A) **Policy-based**: Gebruik de `OwnerOnly` policy (Unit 02).
|
||||
- B) **Internal-only**: Alleen bereikbaar vanaf de lokale host of via een intern netwerk (minder flexibel voor cloud beheer).
|
||||
|
||||
### 3. Fallback Gedrag (Circuit Breaker)
|
||||
**Vraag 3.1**: Als de database herhaaldelijk onbereikbaar is voor de status-check, hoe lang moet de fallback status (`Available`) worden aangehouden voordat we het opnieuw proberen?
|
||||
- A) Elke request opnieuw proberen.
|
||||
- B) Implementeer een eenvoudige circuit breaker (bijv. 30 seconden fallback na 3 opeenvolgende fouten).
|
||||
|
||||
## Volgende Stappen
|
||||
Na beantwoording van deze vragen worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/availability-module/nfr-design/`.
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# NFR Requirements Plan — Unit 03: Availability Module
|
||||
|
||||
Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor de Availability Module (Unit 03).
|
||||
|
||||
## NFR Assessment Stappen
|
||||
- [x] Vaststellen van de performance overhead van de Availability Middleware.
|
||||
- [x] Definiëren van de betrouwbaarheidseisen voor de status check (bijv. caching).
|
||||
- [x] Beveiligen van het onderhouds-bypass mechanisme.
|
||||
- [x] Keuze van de opslag voor de dynamische status (Config vs Cache vs Database).
|
||||
|
||||
## NFR Vragen voor Unit 03
|
||||
|
||||
### 1. Performance
|
||||
**Vraag 1.1**: Wat is de maximale toegestane latency die de Availability Middleware mag toevoegen aan elk request?
|
||||
- A) **Ultra-laag**: < 1ms (vereist in-memory check zonder database/I/O).
|
||||
- B) **Laag**: 1-5ms (staat een snelle cache of config check toe).
|
||||
- C) **Gemiddeld**: < 10ms.
|
||||
|
||||
### 2. Status Opslag & Wijziging
|
||||
**Vraag 2.1**: Hoe moet een beheerder de status van de API kunnen wijzigen in de MVP?
|
||||
- A) **Static**: Alleen via `appsettings.json` (vereist herstart of config-reload).
|
||||
- B) **Dynamic (In-Memory)**: Via een specifiek (beveiligd) endpoint dat de status in het geheugen aanpast (gaat verloren bij herstart).
|
||||
- C) **Persistent**: Via de database, zodat de status over herstarts heen behouden blijft.
|
||||
|
||||
### 3. Caching
|
||||
**Vraag 3.1**: Moet de resultaat van de beschikbaarheidscheck gecached worden in de middleware?
|
||||
- A) Nee, altijd de actuele status ophalen via de service.
|
||||
- B) Ja, voor een korte duur (bijv. 1 seconde) om performance te optimaliseren bij hoge belasting.
|
||||
|
||||
## Volgende Stappen
|
||||
Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/availability-module/nfr-requirements/`.
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
# Code Generation Plan — Unit 01: Core Base
|
||||
|
||||
Dit plan beschrijft de stappen voor de initiële implementatie van de Core Base (Unit 01).
|
||||
|
||||
## Implementatie Stappen
|
||||
- [x] Aanmaken van het `SlpModularCms.Core` class library project.
|
||||
- [x] Toevoegen van het project aan de solution (`SlpModularCms.sln`).
|
||||
- [x] Implementeren van de basis types en interfaces (Functional Design):
|
||||
- [x] `IModule`
|
||||
- [x] `IAvailabilityService`
|
||||
- [x] `AvailabilityStatus` (Enum)
|
||||
- [x] `ModuleInfo` (Record)
|
||||
- [x] Implementeren van de NFR componenten (NFR Design):
|
||||
- [x] `GlobalExceptionHandler` (IExceptionHandler)
|
||||
- [x] `ApiErrorResponse`
|
||||
- [x] `ModuleOrchestrator` interfaces en basis logica (Verplaatst naar U04 Shell).
|
||||
- [x] Opzetten van het Unit Test project `SlpModularCms.Core.Tests`.
|
||||
- [x] Implementeren van de eerste unit tests voor de Exception Handler en Availability Service.
|
||||
|
||||
## Vragen voor Code Generation (Unit 01)
|
||||
1. **Namespace**: Gaan we akkoord met de namespace `SlpModularCms.Core` voor de basis types?
|
||||
2. **Project Locatie**: De `unit-of-work.md` suggereerde `src/SlpModularCms.Core/`. Moet deze map aangemaakt worden in de root? (Huidige root bevat al `SlpModularCms.Api/` direct in de root).
|
||||
|
||||
## Volgende Stappen
|
||||
Na bevestiging van de projectstructuur start de daadwerkelijke code generatie.
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
# Functional Design Plan — Unit 01: Core Base
|
||||
|
||||
Dit plan beschrijft het gedetailleerde functionele ontwerp voor het fundament van de SlpModularCms API.
|
||||
|
||||
## Stap 1: Business Logic Modeling
|
||||
- [x] Modelleren van de module-levenscyclus (Discovery -> Registration -> Initialisation).
|
||||
- [x] Beschrijven van de orkestratie tussen de API Shell en de Core Base interfaces.
|
||||
|
||||
## Stap 2: Domain Entities & Interfaces
|
||||
- [x] Definiëren van de `IModule` interface structureel.
|
||||
- [x] Definiëren van de `IAvailabilityService` contracten.
|
||||
- [x] Modelleren van gedeelde DTO's (bijv. `AvailabilityDetails`).
|
||||
- [x] Genereer `aidlc-docs/construction/core-base/functional-design/domain-entities.md`.
|
||||
|
||||
## Stap 3: Business Rules & Validation
|
||||
- [x] Vastleggen van validatieregels voor module-namen en versies.
|
||||
- [x] Definiëren van de standaard "IsAvailable" logica (fallback gedrag).
|
||||
- [x] Genereer `aidlc-docs/construction/core-base/functional-design/business-rules.md`.
|
||||
|
||||
## Stap 4: Data Flow & Error Handling
|
||||
- [x] Ontwerpen van de globale exception-to-response mapping.
|
||||
- [x] Beschrijven van de dataflow voor cross-cutting concerns (logging context).
|
||||
- [x] Genereer `aidlc-docs/construction/core-base/functional-design/business-logic-model.md`.
|
||||
|
||||
---
|
||||
|
||||
## Vragen voor Functional Design (Core Base)
|
||||
|
||||
### Vraag 1: Module Identificatie
|
||||
Welke metadata moet elke module verplicht opgeven bij registratie?
|
||||
A) Minimale set: Alleen een unieke `Name`.
|
||||
B) Uitgebreid: `Name`, `Version`, `Description` en `Dependencies` (lijst met namen van andere modules).
|
||||
C) Dynamisch: De module bepaalt zelf welke metadata hij exposeert via een dictionary.
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: B
|
||||
|
||||
### Vraag 2: Exception Handling Strategie
|
||||
Hoe moeten domein-specifieke exceptions (bijv. `ModuleNotFoundException`) functioneel worden vertaald naar de buitenwereld?
|
||||
A) Uniform: Alle exceptions mappen naar een generiek fout-object met een `Code` en `Message`.
|
||||
B) Gedetailleerd: Elke exception heeft een eigen response model met specifieke velden voor debug-informatie.
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: B
|
||||
|
||||
### Vraag 3: Availability Fallback
|
||||
Als een module de `IAvailabilityService` niet expliciet implementeert, wat moet het standaard gedrag van de Core Base zijn?
|
||||
A) Optimistisch: Altijd `true` retourneren (beschikbaar).
|
||||
B) Pessimistisch: `false` retourneren (niet beschikbaar totdat expliciet aangezet).
|
||||
C) Foutmelding: De applicatie mag niet starten als een module geen statuscontrole heeft.
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: X, de availability wordt voor de hele API gecontroleerd, niet per module
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# NFR Design Plan — Unit 01: Core Base
|
||||
|
||||
Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor Unit 01.
|
||||
|
||||
## NFR Design Stappen
|
||||
- [x] Ontwerpen van de `GlobalExceptionMiddleware` en de `ApiErrorResponse` mapping (SEC-01).
|
||||
- [x] Definiëren van de `IModule` interface en de dynamische discovery logica (PERF-01).
|
||||
- [x] Uitwerken van de `IAvailabilityService` decorator of middleware voor timeouts en fallback (AVAIL-01).
|
||||
- [x] Vastleggen van de AutoFixture configuratie patronen voor consistente testdata (MAINT-02).
|
||||
- [x] Controleren van de async-consistentie in alle voorgestelde interfaces (PERF-03).
|
||||
|
||||
## Vragen voor NFR Design (Unit 01)
|
||||
|
||||
1. **Exception Mapping**: Willen we gebruik maken van de nieuwe `IExceptionHandler` interface (geïntroduceerd in .NET 8) of de traditionele Middleware aanpak voor de globale foutafhandeling?
|
||||
2. **Module Discovery**: Voor de dynamische discovery: Gaan we uit van assembly scanning op basis van een naamconventie (bijv. `SlpModularCms.Modules.*`) of gebruiken we een specifiek attribuut (`[Module]`) op de entry classes?
|
||||
3. **Availability Timeout**: Moet de timeout voor `IAvailabilityService` globaal geconfigureerd worden via `appsettings.json`, of moet deze per call overschrijfbaar zijn via een `CancellationToken`?
|
||||
|
||||
## Volgende Stappen
|
||||
Na goedkeuring van dit plan (of beantwoording van de vragen), worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/core-base/nfr-design/`.
|
||||
+58
@@ -0,0 +1,58 @@
|
||||
# NFR Requirements Plan — Unit 01: Core Base
|
||||
|
||||
Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor Unit 01 en bevat vragen voor de gebruiker om de technische keuzes te verfijnen.
|
||||
|
||||
## NFR Assessment Stappen
|
||||
- [x] Analyseren van de complexiteit van de module discovery en registration.
|
||||
- [x] Vaststellen van performance targets voor cross-cutting concerns (logging, exception handling).
|
||||
- [x] Definiëren van security constraints voor de API shell en module isolatie.
|
||||
- [x] Keuze van de tech stack componenten voor Unit 01.
|
||||
|
||||
## NFR Vragen voor Unit 01
|
||||
|
||||
### 1. Performance & Schaalbaarheid
|
||||
**Vraag 1.1**: Hoeveel modules verwacht je dat het systeem maximaal zal bevatten in de nabije toekomst?
|
||||
- A) Kleinschalig (1-5 modules)
|
||||
- B) Middelgroot (5-20 modules)
|
||||
- C) Grootschalig (20+ modules)
|
||||
- D) Dynamisch/Onbekend
|
||||
[Answer]: D
|
||||
|
||||
**Vraag 1.2**: Wat is de acceptabele overhead voor de globale exception handling middleware?
|
||||
- A) Minimaal ( < 10ms extra per request)
|
||||
- B) Gemiddeld (10-50ms)
|
||||
- C) Niet kritisch ( > 50ms)
|
||||
[Answer]: C
|
||||
|
||||
### 2. Security
|
||||
**Vraag 2.1**: Welke informatie mag ABSOLUUT NIET in de `Details` dictionary van de `ApiErrorResponse` verschijnen in productie?
|
||||
- A) Alleen stacktraces
|
||||
- B) Stacktraces en interne server IP-adressen/paden
|
||||
- C) Alles wat niet expliciet als 'veilig' is gemarkeerd (White-listing benadering)
|
||||
[Answer]: B
|
||||
|
||||
### 3. Availability & Reliability
|
||||
**Vraag 3.1**: Wat moet de timeout zijn voor de `IAvailabilityService.IsAvailableAsync()` check?
|
||||
- A) Zeer strikt ( < 500ms)
|
||||
- B) Standaard (1-2 seconden)
|
||||
- C) Relaxed ( > 2 seconden)
|
||||
[Answer]: B
|
||||
|
||||
### 4. Tech Stack Keuzes
|
||||
**Vraag 4.1**: Heb je een voorkeur voor een specifieke logging library?
|
||||
- A) Microsoft.Extensions.Logging (Standaard .NET)
|
||||
- B) Serilog (met Structured Logging focus)
|
||||
- C) NLog
|
||||
- D) Geen voorkeur
|
||||
[Answer]: D
|
||||
|
||||
**Vraag 4.2**: Hoe moeten we omgaan met Dependency Injection voor de modules?
|
||||
- A) Alleen de standaard .NET DI container
|
||||
- B) Een krachtigere container zoals Autofac (indien complexe module-overschrijvingen nodig zijn)
|
||||
[Answer]: A
|
||||
|
||||
**Vraag 4.3**: Voor de Unit Tests en Property-Based Testing (PBT), welke libraries wil je gebruiken? (Merk op: PBT is gedeeltelijk ingeschakeld)
|
||||
- A) xUnit + FluentAssertions + FsCheck (voor PBT)
|
||||
- B) xUnit + FluentAssertions + AutoFixture
|
||||
- C) xUnit + Shouldly
|
||||
[Answer]: B
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
# Code Generation Plan — Unit 02: Identity & RBAC
|
||||
|
||||
Dit plan beschrijft de stappen voor de implementatie van de Identity & RBAC module in `SlpModularCms.Core`.
|
||||
|
||||
## Implementatie Stappen
|
||||
|
||||
### 1. Voorbereiding
|
||||
- [x] Toevoegen van NuGet packages:
|
||||
- `Microsoft.AspNetCore.Identity.EntityFrameworkCore`
|
||||
- `Microsoft.EntityFrameworkCore.SqlServer`
|
||||
- `Microsoft.AspNetCore.Authentication.JwtBearer`
|
||||
|
||||
### 2. Domein Model
|
||||
- [x] Implementeren van `ApplicationUser` (erft van `IdentityUser<Guid>`).
|
||||
- [x] Implementeren van `ApplicationRole` (erft van `IdentityRole<Guid>`).
|
||||
- [x] Implementeren van `RefreshToken`, `Invitation`, en `ModulePermission` entiteiten.
|
||||
|
||||
### 3. Data Toegang
|
||||
- [x] Implementeren van `ApplicationDbContext` met de geconfigureerde tabelnamen (Users, Roles, etc.).
|
||||
|
||||
### 4. Services
|
||||
- [x] Implementeren van `IAuthService` voor login en token refresh.
|
||||
- [x] Implementeren van `IInvitationService` voor het uitnodigingsproces.
|
||||
|
||||
### 5. Autorisatie
|
||||
- [x] Implementeren van `HierarchicalRoleRequirement` en `HierarchicalRoleHandler`.
|
||||
|
||||
### 6. Testing
|
||||
- [x] Toevoegen van unit tests voor de Auth en Invitation services.
|
||||
- [x] Toevoegen van tests voor de hiërarchische autorisatie logica.
|
||||
|
||||
## Volgende Stappen
|
||||
Na de implementatie worden alle tests uitgevoerd om de correctheid te verifiëren.
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# Functional Design Plan — Unit 02: Identity & RBAC
|
||||
|
||||
Dit plan beschrijft de stappen voor het functioneel ontwerpen van de Identity & Role-Based Access Control (RBAC) module (Unit 02).
|
||||
|
||||
## Functional Design Stappen
|
||||
- [x] Analyseren van de hiërarchische rollen logica (Eigenaar > Beheerder > Gebruiker).
|
||||
- [x] Ontwerpen van de gebruikersbeheer workflows (aanmaken, wijzigen, verwijderen).
|
||||
- [x] Definiëren van de JWT authenticatie flow (login, token refresh).
|
||||
- [x] Uitwerken van de autorisatie regels voor module-specifieke rechten.
|
||||
- [x] Opstellen van de domein entiteiten (User, Role, Token).
|
||||
|
||||
## Vragen voor Functional Design (Unit 02)
|
||||
|
||||
### 1. Initiële Gebruiker (Bootstrapping)
|
||||
**Vraag 1.1**: Hoe moet de allereerste "Eigenaar" (Owner) van het systeem worden aangemaakt?
|
||||
- A) Via een database seed script bij de eerste start.
|
||||
- B) Via een specifieke configuratie in `appsettings.json`.
|
||||
- C) Via een verborgen/tijdelijk endpoint dat na eerste gebruik wordt gedeactiveerd.
|
||||
|
||||
### 2. Gebruikersuitnodiging (FR-03)
|
||||
**Vraag 2.1**: Voor de creatie van nieuwe gebruikers: welke methode heeft de voorkeur voor de MVP?
|
||||
- A) **Direct**: Beheerder vult e-mail, rol én wachtwoord in. Account is direct actief.
|
||||
- B) **Uitnodiging**: Beheerder vult e-mail en rol in; systeem genereert een tijdelijk token/link waarmee de gebruiker zelf een wachtwoord instelt.
|
||||
|
||||
### 3. Hiërarchie Handhaving
|
||||
**Vraag 3.1**: Waar moet de hiërarchie-controle (bijv. Beheerder mag Eigenaar niet wijzigen) primair plaatsvinden?
|
||||
- A) **Service Layer**: In de `IUserService` wordt bij elke actie gecontroleerd of de uitvoerder voldoende rechten heeft t.o.v. de doelgebruiker.
|
||||
- B) **Authorization Policies**: Gebruikmaken van custom `RequirementHandlers` die de hiërarchie valideren voordat de controller actie wordt aangeroepen.
|
||||
|
||||
### 4. Refresh Tokens
|
||||
**Vraag 4.1**: Hoe moeten Refresh Tokens worden opgeslagen?
|
||||
- A) In de SQL database (gekoppeld aan de Gebruiker).
|
||||
- B) In-memory (alleen geschikt voor single-instance, gaat verloren bij restart).
|
||||
- C) Geen refresh tokens in de eerste versie van de MVP (alleen access tokens).
|
||||
|
||||
## Volgende Stappen
|
||||
Na beantwoording van deze vragen worden de artifacts (`business-rules.md`, `logic-model.md`, `entities.md`) gegenereerd in `aidlc-docs/construction/identity-rbac/functional-design/`.
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
# NFR Design Plan — Unit 02: Identity & RBAC
|
||||
|
||||
Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor Unit 02.
|
||||
|
||||
## NFR Design Stappen
|
||||
- [x] Uitwerken van de `ApplicationDbContext` configuratie voor schone tabelnamen.
|
||||
- [x] Ontwerpen van de `HierarchicalRoleRequirement` en bijbehorende `Handler`.
|
||||
- [x] Definiëren van de `IAuthService` contracten voor JWT en Refresh Token management.
|
||||
- [x] Uitwerken van het beveiligingsmechanisme voor het eenmalige Setup endpoint.
|
||||
- [x] Vastleggen van de database schema voor de `RefreshToken` en `Invitation` entiteiten.
|
||||
|
||||
## Vragen voor NFR Design (Unit 02)
|
||||
|
||||
### 1. Setup Endpoint Beveiliging
|
||||
**Vraag 1.1**: Hoe moeten we garanderen dat het `POST /api/setup/init` endpoint echt maar één keer bruikbaar is?
|
||||
- A) **Database Check**: Controleer of er al een gebruiker met de rol `Owner` bestaat. Zo ja, retourneer 403 Forbidden.
|
||||
- B) **Feature Flag/Config**: Gebruik een vlag in de database `IsSystemInitialized`.
|
||||
- C) **File System**: Controleer op de aanwezigheid van een lock-file (minder geschikt voor cloud/docker).
|
||||
|
||||
### 2. JWT Signing
|
||||
**Vraag 2.1**: Waar moeten de JWT signing keys worden opgeslagen voor de MVP?
|
||||
- A) In `appsettings.json` (niet aanbevolen voor productie, maar eenvoudig voor dev).
|
||||
- B) In Environment Variables.
|
||||
- C) Gebruik van een lokaal gegenereerd certificaat/key file (voorbereiding op KeyVault).
|
||||
|
||||
### 3. Invitation Token
|
||||
**Vraag 3.1**: Wat voor soort token moeten we gebruiken voor de uitnodigingen?
|
||||
- A) Een cryptografisch veilige random string (bijv. 32 bytes Base64).
|
||||
- B) Een GUID.
|
||||
- C) Een kort JWT token (self-contained, maar vereist key management).
|
||||
|
||||
## Volgende Stappen
|
||||
Na beantwoording van deze vragen worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/identity-rbac/nfr-design/`.
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
# NFR Requirements Plan — Unit 02: Identity & RBAC
|
||||
|
||||
Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor de Identity & RBAC module (Unit 02).
|
||||
|
||||
## NFR Assessment Stappen
|
||||
- [x] Vaststellen van de security baseline voor wachtwoordopslag en complexiteit.
|
||||
- [x] Definiëren van de token lifecycle (Access vs Refresh token duur).
|
||||
- [x] Bepalen van de audit-logging vereisten voor gevoelige acties (bijv. rolwijzigingen).
|
||||
- [x] Keuze van de database provider en ORM configuratie voor Identity.
|
||||
- [x] Performance overwegingen voor JWT validatie bij elk request.
|
||||
|
||||
## NFR Vragen voor Unit 02
|
||||
|
||||
### 1. Beveiliging & Wachtwoorden
|
||||
**Vraag 1.1**: Welke wachtwoord-complexiteit regels moeten we afdwingen?
|
||||
- A) **Standaard .NET Identity**: Minimaal 6 tekens, kleine letter, hoofdletter, cijfer en speciaal teken.
|
||||
- B) **Strikt**: Minimaal 12 tekens, verplichte variatie, geen bekende zwakke wachtwoorden.
|
||||
- C) **Eenvoudig**: Alleen minimale lengte (bijv. 8 tekens), geen complexiteitseisen.
|
||||
|
||||
### 2. Token Lifecycle
|
||||
**Vraag 2.1**: Wat moeten de standaard geldigheidsduren zijn voor de tokens?
|
||||
- A) **Standaard**: Access Token: 1 uur, Refresh Token: 7 dagen.
|
||||
- B) **Kort/Veilig**: Access Token: 15 minuten, Refresh Token: 24 uur.
|
||||
- C) **Lang**: Access Token: 12 uur, Refresh Token: 30 dagen.
|
||||
|
||||
### 3. Auditing
|
||||
**Vraag 3.1**: Welke acties moeten verplicht worden gelogd in een audit-trail (database)?
|
||||
- A) Alleen mislukte login pogingen.
|
||||
- B) Alle mutaties: Rolwijzigingen, gebruikerscreatie, en (de)activatie.
|
||||
- C) Alles inclusief succesvolle logins en token refreshes.
|
||||
|
||||
### 4. Database & ORM
|
||||
**Vraag 4.1**: Gaan we voor Identity gebruik maken van Entity Framework Core met SQL Server (conform NFR-01)?
|
||||
- A) Ja, gebruik de standaard `AspNetIdentity` tabellen in de SQL database.
|
||||
- B) Ja, maar met een aangepast schema/tabelnamen om de "AspNet" prefix te vermijden.
|
||||
|
||||
## Volgende Stappen
|
||||
Na beantwoording van deze vragen worden de artifacts (`nfr-requirements.md`, `tech-stack-decisions.md`) gegenereerd in `aidlc-docs/construction/identity-rbac/nfr-requirements/`.
|
||||
Reference in New Issue
Block a user