(ctx: RequestContext, userId: ID) => Promise<User | undefined>(ctx: RequestContext, emailAddress: string, userType?: 'administrator' | 'customer') => Promise<User | undefined>(ctx: RequestContext, identifier: string, password?: string) => Promise<User | PasswordValidationError>Creates a new User with the special customer Role and using the NativeAuthenticationStrategy.
(ctx: RequestContext, user: User, identifier: string, password?: string) => Promise<User | PasswordValidationError>Adds a new NativeAuthenticationMethod to the User. If the AuthOptions requireVerification
is set to true (as is the default), the User will be marked as unverified until the email verification
flow is completed.
(ctx: RequestContext, user: User, identifier: string, password?: string) => Promise<User | PasswordValidationError>Adds an unactivated NativeAuthenticationMethod (empty password, pending
verificationToken) to an existing User, without altering the User's verified state.
If the User already carries a native credential with a pending verificationToken, a fresh one
is issued for it instead. This lets the mailbox owner restart the flow when the first message
was lost or its token has expired.
The guarantee this method makes is that it never stores a password. A password already on the
credential is left as it is, and the password argument is discarded.
This is used when a native credential is being registered against an account that already exists via another authentication method (e.g. an external/SSO strategy). The credential is left without a password so that it can only be activated by whoever controls the email address, via the verification flow. Storing a caller-supplied password here would allow an unauthenticated account takeover (GHSA-wr5h-x3x6-4h23).
If a password is supplied it is validated and hashed, but the hash is deliberately NOT
stored. Doing the same work as a brand-new registration keeps this path indistinguishable from
one, both in its error result and in how long it takes, so it does not become an
account-existence oracle.
(ctx: RequestContext, identifier: string, password: string) => Promise<User>Creates a new verified User using the NativeAuthenticationStrategy.
(ctx: RequestContext, roles: Role[], identifier: string) => Promise<User>Creates a new User which will be responsible for the permissions of an API-Key.
IMPORTANT: The caller is responsible for avoiding privilege escalations!
(ctx: RequestContext, userId: ID) => (ctx: RequestContext, user: User) => Promise<User>Sets the NativeAuthenticationMethod verificationToken as part of the User email verification
flow.
(ctx: RequestContext, verificationToken: string, password?: string) => Promise<ErrorResultUnion<VerifyCustomerAccountResult, User>>Verifies a verificationToken by looking for a User which has previously had it set using the
setVerificationToken() method, and checks that the token is valid and has not expired.
If valid, the User will be set to verified: true.
(ctx: RequestContext, userId: ID, password?: string) => Promise<User | MissingPasswordError | PasswordAlreadySetError | PasswordValidationError>v3.8.0Marks a User as verified. Unlike UserService.verifyUserByToken, no verification
token is required, so this is the route for a verification an administrator performs on the
account holder's behalf. Clears any pending verificationToken, so
refreshCustomerVerification will no longer issue a new one.
The password argument follows the same rules as in verifyUserByToken: a
NativeAuthenticationMethod with no passwordHash requires one, and a credential
which already has one rejects it. A User with no native credential at all is verified only
without a password, since there is nothing to set it on.
verified is not checked before the credential is written, so a User which is already
verified but whose credential has no passwordHash gets one here. That is the state
UserService.addUnactivatedNativeAuthenticationMethod leaves behind, and activating it
is otherwise reserved for whoever controls the email address (GHSA-wr5h-x3x6-4h23). This
route is therefore only safe behind the UpdateCustomer permission.
(ctx: RequestContext, emailAddress: string) => Promise<User | undefined>Sets the NativeAuthenticationMethod passwordResetToken as part of the User password reset
flow.
Returns the User whose NativeAuthenticationMethod has the given passwordResetToken set,
as a result of a prior call to the setPasswordResetToken() method. Note that this method does
not check whether the token has expired.
(ctx: RequestContext, passwordResetToken: string, password: string) => Promise< User | PasswordResetTokenExpiredError | PasswordResetTokenInvalidError | PasswordValidationError >Verifies a passwordResetToken by looking for a User which has previously had it set using the
setPasswordResetToken() method, and checks that the token is valid and has not expired.
If valid, the User's credentials will be updated with the new password.
(ctx: RequestContext, userId: ID, newIdentifier: string) => Changes the User identifier without an email verification step, so this should be only used when an Administrator is setting a new email address.
(ctx: RequestContext, user: User) => Promise<User>Sets the NativeAuthenticationMethod identifierChangeToken as part of the User email address change
flow.
(ctx: RequestContext, token: string) => Promise< | { user: User; oldIdentifier: string } | IdentifierChangeTokenInvalidError | IdentifierChangeTokenExpiredError >Changes the User identifier as part of the storefront flow used by Customers to set a
new email address, with the token previously set using the setIdentifierChangeToken() method.
(ctx: RequestContext, userId: ID, currentPassword: string, newPassword: string) => Promise<boolean | InvalidCredentialsError | PasswordValidationError>Updates the password for a User with the NativeAuthenticationMethod.
Architecture reviews, custom plugin work, migrations, ongoing support. Get a hand from the team that builds Vendure.
Talk to the team