Authorization runs before guards. A request your ACL rules deny never reaches the rules at all, so a guard can only narrow access — it can never grant something a permission refused.

The reverse is worth noting too: a request that is unauthenticated on purpose, such as sign-up, is permitted by the ACL and therefore does reach the guards. That is what makes a rule like "registration is closed" possible.

Rules are never applied to requests authenticated as the service administrator. This is deliberate and it is what makes the plugin safe to experiment with: a rule that blocks everything still leaves the Cloud UI working, so you can always go back and fix it.

For users authenticating with a JWT, @user is the token’s claims — not the user document. A condition on @user.latestConsents will simply never match unless latestConsents is one of the claims your service issues.

Configure the claim list in Service → Users → JWT Claims (see Managing Users). The Guards page warns you inline when a condition names a field that is not in the configured list.

Users authenticating with username and password are not affected — for them @user is the full user document.

Two fields on the user document:

Two flags rather than one, because the terms and the privacy policy have versions of their own. Both are accepted by the same request: the client does not choose what it accepts, which is what keeps this to one permission and one rule. An acceptance that must be splittable — the privacy policy mandatory, the terms optional — is a different design, with a permission and a rule per flag, not an extension of this one.

Neither field is written by POST /auth/register, and that absence is exactly what the guard blocks on. There is one way to accept — the PATCH of step 2 — and it is the same one whether the user has just signed up, arrived through OAuth, or has had an account since before the current version existed.

Add a JSON Schema on /users (see JSON Schema Validation) that validates the two fields when present. Do not make them required — their absence is the state the guard exists to catch. The schema also declares OAuth fields (socialAuths, profile.avatarUrl) and team fields (teams, team) as optional, so documents created via OAuth or after team operations pass validation.

In Service → Schemas → New Schema the schema _id goes in its own field, not in the document — the editor takes only the schema body. Through the API it goes in the body like in any other MongoDB document: POST /_schemas with {"_id": "userConsentsSchema", …​}.

Schema id: userConsentsSchema

Schema document:

The two _id in play are not the same thing: the one in the UI field identifies the schema, the one under properties describes the _id of a user document — the email.

The user accepts with a PATCH /users/{userId} on their own document. Nothing authorizes that request out of the box, and the guard never gets a say on a request the ACL has already refused: without a permission of your own the acceptance is a 403 and the user is locked out for good.

restheart-accounts does install a rule of its own on /users, but it is a veto — it denies self-service writes to _id, password, roles, team, teams, sub, socialAuths, providerId and the one-shot token fields. A veto never grants. Every other field, consents included, is left to your ACL.

Create the permission in Service → Permissions (see Managing Permissions):

The request the client sends is then just:

A few things are doing work here:

Add both latestConsents/tos and latestConsents/pp to the JWT claims in Service → Users → JWT Claims (see Managing Users), so the condition also holds for users authenticating with a token.

The rule must exempt the very request the user sends to accept — the PATCH of step 2. bson-request-whitelist(consents) scopes the exemption to exactly that request, so the rule does not open up self-service writes to any other field.

The same condition, broken up as it reads:

A JWT is a snapshot taken at issuance. After a user accepts, the token they are holding still says they have not, and the rule keeps blocking them — so the acceptance has to be followed by a new token.

Which request you make depends on what the client is holding.

Holding a bearer token — the usual case right after an acceptance — add ?renew=true to get a new one issued without re-sending credentials:

This request is made while the user is still blocked — the token it carries is the one that says they have not accepted. That is why /token is among the exclusions of the condition: without it the acceptance can never take effect.

Authenticating with credentials — ?renew=true is not needed. Every GET /token authenticated with Basic credentials is a fresh issuance built from the user document as it is read at that moment:

The renewed token is built from the user document read again from the database, so it carries latestConsents as it is at that moment — along with any other change, including the user’s roles.

The alternative, and often the better one: have the acceptance endpoint return the new token in the same response. That is what restheart-accounts does when a user switches team or activates their account. It saves a round trip, and the user never passes through a state where they are blocked by a decision they have already made.

Signing out and back in works too. It is the blunt version of the same thing.

Five requests, on a test account that has not accepted yet. Run them in order — each one tells you which piece is wrong if it does not answer as described.

Then check the user document: latestConsents carries the versions and an acceptedAt the server wrote, and consents has one record per acceptance rather than one that keeps being overwritten.

The application never checks whether the user has accepted. It reacts to being told:

Nothing in the client compares versions. That is what keeps the two sides from drifting: raise the version in the rule and in the permission, and every client starts seeing 451 on the next request, with nothing to rebuild or redeploy.