An access rule (Studio calls it a policy) answers one question about one request: may this caller do this, here, now? Every table action, bucket, channel, route and subscription is protected by one. Because rules run on the server for every request, your app can talk to Pawabase directly from a browser. This section teaches rules from both sides at once: how to build them in Studio (a point-and-click condition builder, named rules, quick sets), and how to test and debug them.

​
Rules in one minute

Policy builder showing two rules joined by AND

A rule in Studio: signed in, and owns the record.

  • All of these rules pass:
    • Is signed in: yes
    • Compare values: $record.owner_id equals $auth.user_id
Read it as: the caller is signed in and the record’s owner is the caller. That is the whole idea: conditions over facts about the caller ($auth), the record ($record), the submitted data ($input) and the request. Most of the time you just choose “Record owner” from a menu.

​
Where rules are used

The same rule means the same thing everywhere.

​
Where rules live in Studio

​
Learn it in this order

1

Understand the model

Quickstart, then How rules work.
2

Build rules in Studio

Policies in Studio, the condition builder, rule references, named rules.
3

Learn the language

Facts a rule can read, operators, combining, shorthands, values and paths, how rules are evaluated.
4

Apply them

Per surface: tables, storage, realtime, routes, events.
5

Copy recipes, then prove them

Ownership, roles, content, teams, sensitive actions, then testing and debugging.

​
Built-in rules

You can use these by name anywhere a rule is accepted: