using BigRegister.Api.Data;

namespace BigRegister.Domain.Authorization;

/// <summary>
/// Dev stub (WP-53) — NOT a security boundary, same caveat as <see cref="Authz.ResolvePrincipal"/>
/// (which this provider now backs). Role comes from the existing client-asserted X-Role header
/// (mirrors the FE's <c>?role=</c> toggle); the subject BSN comes from a new X-Subject header,
/// defaulting to the single seeded citizen (<see cref="DocumentStore.DemoOwner"/>) so every
/// existing request — none of which send X-Subject — keeps behaving exactly as before this WP.
/// A real system builds this from verified AD/OIDC/DigiD claims; every consumer of
/// <see cref="CallerIdentity"/> carries over unchanged once that swap happens.
/// </summary>
public sealed class StubIdentityProvider : IIdentityProvider
{
  public CallerIdentity Resolve(HttpContext ctx)
  {
    var role = ctx.Request.Headers["X-Role"].ToString() switch
    {
      "approver" => PrincipalRole.Approver,
      "admin" => PrincipalRole.Admin,
      _ => PrincipalRole.Drafter,
    };
    var bsn = ctx.Request.Headers.TryGetValue("X-Subject", out var v) && !string.IsNullOrEmpty(v)
        ? v.ToString()
        : DocumentStore.DemoOwner;
    // Only one seeded citizen exists in this POC — a real provider carries the display name in
    // the verified claims themselves, so there's no "look up a name by BSN" step to stand in for.
    var displayName = bsn == DocumentStore.DemoOwner ? SeedData.Registration.Naam : bsn;
    return new CallerIdentity(bsn, displayName, role);
  }
}