> ## Documentation Index > Fetch the complete documentation index at: https://docs.xano.com/llms.txt > Use this file to discover all available pages before exploring further. # Realtime Access Control > Who can connect, who can join, who can publish, and who receives — controlled at the server, channel, and message level. This page covers the current version of Realtime. For the original channel permission rows, see [Channel Permissions (Legacy)](/realtime/channel-permissions). Realtime access control is layered. Each layer answers a different question, and the layers are independent — a permissive channel can still hold restricted messages. | Layer | Question it answers | | ------------------ | -------------------------------------------------------------------- | | **Server** | May this client open a connection at all? | | **Channel** | May this client join, publish, see others, or address them directly? | | **Message** | May this client invoke *this specific handler*? | | **Delivery** | Should this recipient receive this copy, and what should it contain? | | **Builder (RBAC)** | May this teammate create or edit Realtime in the workspace? | ## Channel settings Each channel carries its own client-facing settings. ### Publish policy `publish.who` decides who may publish to the channel: | Value | Effect | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | `nobody` | No client may publish. The channel is listen-only, fed by [`realtime.publish`](/realtime/publishing-from-xano) from your own stacks. | | `anyone` | Any connected client may publish, authenticated or not. | | `authenticated` | Only authenticated clients may publish. Anonymous clients can still join and receive. | `nobody` is the right shape for a notification feed or live dashboard, where every update should come from a task or an API endpoint rather than a client. ### Anonymous clients `access.anonymous` decides whether unauthenticated clients may join. Turning it on lets a client subscribe without a token; it does not by itself let them publish, which is governed separately by `publish.who` and by each message's authentication requirement. ### Presence `access.presence` decides whether every client on the channel receives the list of other connected clients, and updates as clients join and leave. Presence is what powers "who's here" indicators and active-collaborator avatars. ### Client-to-client addressing `publish.direct` decides whether one client may address a message to another specific client on the channel, rather than to the channel as a whole. ### Rate limiting `rate_limit.messages_per_minute` caps how much an individual client may send, with `0` meaning unlimited. This is the first line of defense against a client — buggy or hostile — flooding a channel. ## Requiring authentication per message Separately from the channel's join policy, an individual **message can require authentication**. This is the setting that lets a channel be read-open and write-closed: * The channel sets `access.anonymous` to true, so anyone can join and receive broadcasts. * The `post_comment` message requires authentication, so only signed-in clients can invoke it. Because it's per message, one channel can mix them: a `typing` indicator open to everyone on the channel, and a `send` handler that isn't. ## Authorizing with your own data Settings answer *"is this category of client allowed?"* Triggers answer *"is **this** client allowed, given what's in my database?"* * A **connect** trigger can veto the connection outright. * A **join** trigger can veto a join — check the room from the channel path against a membership table and reject anyone who isn't a member. * A **deliver** trigger runs per recipient and can drop or redact that individual copy. This is the part that has no legacy equivalent: access control becomes code you write against your own tables, rather than a fixed set of checkboxes. See [Realtime Triggers](/realtime/realtime-triggers). Triggers require a paid instance. `realtime.publish`'s `auth_table` and `auth_id` arguments are **attribution only** — they stamp an identity onto a server-authored event so recipients can see who it came from. They authenticate nothing. Never treat them as an access check. ## Securing a channel end to end Securing Realtime is rarely a single setting. A sound setup usually combines: * **Channel settings** matched to the use case — don't enable publishing, presence, or anonymous access you don't need * **Typed path templates**, so a channel address can't be anything a client makes up * **A join trigger** that authorizes the client against your own data * **Per-message authentication** on anything that writes * **A deliver trigger** where recipients should see different things * **Rate limiting**, so one client can't degrade the channel for everyone * **Separate auth tokens** for the realtime connection, generated when the user logs in or signs up ## Builder permissions (RBAC) Everything above is about connected clients. Who on your *team* can create, edit, and delete Realtime servers, channels, and messages inside the Xano builder is governed separately, by the **Workspace Realtime Features** permission in [role-based access control](/enterprise/enterprise-features/rbac-role-based-access-control). It's the same permission that governs [Realtime (Legacy)](/realtime/realtime-in-xano) — a role that can manage one can manage the other. Without at least Read on that permission, the **Realtime** entry doesn't appear in the workspace side navigation at all. ## Next steps Veto connections and joins, and rewrite deliveries. Channel path templates and settings. ## Related topics - [Realtime](/realtime/overview.md) - [RBAC (Role-based Access Control)](/enterprise/enterprise-features/rbac-role-based-access-control.md) - [Role Based Access Control (RBAC)](/team-collaboration/role-based-access-control-rbac.md)