Class BowireUserSlot
- Namespace
- Kuestenlogik.Bowire.Auth
- Assembly
- Kuestenlogik.Bowire.dll
Turns an authenticated subject into the directory name that holds their state (#97).
public static class BowireUserSlot- Inheritance
-
BowireUserSlot
- Inherited Members
Remarks
A sub claim is whatever the identity provider felt like issuing: an
e-mail address, a GUID, a URL, auth0|5f3c…. None of those are
directory names, so something has to map one to the other, and the mapping
has exactly two jobs.
It must be readable. An operator looking at the storage root should be able to tell whose slot is whose without a lookup table — a support request that starts "delete my recordings" is answered by finding a directory, and a tree of opaque hashes makes that a database query.
It must not collide. This is the one that would be a security bug
rather than an annoyance. Sanitising alone maps
a.b@example.com and a-b@example.com to the same name, and two
identities sharing a slot is cross-tenant disclosure — each would read the
other's environments, including the secrets in them. So the readable part
is a convenience and the fingerprint appended to it is the identity: it is
taken over the untouched subject, so any two distinct subjects land in
distinct directories no matter what sanitising did to them.
Fields
DirectoryName
The directory under the storage root that holds the per-identity slots.
Reserved as an instance name for the usual reason — with no instance
set the scope is the root, so an instance called
users would land on top of the slots.
public const string DirectoryName = "users"Field Value
Methods
Slug(string)
The directory name for subject: a readable rendering
of it, then a fingerprint of the original.
public static string Slug(string subject)Parameters
subjectstringThe authenticated subject, verbatim from the token. Trimmed, but otherwise not interpreted — the fingerprint is taken over what the provider issued.
Returns
- string
A single path segment, lower-case, safe on every platform Bowire runs on.