AuthOptions
AuthOptions
The AuthOptions define how authentication and authorization is managed.
Signature
interface AuthOptions {
disableAuth?: boolean;
tokenMethod?: 'cookie' | 'bearer' | ReadonlyArray<'cookie' | 'bearer'>;
cookieOptions?: CookieOptions;
authTokenHeaderKey?: string;
sessionDuration?: string | number;
sessionCacheStrategy?: SessionCacheStrategy;
sessionCacheTTL?: number;
requireVerification?: boolean;
verificationTokenDuration?: string | number;
superadminCredentials?: SuperadminCredentials;
shopAuthenticationStrategy?: AuthenticationStrategy[];
adminAuthenticationStrategy?: AuthenticationStrategy[];
customPermissions?: PermissionDefinition[];
passwordHashingStrategy?: PasswordHashingStrategy;
passwordValidationStrategy?: PasswordValidationStrategy;
}
Members
disableAuth
boolean
false
tokenMethod
'cookie' | 'bearer' | ReadonlyArray<'cookie' | 'bearer'>
'cookie'
Sets the method by which the session token is delivered and read.
- ‘cookie’: Upon login, a ‘Set-Cookie’ header will be returned to the client, setting a cookie containing the session token. A browser-based client (making requests with credentials) should automatically send the session cookie with each request.
- ‘bearer’: Upon login, the token is returned in the response and should be then stored by the
client app. Each request should include the header
Authorization: Bearer <token>.
Note that if the bearer method is used, Vendure will automatically expose the configured
authTokenHeaderKey in the server’s CORS configuration (adding Access-Control-Expose-Headers: vendure-auth-token
by default).
From v1.2.0 it is possible to specify both methods as a tuple: ['cookie', 'bearer'].
cookieOptions
CookieOptions
authTokenHeaderKey
string
'vendure-auth-token'
sessionDuration
string | number
'1y'
Session duration, i.e. the time which must elapse from the last authenticated request after which the user must re-authenticate.
Expressed as a string describing a time span per
zeit/ms. Eg: 60, '2 days', '10h', '7d'
sessionCacheStrategy
sessionCacheTTL
number
300
requireVerification
boolean
true
Determines whether new User accounts require verification of their email address.
If set to “true”, when registering via the registerCustomerAccount mutation, one should not set the
password property - doing so will result in an error. Instead, the password is set at a later stage
(once the email with the verification token has been opened) via the verifyCustomerAccount mutation.
verificationTokenDuration
string | number
'7d'
Sets the length of time that a verification token is valid for, after which the verification token must be refreshed.
Expressed as a string describing a time span per
zeit/ms. Eg: 60, '2 days', '10h', '7d'
superadminCredentials
SuperadminCredentials
shopAuthenticationStrategy
adminAuthenticationStrategy
customPermissions
passwordHashingStrategy
passwordValidationStrategy
Allows you to set a custom policy for passwords when using the NativeAuthenticationStrategy. By default, it uses the DefaultPasswordValidationStrategy, which will impose a minimum length of four characters. To improve security for production, you are encouraged to specify a more strict policy, which you can do like this:
Example
{
passwordValidationStrategy: new DefaultPasswordValidationStrategy({
// Minimum eight characters, at least one letter and one number
regexp: /^(?=.*[A-Za-z])(?=.*\d)[A-Za-z\d]{8,}$/,
}),
}