Realtime Access Control

Realtime access control is layered. Each layer answers a different question, and the layers are independent — a permissive channel can still hold restricted messages.

​

Channel settings

Each channel carries its own client-facing settings.

​

Publish policy

publish.who decides who may publish to the channel: 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.

​

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. It’s the same permission that governs Realtime (Legacy) — 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