Sputnik's permission system allows you to control who can read or edit which pages. You can also use Sputnik "behind the scenes" to manage a site that does not look like a wiki at all.

Simply Locking It Down

Let's start with a simple answer to a common question of what to do if you want to stop random people from editing your Sputnik, or even knowing it's a wiki. If you want to do something more complicated (or want to understand how this works), see the next section.

First, to block anonymous users from editing any pages (and even seeing the "edit" link), login as administrator (e.g., "Admin"), and configure @Root. Go to "Permissions". in "Advanced Options" and change

--deny(Anonymous, edit_and_save)

to

deny(Anonymous, edit_and_save)

You can also add 'deny(Anonymous, "history")' if you want anonymous users to not be able to see history (or see the history link).

If you want to apply this restriction to some nodes but not to all, you can do by configuring those nodes individually rather than editing @Root.

Of course, if you want to block anonymous users from editing pages, then you would likely also want to stop random visitors from registering. You can do this by setting DISABLE\_REGISTRATION parameter to true.

The Details

For those who care, let me explain how this works.

Sputnik has a permission system, which may be a little complicated for this simple case, but on the other hand it is very flexible. So, you can allow/deny anyone from doing anything you want, either on a case by case basis or specifying groups of users, and you can do this for specific nodes or all nodes.

The permissions are specified by a field called "permissions", which contains Lua code that specifies permissions as a sequence of calls to two functions: allow(who, what) and deny(who, what). Both take two parameters, which specify to whom the rule applies and what actions it covers. Each parameter can be a string value or a function that takes a string and returns a decision. For instance:

allow("yuri", "edit")  -- "yuri" can "edit" (i.e., see the edit form)
allow("yuri", "save") -- "yuri" can "save"

The first parameter (who) can be a function that defines a class of users (returning true for members and false for non-members). E.g.:

allow(Admin, "edit") -- any admin can edit

The same for the second parameter (what):

deny(Anonymous, all_actions) -- deny anonymous users from doing anything.
allow("yuri", edit_and_save) -- "yuri" can edit, preview, save, etc.

The built in user classes are Admin, Authenticated, Anonymous, all\_users, and owners. The last one of those includes all users that are included in node's "owners" field. Additionally, "is.class" will match those users who have "is_class" attribute set to true in their registration record. For example,

allow(is.friend, all_actions)

will allow all actions to those users who have "is_fiend" set to true in their registration record.

The built in action classes include: all\_actions, edit\_and\_save (basic editing), show (viewing nodes), history\_and\_diff (accessing past versions), show\_etc (the sum of show and history_and_diff).

The rules are applied in order, overriding the previous ones for those users and actions that they apply to. For instance:

deny(all_users, "edit")
allow(Admin, all_actions)
deny("yuri", "edit)

has the effect of prohibiting all users from editing, except for Admins (who can do anything they want), but with an extra stupulation that "yuri" can't edit even if he is an admin.

Sputnik's nodes inherit field values from their "prototype" nodes. Prototypes can be specified explicitly (the "Prototype" field) and default to "@Root", which is every node's ultimate prototype.

In case of permissions, inheritance is done by simple concatenation of rules, from the most distant ancestor to the current node. This way down-stream rules override upstream ones.

What this all means is that setting permissions in @Root changes default permissions for all nodes, but specific nodes can add more rules.

By default, we configure @Root (the default prototype for all nodes) to allow most actions to anonymous users, and then define two additional prototypes @Text_Config and @Lua_Config which block non-Admin users from everything except for "show" and "history" (and you can comment out those two for extra security). All configuration nodes (sputnik/config, etc.) then inherit from one of those two. A few nodes (e.g., sputnik/passwords) then additionally block users from even seeing the content.