API group permissions¶
A group is a list of what may be called : tables and their APIs, fields readable and writable, custom APIs, system APIs, third party APIs, WebSocket events. An API user gets groups ; a person of your users table gets groups through the groupsColumn of its auth provider. A call passes when the API user grants it and, when a person is involved, the person too.
| Page | API Security → API Group Permissions : the groups on the left, the tree of the account on the right. |
| Grants | Instances → databases → tables → APIs, and the fields of a table with R and W ; custom APIs ; system APIs ; third party APIs ; WebSocket events. |
| Shortcuts | All APIs, All Fields, All Third Party APIs and the checkbox of a column check everything below it. New tables and APIs are covered by an "all" grant. |
| Refused with | 403 when no group of the caller grants the API ; a field not readable is absent from the answer, a field not writable is refused on save. |
Make a group¶
- Add New, give a unique name, Save Group. Clone copies an existing group.
- Open the tree. Each API shows how it is reachable, from its settings : Public, AM-User (API user token), DB-User (person token), Google, Azure, or No-Access.
- Check the APIs and, under a table, the fields : R to read them, W to write them.
- Save group settings. Active API users in this group shows who has it.
Give it¶
- To an API user : the groups list on the API User Permissions page.
- To a person : write the group names, comma separated, in the column named by
groupsColumnof the auth provider.*gives the person every group of the API user.
Good to know¶
- The pre and post hooks of an API can be limited to some groups : they run only for callers of those groups.
- The APIs Security Report lists the groups which reach too far.
- Groups go to Git : the same permissions on every environment.