From taylor at metasyntax.net Sun Aug 31 17:24:45 2008 From: taylor at metasyntax.net (Taylor Venable) Date: Sun Aug 31 17:37:06 2008 Subject: [Sputnik-list] Way to lockdown editing features? Message-ID: 20080831152445.498b8e70.taylor@metasyntax.net

I looked around a little bit in the online documentation but couldn't find anything, so I'll ask here and hope it wasn't so obvious that I look foolish. :)

Is there a way to remove the ability to register a new account, and to prevent anonymous page edits? I'm looking to possibly use Sputnik for a replacement for a standard website, but I don't want anybody but a select few to be able to edit it.

Thanks!

-- Taylor Venable http://real.metasyntax.net:2357/

foldr = lambda f, i, l: (len(l) == 1 and [f(l[0], i)] or

                     [f(l[0], foldr(f, i, l[1:]))])[0]

From yuri at sims.berkeley.edu Sun Aug 31 18:56:11 2008 From: yuri at sims.berkeley.edu (Yuri Takhteyev) Date: Sun Aug 31 19:08:39 2008 Subject: [Sputnik-list] Way to lockdown editing features? In-Reply-To: 20080831152445.498b8e70.taylor@metasyntax.net References: 20080831152445.498b8e70.taylor@metasyntax.net Message-ID: fa4efbc00808311356xff55717qa5be7c72e626d65a@mail.gmail.com

I looked around a little bit in the online documentation but couldn't find anything, so I'll ask here and hope it wasn't so obvious that I look foolish. :)

I think it's not documented, though not for any particular reason - I just haven't gotten around to it. :)

Is there a way to remove the ability to register a new account, and to prevent anonymous page edits? I'm looking to possibly use Sputnik for a replacement for a standard website, but I don't want anybody but a select few to be able to edit it.

Yes to both. (And I do myself use Sputnik as a replacement for a regular site that I wouldn't want other people to edit.)

Let me first give you the simple answer (maybe not as simple as it should be), then explain how it works.

First, to block anonymous users from editing any pages (and even seeing the "edit" link), edit @Root (as "Admin"), go to "Permissions" in "Advanced Options" and change

--deny(Anonymous, "edit")
--deny(Anonymous, "save")

to

deny(Anonymous, "edit")
deny(Anonymous, "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).

Second, to remove the registration option, go to "sputnik/register" (click on the registration link) as Admin, click on "edit", go to "Actions" in "Advanced Options" and change

show = "register.show_form"
submit = "register.submit"

to

--show = "register.show_form"
--submit = "register.submit"

This will disable registration or new users.

Finally, to remove the registration link form all pages, edit "sputnik/translations" and change:

en_US = "<a $login_link>Login</a> or <a $register_link>register</a>",

to

en_US = "<a $login_link>Login</a>",

(Watch for that closing quote and the comma.)

Now, 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.

The built in functions are: Admin, Authenticated, Anonymous, allusers, and allactions. (The latter two always return true.)

The rules are applied in order, overridomg 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 @TextConfig and @LuaConfig 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.

• yuri

-- http://sputnik.freewisdom.org/