Let's you flexibly customize if and how you prevent users from registering with your Vendure instance. For example, reduce fraud by blocking disposable email providers or IP ranges from registering with your Vendure instance or harden your admin accounts by only allowing specific domains in email addresses.
npm install @danielbiegler/vendure-plugin-user-registration-guard
Let's you flexibly customize if and how you prevent users from registering with your Vendure instance.
For example, reduce fraud by blocking disposable email providers or IP ranges from registering with your Vendure instance or harden your admin accounts by only allowing specific domains in email addresses.
AND
, OR
) for when you have multiple checksBlockedCustomerRegistrationEvent
or BlockedCreateAdministratorEvent
on the EventBus for your consumption, for example if you'd like to monitor failed attemptsregisterCustomerAccount
, createAdministrator
), which makes this plugin integrate seamlessly with your own resolver overrides
✓ user-registration-guard/e2e/email.e2e-spec.ts (4)
✓ user-registration-guard/e2e/events.e2e-spec.ts (4)
✓ user-registration-guard/e2e/injector.e2e-spec.ts (2)
✓ user-registration-guard/e2e/ip.e2e-spec.ts (2)
✓ user-registration-guard/e2e/logical-and_fail.e2e-spec.ts (2)
✓ user-registration-guard/e2e/logical-and_ok.e2e-spec.ts (2)
✓ user-registration-guard/e2e/logical-or_fail.e2e-spec.ts (2)
✓ user-registration-guard/e2e/logical-or_ok.e2e-spec.ts (2)
✓ user-registration-guard/e2e/reject.e2e-spec.ts (2)
Test Files 9 passed (9)
Tests 22 passed (22)
The plugin does not extend the API, has no dependencies and requires no migration.
You can find the package over on npm and install it via:
Please refer to the specific docs for how and what you can customize.
Here's an example assertion where we block customer registrations if the email ends with example.com
:
The reason
field is helpful for when you're subscribing to the published events and want to log or understand why somebody got blocked.
In your assertions, see the types, you'll receive these arguments:
RequestContext
RegisterCustomerInput
or CreateAdministratorInput
depending on the API type.Injector
For example, if you'd like to block IP ranges you can access the underlying Express Request object through the RequestContext
.
If you'd like to delegate the decision to a service you may inject it like so:
If you've extended your GraphQL API types you may override the TypeScript Generic to get completions in your assertion functions like so:
This user will now be blocked from registering according to our blockExampleDotCom
assertion.
The plugin is non-intrusive and does not extend the API itself to avoid introducing unhandled errors in your code.
It respects RegisterCustomerAccountResult
being a Union, so we don't throw an error, but return a NativeAuthStrategyError
. You may handle the error just like the other RegisterCustomerAccountResult
types like PasswordValidationError
for example.
In contrast, for admins we do throw the error! This is a little different because by default the createAdministrator
mutation does not return a Union with error types.
Granted, the NativeAuthStrategyError
is technically not correct for blocking registrations and doesn't communicate the blocking properly, but it's the only reasonable error type in the Union for a default non-api-extended Vendure instance. You might want to add some comments in your registration logic that the error means blockage.
You may want to subscribe to the EventBus to monitor blocked registration attempts.