authzmutate

type ActivateUser ¶

type ActivateUser struct{}

ActivateUser re-activates a user. Additive — Invalidates() == false. Existing sessions remain valid; no epoch-bump needed. ref: ADR §A6 / OAuth Security BCP §4.13.2 (scope-expanding ops don't revoke).

Auto-lockout interaction: persist calls UpdateLockState(status=Active) which atomically zeros failed_login_count / last_failed_at / locked_until in the same SQL CASE statement (mem mirrors via ResetFailedLogins). This is a column-level invariant — "activate without lockout reset" is not expressible at the call site, closing the PR #585 P1#3 admin-unlock re-lock race at the schema layer. Both admin-unlock and lazy-unlock (accountlockout.TryLazyUnlock) routes through this mutation, so the reset is shared by both paths (ACCESSCORE-ACCOUNT-LOCKOUT-AUTO-LOCK-01). ref: ports.UserRepository.UpdateLockState godoc for the column-level invariant statement; PR #585 P1#3; ADR 202605222309.

func (ActivateUser) Event() session.CredentialEvent

func (ActivateUser) Invalidates() bool

type ClearPasswordReset ¶

type ClearPasswordReset struct{}

ClearPasswordReset clears the password-reset-required flag. Additive — Invalidates() == false. The credential change (password rotation) was already handled by changePasswordInTx which called inv.Apply directly; this mutation only updates the domain flag.

func (ClearPasswordReset) Event() session.CredentialEvent

func (ClearPasswordReset) Invalidates() bool

type LockUser ¶

type LockUser struct{}

LockUser locks the user account. Credential-weakening — Invalidates() == true.

func (LockUser) Event() session.CredentialEvent

func (LockUser) Invalidates() bool

type Mutation ¶

type Mutation interface {
	// Event returns the CredentialEvent label carried by this mutation.
	//
	// Contract: Event() is consumed ONLY when Invalidates()==true. The value
	// is passed to inv.Apply → audit/credential-event routing and must be a
	// meaningful CredentialEvent for those callers.
	//
	// For additive mutations (Invalidates()==false: ActivateUser,
	// ClearPasswordReset) the return value is NEVER READ by any code path —
	// Mutator.Apply skips inv.Apply entirely when Invalidates()==false.
	// These implementations return the nearest-domain event purely to satisfy
	// the total interface; the value is a documented don't-care and will never
	// reach an audit row or session-revocation path.
	Event() session.CredentialEvent

	// Invalidates returns true when this mutation is a credential-weakening
	// event that requires an epoch-bump + session/refresh revocation.
	Invalidates() bool
	// contains filtered or unexported methods
}

Mutation is the sealed interface for all authz-field change operations. Implementations are in this package only; the unexported mutationOK() method prevents external packages from satisfying the interface.

Invalidates() distinguishes additive operations (activate, clear-reset) from credential-weakening operations (lock, suspend, require-reset, role-revoke). Apply skips inv.Apply when Invalidates() == false — additive changes do not need an epoch-bump+revoke because no existing grants become too broad.

ActivateUser semantics (ADR §A6 / OAuth Security BCP §4.13.2): re-activating a user is an additive operation (scope-expanding, not scope-narrowing). It persists the status change but must NOT bump the authz_epoch or revoke sessions — existing sessions become MORE valid, not LESS. Invalidates() == false for ActivateUser.

ClearPasswordReset semantics: clearing the reset-required flag means the user has changed their password; the password-change path itself calls inv.Apply via changePasswordInTx, so clearing the flag here is a no-op on the invalidation side. Invalidates() == false for ClearPasswordReset.

type Mutator ¶

type Mutator struct {
	// contains filtered or unexported fields
}

Mutator is the single entry point for all authz-field mutations on a User aggregate. It guarantees that every credential-weakening mutation (status change to locked/suspended, requirePasswordReset, role-revoke) atomically bumps authz_epoch + revokes sessions + revokes refresh chains via the credentialinvalidate funnel.

Additive mutations (activate, clear-reset) persist the domain-field change but skip the invalidation trifecta (ADR §A6).

tx boundary: Mutator no longer owns a RunInTx boundary. Callers MUST invoke ApplyInTx from within their own outer RunInTx closure. This ensures that the domain mutation + event publish co-commit in the same transaction (L2 OutboxFact guarantee).

func New(
	inv *credentialinvalidate.Invalidator,
	repo ports.UserRepository,
) (*Mutator, error)

func (a *Mutator) ApplyInTx(
	ctx context.Context, txCtx context.Context, tid tenant.TenantID, userID string, m Mutation, now time.Time,
) error

type RequirePasswordReset ¶

type RequirePasswordReset struct{}

RequirePasswordReset marks the user as requiring a password reset. Credential-weakening — Invalidates() == true (existing sessions should be revoked so the user is forced through the reset flow immediately).

func (RequirePasswordReset) Event() session.CredentialEvent

func (RequirePasswordReset) Invalidates() bool

type SuspendUser ¶

type SuspendUser struct{}

SuspendUser suspends the user account. Credential-weakening — Invalidates() == true.

suspend≡lock for credential revocation (intentional, ADR-consistent): Event() returns CredentialEventLock rather than a hypothetical CredentialEventSuspend. This is not a bug — session.CredentialEvent is a sealed, completeness-checked set (WithRevokeOnAll / NewProtocol / ValidateCredentialEvent / String / all Store.RevokeForSubject impls) with no Suspend member by design. The project canonically treats suspend as equivalent to Lock for the purpose of session/refresh revocation: both states make the user non-authenticable and must revoke all active tokens. Precedent: identitymanage.cascadeInvalidateOnDemotion godoc explicitly states "suspended semantics are equivalent to Lock".

func (SuspendUser) Event() session.CredentialEvent

func (SuspendUser) Invalidates() bool