User accounts, password resets and role management that you control

Sign-up, sign-in and reset

Visitors register with email and password or sign in with Google. A forgotten-password request sends a reset link to the account's email address; following it returns the user to a set-new-password screen in the app and signs them in on success.

Email confirmation behaviour is a project decision rather than a default we impose, because a trade portal and a consumer store want different answers.

• Email and password plus Google sign-in
• Emailed reset link with an in-app new-password step
• Sessions refreshed automatically by the client library
• Sign-out clears the session everywhere in the app

Roles live in their own table, deliberately

Roles are never stored on the profile record. They live in a dedicated user-roles table with a unique pairing of user and role, read through a security-definer helper function that row-level security policies call.

The reason is a specific class of vulnerability: if a role sits on a row the user can update, the user can promote themselves. Separating the table removes that possibility structurally rather than relying on careful policy writing.

What an administrator can do

Administrators assign and remove roles, which is what determines access to admin areas, branch scoping and trade pricing. Trade or business accounts can be approved from a pending state before they see account pricing.

Being precise about the boundary: role assignment and approval are in the admin. Deeper account administration such as suspending users or reassigning their history is built per project when a client needs it, not something we claim as standard.

Why managed auth rather than our own

Credential storage, token refresh, social provider flows and reset-link expiry are all places where a bespoke implementation is quietly worse than a maintained one. We use a managed service and spend the effort on authorisation instead, which is where client-specific risk actually lives.

The practical benefit is that a new admin screen inherits the same boundary as every existing one, because the check happens in the database.