Namespace Kuestenlogik.Bowire.Auth

Classes

CookieJar

Per-environment in-memory cookie store. Bowire holds one CookieContainer per environment id while the workbench process runs; the REST plugin hands the container to a fresh per-call HttpClientHandler when the JS layer marked the request with MarkerKey, so cookies set by one call (e.g. POST /login) ride along on every following call to the same origin (GET /me).

Memory-only by design: process restart wipes the jar, which mirrors what an actual logged-out browser session looks like. Persistent storage would buy little since secrets in cookies are already short- lived and the user can re-authenticate trivially.

CookieSnapshot

Wire shape for the workbench's cookies-list endpoint.

LocalhostCertTrust

Resolves whether a Bowire protocol plugin should trust a self-signed certificate served from a loopback address. Off by default — production hosts always validate strictly via the OS trust store. The opt-in is designed for the ASP.NET Core dev-certs flow on developer machines and CI containers where dotnet dev-certs https --trust hasn't run.

Settings hierarchy (first hit wins):

• Bowire:{PluginId}:TrustLocalhostCert — per-plugin override. Use when one plugin needs different cert handling than the host's global default (e.g. enable for SignalR but stay strict for REST).
• Bowire:TrustLocalhostCert — global default for every TLS- bearing plugin. Recommended choice for a typical local-dev host.
• Otherwise — false.

Even when the flag is on, the relaxed validation only fires for URLs whose host is localhost, 127.0.0.1 or ::1. A production hostname accidentally seen by a misconfigured Bowire host is still validated against the OS trust store.

MtlsCertOwner

Lightweight cert-only owner for transports that don't go through an HttpMessageHandler — primarily System.Net.WebSockets.ClientWebSocket, which exposes its own ClientCertificates + RemoteCertificateValidationCallback on ClientWebSocketOptions. Disposes the loaded X509 resources when the channel goes away.

MtlsConfig

Decoded mTLS client-cert configuration carried inline in the request metadata dict via MtlsMarkerKey. Shared between the REST plugin (HttpClientHandler) and the gRPC plugin (SocketsHttpHandler) so every TLS-capable transport speaks the same wire format and only one PEM parser exists in the codebase.

MtlsHandlerOwner

Bundles a pre-configured HttpMessageHandler with the X509 resources whose lifetime must match it. Disposing the owner disposes the handler and every cert it holds — caller places this in the finally next to the per-call HttpClient / GrpcChannel.

One owner type rather than one per protocol: REST uses HttpClientHandler (its ClientCertificates collection is the natural shape); gRPC uses SocketsHttpHandler (its SslOptions property carries the same data via SslClientAuthenticationOptions). Both inherit from HttpMessageHandler, so callers can hold the abstract base type without caring which factory built it.