ApexKit Advanced Access Control Policies: Guide & Reference — ApexKit Docs

# ApexKit Advanced Access Control Policies: Guide & Reference ApexKit features a JSON-based Attribute-Based Access Control (ABAC) and Role-Based Access Control (RBAC) engine. This allows developers to write declarative, fine-grained access control rules directly inside their collection schemas. Policies are evaluated: 1. **In-Memory** using the lightweight `FilterNode` engine to validate REST and WebSocket payload transitions. 2. **At the SQL Layer** by compiling rules into optimized SQL clauses injected into `WHERE` statements (Row-Level Security / RLS). --- ## 1. Context Variables The policy engine exposes three distinct scopes for evaluating access. These can be used on either the left-hand side (key) or right-hand side (value) of your comparison operations. | Variable Prefix | Scope Context | Commonly Used For | | :--- | :--- | :--- | | **`@request.auth`** | The active authenticated session claims. | Checking roles (`.role`), emails (`.email`), and user IDs (`.id`). | | **`@request.record`** | The incoming request payload submitted by the client. | Enforcing constraints on what data is being created or patched. | | **`@record`** | The existing record currently stored in the database. | Enforcing constraints on reads, updates, and deletions based on the current state. | --- ## 2. Supported Operators ### Comparison Operators * **`$eq`** / **`eq`**: Equal to * **`$neq`** / **`neq`**: Not equal to * **`$gt`** / **`gt`**: Greater than * **`$gte`** / **`gte`**: Greater than or equal to * **`$lt`** / **`lt`**: Less than * **`$lte`** / **`lte`**: Less than or equal to * **`$in`** / **`in`**: Actual value exists inside the expected array * **`$nin`** / **`nin`**: Actual value does not exist inside the expected array * **`$contains`** / **`contains`**: Text substring check ### Logical Operators * **`$or`**: Evaluates to true if *any* of the child conditions are met. * **`$and`**: Evaluates to true only if *all* child conditions are met. --- ## 3. Database Subqueries (`@get()`) The `@get()` directive executes an in-context query against any collection. This is used to validate relationships across collections. ### Syntax ```json { "@get()": { "from": "collection_name", "select": ["field_name"], "where": { "field": "value" } } } ``` ### Critical Rules 1. **Flattening:** The query engine automatically flattens the selected field array (e.g. `[{"id": 1}, {"id": 2}]` is flattened to `[1, 2]`), making it compatible with `$in` and `$nin` operators. 2. **Nesting Constraint:** **`@get()` queries cannot be nested.** * *Unsupported:* `{"tutorId": { "$in": { "@get()": { "where": { "user_id": { "$in": { "@get()": ... } } } } } } }` * *Workaround:* Design policies so that they query a single collection. Relationships are modeled by comparing record variables directly. --- ## 4. Policy Debugging (`@log()`) To audit and trace how policies are resolved, wrap your root policy inside the `@log()` directive. ### Syntaxes