AuthOptions

disableAuth

Disable authentication & permissions checks. NEVER set the to true in production. It exists only to aid certain development tasks.

tokenMethod

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>.
• 'api-key': The mutation createApiKey will return a generated API-Key once, which should then be stored by the User. Each request should include the API-Key inside the header defined by apiKeyHeaderKey ('vendure-api-key' by default).

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'].

From v3.6.0 it is possible to include 'api-key' as additional method in the method-tuple to allow for long-lived API-Key based authorization.

cookieOptions

Options related to the handling of cookies when using the 'cookie' tokenMethod.

authTokenHeaderKey

Sets the header property which will be used to send the auth token when using the 'bearer' method.

apiKeyHeaderKey

Defines which header will be used to read the API-Key when using the 'api-key' token method.

sessionDuration

Session duration, i.e. the time which must elapse from the last authenticated request after which the user must re-authenticate.

If passed as a number should represent milliseconds and if passed as a string describes a time span per zeit/ms. Eg: 60, '2 days', '10h', '7d'

sessionCacheStrategy

This strategy defines how sessions will be cached. By default, since v3.1.0, sessions are cached using the underlying cache strategy defined in the SystemOptions.cacheStrategy.

sessionCacheTTL

The "time to live" of a given item in the session cache. This determines the length of time that a cache entry is kept before being considered "stale" and being replaced with fresh data taken from the database.

If passed as a number should represent seconds and if passed as a string describes a time span per zeit/ms. Eg: 60, '2 days', '10h', '7d'

requireVerification

Determines whether new User accounts require verification of their email address.

If set to "true", the customer will be required to verify their email address using a verification token they receive in their email. See the registerCustomerAccount mutation for more details on the verification behavior.

verificationTokenDuration

Sets the length of time that a verification token is valid for, after which the verification token must be refreshed.

If passed as a number should represent milliseconds and if passed as a string describes a time span per zeit/ms. Eg: 60, '2 days', '10h', '7d'

superadminCredentials

Configures the credentials to be used to create a superadmin

shopAuthenticationStrategy

Configures one or more AuthenticationStrategies which defines how authentication is handled in the Shop API.

adminAuthenticationStrategy

Configures one or more AuthenticationStrategy which defines how authentication is handled in the Admin API.

customPermissions

Allows custom Permissions to be defined, which can be used to restrict access to custom GraphQL resolvers defined in plugins.

passwordHashingStrategy

Allows you to customize the way passwords are hashed when using the NativeAuthenticationStrategy.

adminApiKeyStrategy

shopApiKeyStrategy

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,}$/,  }),}

verificationTokenStrategy

Allows you to customize the way verification tokens are generated.

entityAccessControlStrategy

Allows you to define access control for entity queries at three levels:

• canAccess() — gate-level permission check (once per request)
• prepareAccessControl() — async pre-loading for row-level filtering (once per request)
• applyAccessControl() — synchronous row-level QB filtering (every entity query)

Developer preview: this API is subject to change in future releases.

customerChannelAssignmentStrategy

Determines whether an authenticated Customer is auto-assigned to the active Channel. This is skipped for the default channel, disableAuth, and registration/checkout flows. The default strategy always assigns.

disableLastLoginUpdate

When set to true, the User.lastLogin field is not updated when a user logs in. Each login otherwise writes to the user table, which can become a bottleneck for storefronts that authenticate on a large proportion of requests.