Using the SecurityPolicy option
SecurityPolicy is a config option that allows wiki admins to dynamically enable or disable certain key actions in a MoinMoin wiki, most notably editing and deleting content. For more details, see HelpOnConfiguration/SecurityPolicy.
If you use moin 1.1 or later, be aware that there are AccessControlLists, too, which make some of this stuff quite a bit easier. The default security MoinMoin uses is then based on ACLs, if enabled.
This page contains different usage examples. See also AccessControlList.
Content
Contents
1. Anti Spam
Here used to be an example of how to use SecurityPolicy against spammers. This is superceded by AntiSpamGlobalSolution.
2. Examples - MoinMoin 1.1
2.1. Only allow editing for known users
By default the access control list default rights are set to:
acl_rights_default = u'Known:read,write,delete,revert All:read,write'
"Known" = "logged in users, "All = everyone else". If you want to prevent anyone who is not logged in from editing pages add this to your wikiconfig.py:
- # Only allow logged-in users to edit screens
acl_rights_default = u'Known:read,write,delete,revert All:read'
2.2. Disable editing over HTTPS
The following makes an intra-net wiki available in read-only form via HTTPS. It's an extra security measure, in addition to password protection, against content changes from the outside. The same scheme can be used to have two different URLs pointing at the same wiki, and have only one of those URLs1 being able to edit the wiki. The net effect is that you have a read-only wiki editable only by certain people.
Add this to your wikiconfig.py:
# permissions
from MoinMoin.security import Permissions
class Config...
class SecurityPolicy(Permissions):
def edit(self, pagename, **kw):
from MoinMoin import webapi
return not webapi.isSSL() and Permissions.edit(self, pagename, **kw)
def delete(self, pagename, **kw):
from MoinMoin import webapi
return not webapi.isSSL() and Permissions.delete(self, pagename, **kw)
This is curios. I would use it in the opposite direction. https to edit because user and password is sent encrypted and readonly from http. Did I have missed something? -- ReimarBauer 2005-11-19 22:21:34
I also do it the other way, only allowing editing if HTTPS, but that's easy to do by just removing the not operators. I think the example assumes (without making it clear) that a firewall is in place which only allows HTTPS in from the outside, but on the inside plain HTTP is also allowed and used because it has less overhead and the inside network is assumed to be trusted. So under those assumptions if it's HTTPS then it is assumed to be from outside and thus should be immutable. -- DeronMeranda 2006-01-11 07:01:15
3. Examples - MoinMoin 1.3
3.1. SSL-only Revert, Write, Delete
from MoinMoin.security import Permissions
class Config(FarmConfig):
class SecurityPolicy(Permissions):
def revert(self, pagename, **kw):
return self.request.is_ssl and Permissions.__getattr__(self, 'revert')(pagename)
def write(self, pagename, **kw):
return self.request.is_ssl and Permissions.__getattr__(self, 'write')(pagename)
def delete(self, pagename, **kw):
return self.request.is_ssl and Permissions.__getattr__(self, 'delete')(pagename)
4. Examples - MoinMoin 1.5
4.1. SSL-only Write
If you want for security reasons that users do not edit the wiki without using SSL you should add:
# permissions
from MoinMoin.security import Permissions
class Config(DefaultConfig)
class SecurityPolicy(Permissions):
def write(self, page_name):
return self.request.is_ssl and Permissions.__getattr__(self, 'write')(page_name)
Don't forget to replace Config with FarmConfig if you're using Wiki farming.
5. Discussion
Perhaps we can integrate a WikiFeatures:LinkBan list with the MovableType ban list. -- LionKimbro (2004-04-30)
5.1. How to have multiple SecurityPolicies
You can't have more then one SecurityPolicy in your config, but you can add policies by sub-classing. For example, to use both AntiSpam and your own policy, create your class like this:
from MoinMoin.util.antispam import SecurityPolicy as Permissions
class SecurityPolicy(Permissions):
def write(self, pagename, **kw):
return (Permissions.write(self, pagename, **kw) and
self.request.user.valid)
In this example, a user will be able to write only if the user is valid and does not annoy antispam 
5.2. Use Server Authentication
It would be nice if the wiki would automatically determine if a user has been authenticated through a web server and use that for the User. If I happened to be using IIS, I could set it up to authenticate and then use os.environ['REMOTE_USER'] to find out who they are. If I were using Apache, I could do the same. If I were using Orion, etc, etc.
This is how Twiki does it (roughly). The thing I don't like about it is that authentication usernames don't typically match WikiNames so you now have to maintain a mapping of usernames to WikiNames. It's not that big a deal but it's kinda confusing until you get used to it. Also I don't believe that Apache's Directory/Location directives will match URL get parameters so all you can do is restrict access entirely. You can't restrict certain fuctions. -- AdamShand
I've done a few patches to my MoinMoin 0.8 distribution to handle this case. Since it's an intranet site, I require authentication on my Wiki, and I use the login name (rather than the randomly generated cookie) as the Wiki user, so there's no mapping problem. I did it in a kind of slipshod way, and I've never gotten the energy to do it right. I'll submit my hacky patch when I get the chance. -- RobLa
5.3. Extension & Ideas
5.3.1. Groups of Users
ACLs let specific pages be protected, but it should be possible make specific features (such as the ability to save a page with XML content) available only to users who have asked for the ability (and been recognized as a sensible human).
6. OLD CONTENT, needs refactoring
I actually have a rather different security problem. I would like to set up a non-firewalled wiki but only a certain group should have access. This may be for legal reasons, but has been imposed as a requirment that I cannot get around. Anyone know of a wiki that restricts access in such a way?
Yes, see OrgPatterns which runs in FishBowl mode. - This may be exactly what I was looking for... thanks!!!
Why not use webserver passwords to restrict access? Or do you wish to restrict editing by a restricted group? -- AnonymousCoward ;)
Even restricting the editing could be done easily using the security the webserver provides.
OTOH, few users have ".htaccess" enabled for them, and even fewer have access to the "httpd.conf".
I played with trying to get Apache's htaccess stuff to work to restrict editing privledges with MoinMoin and couldn't get it to work. I believe that this is because the Directory/Location/File directives will not match get parameters in the URL. I think this is why TWiki uses different scripts for the different functions rather than parameters passed to the main script. If I'm wrong and someone has made this work I'd love to hear about it. From an intranet point of view another feature that would be nice is the ability to restrict access/edits based on category. -- AdamShand
It's in there. See MoinMoin/security.py (I use this in a wiki to disable editing via HTTPS). --jh
I might have misunderstood the above, but you can do url rewriting on the QUERY_STRING to, eg, force login over ssl -- JayD
It isn't included in 0.9 but I see it in the current CVS repository. However I only see the option for requiring users to log in, I don't see anything which allows restriction of permissions (is that still coming or am I missing something?). -- AdamShand
In case you have the ability to modify your .htaccess file, here's the .htaccess file I'm using to allow wiki reading-only by userone and wiki reading-and-writing by usertwo, while denying access to everyone else:
AuthUserFile /path/to/.htpasswd Authname "My Group" AuthType Basic <limit GET> require user userone usertwo </limit> <limit POST PUT DELETE> require user usertwo </limit>
7. Help on Security
There are two types of security issues.
7.1. Malicious use of Editability
This is more of a design or philosophical issue, and is discussed elsewhere. See in particular, Section 1.6 of HelpMiscellaneous/FrequentlyAskedQuestions.
Edit priveleges can be controlled using access control lists. See also HelpOnConfiguration/Security.
7.2. Exploits
The second type of security issue is exploits of particular implementations/installations of a wiki. This would be of interest to any system administrator considering installing a wiki, whether or not the wiki is expected to have valuable content. A reference assessing the current risk of exploitability, and a way of staying current as exploits and patches are found, would be valuable. Even a general discussion of issues with enabling python cgi scripts that can read and write files would be valuable.
An URL that is password-protected, by means of Apache server rules. (1)