@happyvertical/smrt-users 0.57.7 → 0.57.9

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -905,13 +905,30 @@ Other credential kinds (a fob or badge reader, say) implement
905
905
  ### Password sign-in
906
906
 
907
907
  `PasswordCredentialService` (#3274) gives an app without an identity provider
908
- email + password sign-in for **existing, active** users. It never creates a
908
+ email-or-username + password sign-in for **existing, active** users. It never creates a
909
909
  user. The password lives in its own object, `UsersPasswordCredential`
910
910
  (`users_password_credentials`, one row per person), not on `User`: it is
911
911
  `sensitive`, has no generated REST/MCP/CLI surface, never enters the change
912
912
  feed, and `toPublicJSON()` omits the hash. The service and the handlers below
913
913
  are its only read and write paths.
914
914
 
915
+ Username rollout: run the normal explicit application schema migration before
916
+ serving the updated users package. The additive nullable `username` and unique
917
+ `username_key` columns leave existing accounts unchanged; no username is inferred
918
+ from an email or profile, and no data backfill is needed. Assign usernames through
919
+ `User.save()` so the canonical key is maintained. Usernames are global, NFKC
920
+ normalized, trimmed, lowercased, and limited to 1–64 ASCII letters/digits with
921
+ internal dots, underscores or hyphens; `@` remains reserved for email sign-in.
922
+
923
+ Pass `{ identifier, password }` to the handler for either email or username
924
+ (the existing `{ email, password }` body remains supported). Applications that
925
+ need no workspace chooser can configure `tenantId: 'unique-active-membership'`.
926
+ The service verifies the password first, then requires exactly one active direct
927
+ membership before minting a tenant-bound session. Zero or multiple active
928
+ memberships return the same generic refusal as other invalid credentials; an
929
+ ambiguous login never returns an unscoped session. Explicit tenant IDs and
930
+ omitting the tenant option retain their existing behavior.
931
+
915
932
  **Hashing.** scrypt from `node:crypto` (no native dependency) with a random
916
933
  per-hash salt; the parameters are stored in each hash
917
934
  (`scrypt$N$r$p$salt$hash`) and compared with `timingSafeEqual`. Raising