Authentifizierungs-Middleware vs. explizite Header in vom Analysator generierten Controllern – Best Practice? ⇐ C#

[Anonymous]

Ich erstelle eine Blazor WebAssembly-Backend-API mit ASP.NET Core und alle meine Controller werden automatisch über einen Codeanalysator generiert. Diese Controller sind sehr dünn, sie dienen hauptsächlich dazu, die richtige Schnittstelle für die API bereitzustellen, und nicht, um Geschäftslogik zu speichern.
Mein System verwendet einen sitzungsbasierten Authentifizierungsdienst, bei dem ein SessionContext in Headern übergeben wird (

Code: Select all

X-Session

) für jede Anfrage. Jede Anfrage gibt auch aktualisierte Sitzungsdaten in den Antwortheadern zurück.
Ich diskutiere zwei Ansätze für die Handhabung von Authentifizierung und Sitzungsstatus:
Option 1 – Middleware:

• Sitzungsdaten aus Headern in einer Middleware lesen.
• Authentifizierung/Sitzungskontext in Middleware initialisieren.
• Controller-Aktion aufrufen.
• Aktualisierte Sitzungsheader zurück in die Middleware schreiben.

Middleware: Lesen

Code: Select all

public class SessionContextMiddleware
{
private readonly RequestDelegate _next;

public SessionContextMiddleware(RequestDelegate next) => _next = next;

public async Task Invoke(HttpContext ctx, IServerAuthenticationService auth)
{
var raw = ctx.Request.Headers["X-Session"].FirstOrDefault();
await auth.InitializeAsync(raw);
await _next(ctx);
}
}

Middleware: Schreiben

Code: Select all

public class SessionContextCommitMiddleware
{
private readonly RequestDelegate _next;

public SessionContextCommitMiddleware(RequestDelegate next) => _next = next;

public async Task Invoke(HttpContext ctx, IServerAuthenticationService auth)
{
await _next(ctx);
var newState = await auth.CreateSessionData();
if (newState != null)
ctx.Response.Headers["X-Session"] = newState;
}
}

Controller (generiert von Source Analyzer)

Code: Select all

[HttpPost("create")]
public async Task Create(
[FromForm] Country country)
{
if (!ModelState.IsValid) return BadRequest(ModelState);
if (auth.IsForbidden) return Forbid();
var result = await countriesService.Create(country);
return Ok(result);
}

Vorteile:

• Controller bleiben klein und sauber.
• Zentralisierte Sitzungs-/Authentifizierungsverwaltung.

Nachteile:

• Swagger/OpenAPI zeigt nicht automatisch Header an (

  Code: Select all

  X-Session

  ) in der Dokumentation.
• Entwickler, die den Controller lesen, können nicht sehen, woher Sitzung/Authentifizierung kommt (weniger explizit).

Option 2 – Explizit in Controllern:

• Jede Controller-Aktion erhält [FromHeader]-String sessionData.
• Ruft explizit auth.InitializeAsync(sessionData) vor der Geschäftslogik auf.
• Schreibt Response.Headers["X-Session"] = ... explizit nach der Geschäftslogik zurück.

Controller (generiert von Source Analyzer)

Code: Select all

[HttpPost("create")]
public async Task  Create(
[FromForm] Country country,
[FromHeader(Name = "X-Session")] string sessionData)
{
if (!ModelState.IsValid) return BadRequest(ModelState);
await auth.InitializeAsync(sessionData);
if (auth.IsForbidden) return Forbid();
var result = await countriesService.Create(country);
Response.Headers["X-Session"] = await auth.CreateSessionData();
return Ok(result);
}

Vorteile:

• Vollständig explizit und für Entwickler sichtbar.
• Swagger/OpenAPI dokumentiert automatisch Header.
• Leicht für Junioren zu verstehen.

Nachteile:

• Leichte Duplikate in jedem Controller (obwohl sie automatisch generiert werden).
• Controller verwalten jetzt eine kleine „Infrastruktur“-Logik.

Kontext:

• Controller werden generiert und sind nahezu identisch.
• Granularität/Unterschiede pro Endpunkt sind nicht erforderlich.
• Leistung ist kein Problem (E/A dominiert).
• Sicherheit, Wartbarkeit und Wiederverwendung werden bereits durch die generierten Dienste gesteuert.

Frage:
Was würden Sie angesichts dieser Einschränkungen empfehlen?

• Zentralisierte Authentifizierung/Sitzung in Middleware (saubere Controller, weniger explizit)
• Explizite Sitzungs-/Authentifizierungsaufrufe in jedem generierten Controller (transparent, Swagger-freundlich)

Gibt es noch andere Kompromisse, die mir besonders fehlen? bezüglich Lesbarkeit, OpenAPI-Dokumentation und Entwickler-Onboarding?