• Applicable Software: MokoNtfy

Access control & roles give you fine-grained, topic-level control over who can read and write each MokoNtfy topic. On top of the built-in owner, admin and user roles you can now build your own custom roles, bundle users into groups, lock down sensitive topics as protected, and preview exactly what any person can do on any topic — all from Site Administration.

Custom roles (RBAC)

A role is a named bundle of capabilities that you can assign to a user or to a whole group, so you can delegate a subset of administrative power without handing out full admin. Capabilities come in two kinds:

  • System capabilities — server-wide powers (for example, managing users or topics).
  • Topic-scoped capabilities — a capability that applies only to a topic or a pattern such as alerts-*, so a role can be granted authority over one namespace and nothing else.

Admins and the owner already hold every capability, so roles exist to grant power to regular users and groups, never to restrict admins. Role management is owner-only — only the owner can create, edit, delete or assign roles.

Groups

Groups bundle users together so a single topic-access grant applies to every member. Grant a group read, write or read-write on a topic (or pattern) and every member inherits it; add or remove members and their access follows automatically. A user's own per-user grant always takes precedence over a group grant, so you can make a targeted exception without dissolving the group.

Topic-centric access view

Open Site Administration › Topics to browse every topic that has any access grant or reservation and see, at a glance, who can access each topic. Select a topic to list the users, groups and the Everyone grant that match it, along with the pattern that granted each one. Access is edited here through the same per-user and per-group grants used on the Access and Groups pages, so there is one consistent model however you look at it.

Protected topics

Marking a topic (or a wildcard pattern such as team-*) as protected means it requires an explicit user or group grant. The fall-through Everyone grant and the server's default access no longer reach a protected topic — but owners, admins and the topic's reservation owner always retain access. Protecting a topic removes its exact Everyone grant; a broader Everyone wildcard is left in place with a warning. Use the Protect / Unprotect buttons on a topic in the Topics view, or manage the whole registry under Protected topics.

Effective-permission preview

Not sure whether a change did what you intended? The Access preview answers “what can user X do on topic Y?” directly. Pick a user (or Anonymous, for a not-signed-in visitor) and a topic, and MokoNtfy reports read allowed/denied and write allowed/denied. The result is resolved by the real authorization engine, so it reflects roles, groups, protected topics, the Everyone grant and the default access exactly as they would apply in production.

Saved logins

Saved logins are the per-browser credential store for protected topics and servers — the feature previously shown under a different name. It is now clearly labeled and reachable by every signed-in user, so you can keep the usernames and passwords your browser uses to reach protected topics in one place.

From the command line

Everything above can also be driven from the server CLI, which is handy for scripting and automation:

  • ntfy role — create roles, add/remove capabilities, and assign/unassign them to users or groups.
  • ntfy group — create groups, manage members, and grant group topic access.
  • ntfy protectadd, remove and list protected topics and patterns (optionally recording a note explaining why).

Where to find it

Sign in as owner or admin and open the Site Administration area. You will find the Access, Groups, Roles (owner-only) and Topics pages there. Saved logins is available to every signed-in user from their account menu.