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 und dienen hauptsächlich dazu, die richtige Schnittstelle für die API bereitzustellen, 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 – Lesemethode:

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 – Schreibmethode:

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.
• Aufrufe explizit auth.InitializeAsync(sessionData) vor der Geschäftslogik.
• 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
• Einfach für Junioren zu verstehen

Nachteile:

• Leichte Duplizierung in jedem Controller (obwohl sie es sind). automatisch generiert)
• Controller verwalten jetzt ein wenig „Infrastruktur“-Logik

Kontext:

• Controller werden nahezu identisch generiert
• 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

Fragen
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 andere Kompromisse, die mir fehlen, insbesondere in Bezug auf Lesbarkeit, OpenAPI-Dokumentation und Entwickler-Onboarding?