Public Access
jaap-jan
69bc9e270b
An invitation decided access from an assertion about an address. Everything else
in this model decides it from something a person did — an admin naming an
account, a key holder wrapping a vault key to a key they verified — and this was
the one place a token's email claim was the thing that let somebody in.
It was guarded as tightly as that can be guarded: the claim was refused outright
on an unverified or absent `email_verified`, with no setting to relax it. But the
guard and the risk were the same shape. The whole defence was one boolean sent by
a system the deployment does not control.
So `POST /teams/{id}/members` is the only way in, and an address with no account
is refused with `no-such-account` — which is now the end of the road rather than
the signal to invite. Both clients say the remedy: that person signs in here
once, which is what creates the account, and then they can be added. The desktop
leaves the address in the box, because a message telling you to come back later
is one you act on later.
Gone with it: the `team_invitation` table, the claim hook in the sign-in path,
and `Oidc:EmailVerifiedClaim`, which that hook was the only reader of. Nothing in
the server now reads the email claim to decide anything.
Pending invitations are dropped rather than converted. Converting one would mean
creating a membership because an address matched, which is the property being
removed — and an invitation to an address that did have an account here had
already been claimed by the hourly sweep, so what is left is offers to people who
never arrived.
Two tests carry the property rather than the feature: the endpoint inventory
asserts the three routes are absent, and the API suite adds an address that has
no account, watches the refusal, then signs that address in and checks it joined
nothing. Without the second half, a server that merely renamed the deferred path
would pass.
89 lines
2.8 KiB
C#
89 lines
2.8 KiB
C#
namespace DodoSSH.Domain;
|
|
|
|
/// <summary>
|
|
/// A group of users who can share vaults.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// The tables exist from the first migration although team features ship in M3. Adding them
|
|
/// later would mean altering <see cref="Vault"/> to introduce a foreign key on a live table, and
|
|
/// the cost of carrying two unused tables is far lower than that.
|
|
/// </remarks>
|
|
public sealed class Team
|
|
{
|
|
/// <summary>Primary key.</summary>
|
|
public Guid Id { get; set; }
|
|
|
|
/// <summary>Display name.</summary>
|
|
public string Name { get; set; } = string.Empty;
|
|
|
|
/// <summary>URL-safe unique identifier.</summary>
|
|
public string Slug { get; set; } = string.Empty;
|
|
|
|
/// <summary>Optional description.</summary>
|
|
public string? Description { get; set; }
|
|
|
|
/// <summary>Who created it.</summary>
|
|
public Guid CreatedByUserId { get; set; }
|
|
|
|
/// <summary>Creation timestamp.</summary>
|
|
public DateTimeOffset CreatedAtUtc { get; set; }
|
|
|
|
/// <summary>Soft-delete marker.</summary>
|
|
public DateTimeOffset? DeletedAtUtc { get; set; }
|
|
|
|
/// <summary>Members.</summary>
|
|
public ICollection<TeamMembership> Memberships { get; } = [];
|
|
}
|
|
|
|
/// <summary>
|
|
/// A user's membership of a team.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// Revoked memberships are retained rather than deleted, so historic audit entries remain
|
|
/// resolvable to a person.
|
|
/// </remarks>
|
|
public sealed class TeamMembership
|
|
{
|
|
/// <summary>Primary key.</summary>
|
|
public Guid Id { get; set; }
|
|
|
|
/// <summary>The team.</summary>
|
|
public Guid TeamId { get; set; }
|
|
|
|
/// <summary>The team.</summary>
|
|
public Team? Team { get; set; }
|
|
|
|
/// <summary>The member.</summary>
|
|
public Guid UserId { get; set; }
|
|
|
|
/// <summary>The member.</summary>
|
|
public UserAccount? User { get; set; }
|
|
|
|
/// <summary>Role within the team.</summary>
|
|
public TeamRole Role { get; set; }
|
|
|
|
/// <summary>Membership state.</summary>
|
|
public MembershipStatus Status { get; set; }
|
|
|
|
/// <summary>
|
|
/// Which admin added them.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// Named for the invitations that used to be the other way in. They are gone — an account is added
|
|
/// by somebody who names it, and there is no path that creates a membership out of a token's email
|
|
/// claim — so this now records only that, and the column keeps its name rather than costing a
|
|
/// migration to rename a field nothing reads but an audit trail.
|
|
/// </remarks>
|
|
public Guid? InvitedByUserId { get; set; }
|
|
|
|
/// <summary>When the membership became active.</summary>
|
|
public DateTimeOffset? JoinedAtUtc { get; set; }
|
|
|
|
/// <summary>Creation timestamp.</summary>
|
|
public DateTimeOffset CreatedAtUtc { get; set; }
|
|
|
|
/// <summary>Soft-delete marker.</summary>
|
|
public DateTimeOffset? DeletedAtUtc { get; set; }
|
|
}
|
|
|