- 000002 by yuri@... on 2008/08/31 at 23:56 GMT
000001 by taylor@... on 2008/08/31 at 22:24 GMT
Page Content
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,
all_users, and all_actions. (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 @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.
- yuri
--
http://sputnik.freewisdom.org/
