Auth / Auth and Guard
Which one owns what
| Question | Owner | Where it runs | How it says no |
|---|---|---|---|
| Is there a session on this request, and may this request use it? | foldkit-auth (AuthServer.resolver) | server, per request | a 401 (Unauthenticated): the request is refused before anything is read |
Who is that session in the application's terms (User, its role)? | the application's principal function, given to the resolver | server, per request | a 401, if it refuses the session |
Which rows, members and relations may this User read? | foldkit-guard (Read rules) | server: a SQL condition or an evaluator | the rows are absent; nothing says they exist |
May this User make this write? | foldkit-guard (Write rules, GuardServer.writer, mutation) | server, before the write; what it returns is read back through the Read rules | a 403 (Forbidden) |
| What may the page show as allowed? | the server's may answer (Me, a row's may) | answered on the server, read on the client | a button not drawn; no rule runs on the client |
| Credentials, sign-in, sign-out, the cookie | Yielded Auth itself | its own routes | its own errors (PasswordRejected, …) |
Two things follow from the table:
- A visitor is not a refusal. No cookie is
Option.none(), a principal like any other, and guard decides what a visitor may read (usually nothing guarded). Auth refuses only a credential that was sent and no longer holds, or a request that cannot show it came from the application. - Auth never authorizes. A resolver that checks a role and refuses has
moved a rule out of the guard set, where no read, write, Sync edit or agent
will find it. Build the principal in
principal; decide in guards.