Skip to content
Slaap rustigData foundation

Login, goed geregeld

Inloggen en rollen werken meteen. Gebruikers zien alleen de data van hun eigen bedrijf.

Inloggen en rollen werken meteen. Gebruikers zien alleen de data van hun eigen bedrijf.

  • 1

    path that decides who a user is

  • 4

    roles, compared in one place

  • 0

    company IDs accepted from the browser

Het probleem dat dit oplost

Zonder een gedeelde basis bouwt elk team deze randgevallen opnieuw — en anders.

The leak you find out about from a customer

One endpoint trusts an ID sent from the browser. One curious user edits it. Now they're reading another company's data, and you're writing the apology email. Here, the browser never gets to pick the tenant. The server does.

Role rules that drift

Every feature writes its own role check. Over time they disagree. An admin-only action in one screen quietly becomes open to editors in another, and nobody notices until an audit does.

The 'who can see this?' mess

Company-wide members, project-only members, and owners all overlap. Without one rule, every endpoint answers 'who can see this project?' a little differently. That's how weird access bugs are born.

Hoe het werkt

Het mechanisme van begin tot eind, zoals het in de repository is geïmplementeerd.

  1. 1

    Clerk checks the login

    Clerk confirms the session once per request. No session means the request stops right there.

  2. 2

    The login maps to a real user

    The server looks the login up in your own users table. An account that isn't set up yet gets a clear error, not a free pass.

  3. 3

    Access is checked next to the write

    The same database call that saves your data also confirms the user belongs there. There's no gap for a mistake to slip through.

  4. 4

    One rule decides roles

    Viewer, editor, admin, owner. One comparison function ranks them, and every feature uses it. Company and project access merge with a single rule.

Interactief voorbeeld

Bekijk het in werking

Deze rondleiding toont het geïmplementeerde backendcontract zonder account, credentials of providercalls.

Interactief voorbeeld

Explore the implemented decisions

Kies een voorbeeldstatus
Read access

Alleen deterministische voorbeelddata. De interactie gebruikt geen account-, provider- of netwerkverbinding.

Kernpunten

Waarom dit belangrijk is

The server decides who you are

Every request is checked against a real user in your database. What the browser claims doesn't matter.

One rule for roles

Viewer, editor, admin, owner. One ordering, used everywhere, so access never drifts between features.

Locked by default

Missing login, unknown account, or no membership? The request stops with a clear error. Nothing slips through on a lucky default.

Technische garanties

Wat dit wel en niet belooft

Veiligheidsgrens

Achter de schermen houden autorisatie, tenantgrenzen en foutafhandeling één duidelijke eigenaar. Zo blijft de snelle ervaring voor gebruikers gekoppeld aan veilig herstel als het misgaat.

Implementatiebewijs

De grens hierboven is geen claim maar code. Deze bestanden dragen het contract:

  • src/server/auth.ts
  • src/server/permissions.ts
  • src/policies/roles.ts
Vragen

Veelgestelde vragen

Bouw verder op Login, goed geregeld

De documentatie beschrijft dezelfde contracten die deze pagina demonstreert.