Contents
- allow 'admins' to delete/overwrite attachments?
- Disallow removal of own admin permission
- Is it possible to disable read on ALL pages except login?
- Why is block all except login possible with the following scenario?
- Administrating ACLs is cumbersome
- You can't change ACLs on this page since you have no admin rights on it!
- Lost Admin Rights?
- attachments only for certain users
- Project group members need permission to create new group pages?
- How to change a protected page into a non protected page
- Adding Myself As An Administrator
- How to prevent user-creation?
- Adding users
- How do I set the limit on the size of attachments?
- Prevent Editing When Not Logged In
- Disable overwriting attachments for common users
- Changing ACL-Rights on user-created pages without giving every user ACL-'admin' rights on the whole Wiki?
- Cannot get AutoAdmin to work
- Also cannot get AutoAdmin to work
- NewPage macro + ACL = You are not allowed to edit this page
- Groups in ACL are ignored
- Groups are ignored in ACLs
- After upgrade to 1.9.2, from 1.8.1, acl_hierarchic does not work the same
- Is it possible to have a password prompt on page approval?
allow 'admins' to delete/overwrite attachments?
At the moment only superadmins are allowed to delete or overwrite attachments on our page, is there any way to configure a 1.8 moinmoin to make this possible for normal admins/special usergroups? Tried several searches here on that theme but wasnt very successfull as it seems.
I don't think your problem is related to "superuser" configuration, but rather a standard ACL problem. For deleting or overwriting (which is deleting and writing) attachments, you need to have "write" and "delete" rights on the respective wiki page. If you are not logged in, you usually don't have "delete" rights. If it still does not work after logging in, check your acl_rights_* configuration and the ACLs on that page.
Disallow removal of own admin permission
Users often make mistakes editing ACL strings and inadvertantly change the page permission such that they cannot revert the change. There should be a configuration option disallow removal of your own read/write/admin permission on a page. Or maybe a confirmation dialog warning them that they are about to remove their own permission from the page. -- VitaliyShchupak 2008-07-20 11:48:22
This is why you don't give admin rights to users not capable of correctly using it. -- ThomasWaldmann 2008-07-20 12:10:37
Is it possible to disable read on ALL pages except login?
I want to prevent viewing of every single page (all, even the help pages) in my wiki. Users in a certain group will be able to view pages after logging in. The problem is that many pages (Help, recent changes, etc...) specify read for All in their ACL. The only way to override that is to specifly no privs for All in acl_rights_before, but then that would block everyone from the login page too. The FAQ above for closed community says to use acl_rights_default and set All : blank, but that won't stop people from seeing help and recent changes. Is there any way to do this other than to edit every page in the system to remove the All : read line?
- You have two options:
- Change the ACL of all problem system pages and add All: to block anonymous users. You want to do this change with a script, so you can fix the ACLs after upgrading the system.
Write custom SecurityPolicy that block anonymous users on all pages expect the login page. This should be easier and avoid upgrading issues.
System / Help page ACLs were changed in moin 1.7 (they just take away "write" rights now and otherwise use Default ACLs. So if you change your default ACL, the change is also implemented by the system / help pages.
Why is block all except login possible with the following scenario?
In MoinMoin ver. 1.6.0, with acl_hierarchic = True and acl_rights_after = u"All:", the above (block all pages except login) is accomplished. We have acl_rights_before set to allow a specific admin group all privileges, and acl_rights_default set to allow a user group read,write,delete,revert. Only users in either the admin or user groups can view pages at all. My question is, why does this work? Is it a bug or a feature?
- Sorry, I have trouble to understand your question.
There is a bug in hierarchic ACL processing, see SecurityFixes. <- That's why it's behaving in that manner. Thanks.
- Strictly taken, using "All:" ACL doesn't make much sense (it does no harm, but it is not necessary).
Administrating ACLs is cumbersome
Here's what I want to do. I want a certain user to be able to manage ACLs for a certain area of the wiki... say everything under a certain page. Without any hierarchical access control scheme, I can't just give him admin rights to the top page and let him go. It means that every single page he creates that needs any sort of access control, I have to go and manually add them to each page ONE AT A TIME! This is not only an annoyance for me, it also slows him down.
So I came up with an Idea I thought might work... Create a template that contains an ACL line giving this author admin rights, and restricting read rights so that only he has access to that template. I thought this might allow him to create pages by basing them off of this template. But alas, it appears that creating a page from a template amounts to a cut and paste of the text from the template, so non-admin types are not allowed to "add" the ACL's to the new page (even though they were already granted in the template).
Does anyone know of a way to give someone the ability to create certain pages with them as an admin, but without giving them admin rights to the entire wiki? -- SteveDavison 2007-03-01 22:03:43
Have a look at HelpOnAutoAdmin! -- DavidLinke 2007-03-01 23:50:18
Sure enough. Thanks David, that solves most of my problem. I'll file a FeatureRequest for the rest.
You can't change ACLs on this page since you have no admin rights on it!
I get this error msg when I try and save a newpage w/ ACL's on it and I the TrustedGroup has admin rights to both.
Here's the ACLs on the page #acl TrustedGroup:read,write,delete,revert,admin
Here's the ACLs on the template for the new pages created by this group #acl TrustedGroup:read,write,delete,revert,admin
the result is the new pages fail to save w/ this error You can't change ACLs on this page since you have no admin rights on it!
thanks in advance
--Andrew
I added acl_rights_before = u"admin:admin,read,write,delete,revert TrustedGroup:admin,read,write,delete,revert" to the wikiconfig.py and trusted group can add pages now! Seems that before doing this TrustedGroup could admin, edit pages, edit the ACL lines on the pages, just not save a new page w/ an ACL line included. Not sure if a bug or pilot error...
Lost Admin Rights?
I think I'm in over my head. I am completely new to wikis. But yesterday I set up a wiki page and specified myself as the administrator. I then set up a users page, and I went to edit one of the names I listed, and it said "You are not allowed to change this page." I can't figure out what happened. Thank you -- Laura 19 Dec 06
The page HelpOnAccessControlLists in your wiki describes how it works. Keep in mind that "admin" right only means "being able to change ACLs", it does not include any other right like "read" or "write".
attachments only for certain users
Is it possible to finetune ACL to allow anonymous and new registered users to edit the page but WITHOUT the permission to add attachments. and add an ACL rule to each user that should be allowed to add attachments. thank you for your responds. HatschMa 01/12/2006
Not with a standard moin, it just uses the page ACLs for the page's attachments. For moin 1.5 you could patch AttachFile.py to not check for "write" rights, but for "attachwrite" right and add that right to the valid ACLs list. In some future moin version (not 1.6), file attachments will be first class items with own ACLs.
Project group members need permission to create new group pages?
I set up some independent groups, each one with it's own adminstrator. The default permissions permit Known users to read/write/edit but not admin for default pages. I set up templates for each group that allow the group to read/write/edit their pages and their admin user to read/write/edit/admin. I find that the group users get a "you can't change the permission of this page" when they try to create a new page using the group template. Is there a trick here to make that work? Is that what AutoAdmin is for?
Many thanks in advance for your help.
Any suggestions about where to look on this one? 2024-12-22 03:33:59
How to change a protected page into a non protected page
In my local wiki (MoinMoin Version 1.5.2 on IRIX64) the page WikiSandBox is a protected page ("Geschützte Seite"). Even though I have administrator rights I did not found a way so that any user can experiment with this page. What can I do to change the status of this page?
How are ACLs configured in wikiconfig.py?
acl_rights_default = u'StudentGroup:read,write,delete,revert All:read' acl_rights_before = u'AdminGroup:read,write,delete,revert,admin '
I belong to the AdminGroup but I cannot edit this page, too.
Is there an ACL line in your WikiSandBox?
I think it is the default WikiSandBox without any ACL and because of this problem I had no chance to modify it. (Of course you can change the source code via the operating system.) It has the following lines in the beginning of the page: {{{## Please edit system and help pages ONLY in the moinmaster wiki! For more
#format wiki #language en (...)}}}
- Maybe check filesystem access rights for the underlay directory. And probably who is the owner of this dir and who is the owner of the webserver process. Does it match?
I made some tests varying owner and file permissions but had no success. It remains protected. I solved the problem for me by copying the directory WikiSandBox manually from underlay/pages into the data/pages directory and changed its file permissions according to other files in this directory.
Beside my special problem I have some difficulties in understanding the general concept of the underlay directory. I understand that pages in this directory are normally read-only and should not be altered by users. There are only few exceptions like e.g. the WikiSandBox. But what do you have to do when you like to change such a page (in a perfect installed wiki setup). How do you change the state of a page from "protected" to "non-protected"?
Adding Myself As An Administrator
I just installed the latest stable version of Moin on FreeBSD + Apache in my $HOME directory on a shared web server. Everything is working very well except for the fact that I can't act as an administrator in my wiki.
I found the MoinMoinQuestions/Administration "How To Become An Administrator", and followed its directions. First, I registered with the site using a username of TomPurl. I then checked the $INSTANCE/data/user directory and made sure that the TomPurl username existed. I then added the following line to $INSTANCE/wikiconfig.py:
acl_rights_before = u"TomPurl:read,write,delete,revert,admin"
I then logged into Firefox, but was unable to delete, rename, or add attachments to pages. To troubleshoot, I deleted all of my cookies and then logged in again. Still, no luck. I've even restarted Apache.
Can anyone else think of something that I could try to get this to work?
Thanks! - TomPurl
- probably you have missed to set
allowed_actions = ['DeletePage', 'AttachFile', 'RenamePage']
in your wikiconfig.py -- ReimarBauer 2005-12-30 18:19:39
Thanks Reimar! I missed that direction in the HelpOnInstalling/ApacheOnUnix instructions. -- TomPurl
How to prevent user-creation?
I don't want to have any users except me. I'm running Version 1.5.0beta4, so that http://moinmoin.wikiwikiweb.de/FeatureRequests/NewUserCreationACL won't run. (i tried everything, but i didn't get it)
Use access control lists.
- I can't find anything on that page that mentions disabling user creation. The login page seems to double as an account creation page. I need access to a login page, but not account creation. How do we fix that?
Please add this as FeatureRequest
Strange that this is a new feature - nobody wants his Wiki to be potentially spammed by billions of bots or something. Should be a basic feature
I've set the ACL on UserPreferences for All to nothing ("All: ") while keeping rights for registered users ("MoinPagesEditorGroup:read,write,delete,revert"). It seems to me that this lets people still login but disables creating new user accounts. Am I missing something?
- I can't find anything on that page that mentions disabling user creation. The login page seems to double as an account creation page. I need access to a login page, but not account creation. How do we fix that?
Adding users
I'm doing a wiki page for a company. My boss will be the admin, got all the rights etc. This wiki will not be edited by unknown people, only the users that my boss allow. How do the admin add the users to a group or what? Thanks.~
Do read HelpOnAccessControlLists
How do I set the limit on the size of attachments?
MoinMoin does not offer this facility, but if you use apache >= 1.3.2 then you might like to look at the LimitRequestBody directive
Prevent Editing When Not Logged In
I've searched and searched for how to do this, but can find nothing. I think the ability exists, since I have seen mention in several other questions of someone not being able to edit a page because they are not logged in. Are there instructions anywhere that describe how to configure MoinMoin to require login for edits? Thanks. --SteveDavison
What you search is part of access control, read HelpOnAccessControlLists.
Disable overwriting attachments for common users
Common users (anonymous and logged in) can't delete attachments, only administrators can do that. Which is good, because these changes can't be reverted. But I found out that anonymous users can overwrite attachments with whatever they want, it's enough to check "Overwrite existing attachment of same name" checkbox (moinmoin 1.5.7). This way evil anonymous users can destroy all my images/other attachments on my wiki in a few minutes, and I cannot revert it. How can I disable overwriting feature for non-admins? --Kamil
It is a bug: MoinMoinBugs/OverwriteAttachmentShouldDependOnDeleteRight --Kamil
Changing ACL-Rights on user-created pages without giving every user ACL-'admin' rights on the whole Wiki?
I want to make it possible for normal Users to set ACL write-permission only for themselves on their pages, to create a simple Character-Database ( http://mylairexil.de/wiki/CharakterSeiten ) is this possible without giving every ACL-'admin' rights for the whole wiki, and without intervention of an Admin or TrustedUser on every Charpage?
You should define "their" pages. Moin does not have the concept of page "owner". However, if you to give write access to sub pages of the user page, you can do this with a custom security policy. Subclass MoinMoin.security.Permissions, and define a write method that check the current page name against the current user name and allow only the user to write on his sub pages ignoring the page ACL. See SecurityPolicy for more info.
Version 1.5 has autoadmin security policy that give admin rights to user pages, but it is not recommended for common users, because they will not be able to set ACL correctly. see HelpOnAutoAdmin.
- I am confused about this as well. "their" := the page they created. This is a variation I need: I want to be able to approve the potential users when applying. However, once someone is an user, they should be able to create "private" pages (e.g. set their own permissions and edit the list of users who are 'collaborating' on the page). Is this possible? Thanks! -- ranko
Cannot get AutoAdmin to work
I want to enable users the ability to setup their Homepage using the HomepageTemplate with a pre-defined ACL. To do this they need 'admin' rights. I am using AutoAdmin and below is what I did
- Added the following line to wikiconfig.py, using Moin version 1.6.1
from MoinMoin.security.autoadmin import SecurityPolicy
Created AutoAdminGroup page
Added usernames to the AutoAdminGroup page which should enable these users 'admin' rights
But it does not seem to enable 'admin' rights. Am I missing something, can you help?
Kim Tran - 2024-12-22 03:33:59
Also cannot get AutoAdmin to work
The HelpOnAutoAdmin page is woefully inadequate. It mentions things but does not explain them fully or even tell you what they do.
Are page/ReadGroup and page/ReadWriteGroup supposed to work on projects as well as users? And how do you get them to work?
I can only assume that if a user is in ReadGroup or ReadWriteGroup that they are able to read all subpages by default, and the ReadWriteGroup also can edit. But I set up the ReadGroup and ReadWriteGroup pages with nothing in them, and I can still see and edit all of the subpages. Do I have to add ReadGroup, etc., to the AutoAdminGroup page as well as the page/AdminGroup in order to activate them?
HelpOnAutoAdmin mentions that you can set up project/ReadGroup, project/ReadWriteGroup, etc., but doesn't say what the "etc." includes. Can I create a project/RevertGroup or project/DeleteGroup? Or what about a WriteRevertGroup?
And another thing that needs explanation is, how exactly do these groups affect the ACL's of a page? Is it sort of like an automatic #acl +ReadGroup:read +ReadWriteGroup:read,write +AdminGroup:admin added to each subpage? If the subpage has its own ACL line, does this prevent the AutoAdmin ACLs from working (i.e., do the automatic rights work like "default", "before", or "after" ACL rights?
Oh, I should mention that I'm using version 1.5.8; I checked the latest HelpOnAutoAdmin and it seems to be identical to the 1.5.8 page, so I assume there haven't been significant changes since.
Thanks for any help... -- SteveDavison 2008-07-03 04:52:36
NewPage macro + ACL = You are not allowed to edit this page
I am using Moin 1.7 and am trying to set it to use the NewPage macro to make structured page creation easier on the users. I also have ACL's (hierarchic, if this matters) enabled. Now a certain user belonging to a certain group can easily create sub pages, perform edits, and do what they need to do. However, when they try to perform this task through the NewPage macro they get an error that says "You are not allowed to edit this page." As I have said before, creating this page and loading the proper template by hand works just fine. I don't know if this is the proper avenue to have this question answered but any help would be appreciated.
Cameron
Groups in ACL are ignored
Just updated from 1.5.5a to 1.7.1. To be more precise, old wiki was on Windows server with IIS and CGI. Then I installed 1.7.1 on Linux machine with Apache and fastcgi. Copied ./data, removed cache, removed all old macros, parsers and themes, performed pages migration. I took wikiconfig.py from the new distro and updated it accordingly.
I have very tight security policy with lots of groups. Now after upgrade only users who are specified explicitly in acl_rights_before, acl_rights_default or in a page's ACL get proper authorization. If user is the member of some group then he doesn't get authorized despite this group being mentioned in ACL. Look like group membership is just ignored.
I've tried switching acl_hierarchic off, searched through this site, read CHANGES and MIGRATION documents, looked in the sources, but still can't find the cause of the problem.
You likely missed the part of docs/CHANGES talking about page_*_regex configuration having changed. If you just need the usual "for English" behaviour, you can just delete all those regexes from wiki config. If you need to have it recognize something complex (like e.g. matching group page names for different languages), you have to read docs/CHANGES. -- ThomasWaldmann 2008-08-11 12:19:17
- Well, I did really miss that part. But all the pages in my wiki have English names, so I didn't get any positive result after editing or disabling those regexes.
Do you have stopped the server and cleaned the old dict cache? You can verify as superuser using the SystemAdmin page if all works after you had restarted the server process. -- ReimarBauer 2008-08-11 14:29:00
Yes, I tried both /etc/init.d/apache2 stop/start and apache2ctl restart. Cleaned cache manually by removing everything from ./data/cache before server restart. On SystemAdmin page I can only see user accounts and list of attachments. -- AlexanderAgibalov
- Well, I did really miss that part. But all the pages in my wiki have English names, so I didn't get any positive result after editing or disabling those regexes.
2008-08-12 05:49:07
Can you pastebin your wikiconfig.py? And please check if the timestamp of the pyc file is newer as the py file. I don't know what is wrong yet but it is easier to figure out if you meet us at chat.freenode.net #moin. -- ReimarBauer 2008-08-12 18:36:28
Here it is. I removed all the commented lines. .pyc file is recreated each time after I make changes in .py -- AlexanderAgibalov 2008-08-14 06:55:40
# -*- coding: utf-8 -*- from MoinMoin.config.multiconfig import DefaultConfig class Config(DefaultConfig): sitename = u'Ext.Wiki' logo_string = u'<img src="/moin_static171/common/moinmoin.png" alt="MoinMoin Logo">' html_head = '''<link rel="shortcut icon" href="/moin_static171/favicon.ico">''' page_front_page = u"FirstPage" data_dir = '/db/extwiki/data/' data_underlay_dir = '/db/extwiki/underlay/' url_prefix_static = '/moin_static171' superuser = [u"AlexanderAgibalov", u"GrigoryBaytsur"] acl_rights_before = u"AlexanderAgibalov:read,write,delete,revert,admin +MxGroup:read,write" acl_rights_default = u"AlexanderAgibalov,MxGroup:read,write,delete,revert,admin Known,All:none" acl_hierarchic = True surge_action_limits = None # disable surge protection navi_bar = [ u'%(page_front_page)s', u'RecentChanges', u'FindPage', u'HelpContents', ] theme_default = 'modern' language_default = 'en' #page_category_regex = u'^Category[A-Z]' page_category_regex = ur'(?P<all>Category(?P<key>\S+))' page_dict_regex = u'[a-z]Dict$' page_form_regex = u'[a-z]Form$' page_group_regex = u'[a-z]Group$' page_template_regex = u'[a-z]Template$' show_hosts = 1
Remove the old rules or use the new syntax for
page_dict_regex = u'[a-z]Dict$' page_form_regex = u'[a-z]Form$' page_group_regex = u'[a-z]Group$' page_template_regex = u'[a-z]Template$'
see * HINT: page_*_regex processing had to be changed to fix category search. in the CHANGES file or look into MoinMoin.config.multiconfig. e.g.
page_category_regex = ur'(?P<all>Category(?P<key>(?!Template)\S+))' page_dict_regex = ur'(?P<all>(?P<key>\S+)Dict)' page_group_regex = ur'(?P<all>(?P<key>\S+)Group)' page_template_regex = ur'(?P<all>(?P<key>\S+)Template)'
you can remove the vars completly if they are the defaults. -- ReimarBauer 2008-08-14 09:05:37
Note that this doesn't make too much sense:
acl_rights_before = u"AlexanderAgibalov:read,write,delete,revert,admin +MxGroup:read,write" acl_rights_default = u"AlexanderAgibalov,MxGroup:read,write,delete,revert,admin Known,All:none"
Reasons:
- there is no ACL right called "none"
- what you likely want is to not give Known and All any rights
- you do that by just not giving them any rights
- if you don't have a conflicting ACL otherwise, it is enough to not mention Known and All
- if you don't explicitely give some user or group some rights, they won't have rights (note that the internal default of acl_rights_default DOES give Known and All group some rights, but for your case this does not matter as you are overriding acl_rights_default)
- if Alexander is in acl_rights_before and gets all rights there, you don't need to give him rights in acl_rights_default
not sure what your MxGroup ACL settings are for. Looks like you want to give them read and write rights ever (you don't need to repeat that in default ACL), but delete,revert,admin only by default if the page ACL does not override the default.
Thus, you maybe want this:
acl_rights_before = u"AlexanderAgibalov:read,write,delete,revert,admin +MxGroup:read,write" acl_rights_default = u"MxGroup:delete,revert,admin"
Oh. You were right since the beginning. The problem was indeed with regex. Sorry for wasting your time. -- AlexanderAgibalov 2008-08-14 13:18:49
Groups are ignored in ACLs
2008-09-09 FrankSteinhauer
I have the same problem as AlexanderAgibalov (and Cameron) above - my Groups seem to be ignored. We're using MoinMoin 1.6.2.
From wikiconfig.py:
acl_rights_valid = ['read', 'write', 'delete', 'revert', 'admin', 'approve', 'review'] acl_rights_before = u"my-admin,AdminGroup:read,write,delete,revert,admin,approve,review" acl_rights_default = u"Known:read,write,delete,revert All:read" #commented out the page_xxx_regex lines
Page TestApprovalGroup: (created by a member of the AdminGroup)
#acl TestApprovalGroup:admin,read,write,delete,revert Known:read All: === All members of the ACL group "TestApprovalGroup" === * SomeUser (part of the test department) <<BR>> ---- ~-this page belongs to the CategoryAdministratorSection-~
Now SomeUser is not allowed to change the page TestApprovalGroup. Furthermore, he's not able to create a new page and set any ACLs. This looks like a "feature", since he has no admin rights yet he's not allowed to give himself the admin rights - but still it's strange. Now I have to add all "XxxApprovalGroup"s to the acl_rights_before
What is the approve right? Have you restarted the server process after removing the page_*_regex and do you have cleaned the dict cache? -- ReimarBauer 2008-09-09 15:41:34
After upgrade to 1.9.2, from 1.8.1, acl_hierarchic does not work the same
The pertinent lines of my wikiconfig.py file are:
acl_rights_default = u"AdminGroup:read,write,delete,revert,admin DnDPlayersGroup:read DnDDMsGroup:read All:"
acl_hierarchic = True
I have a page called DnD, for which I want admins to have full rights and players and DMs to only be able to read. It has the ACL line:
#acl DnDDMsGroup:read DnDPlayersGroup:read
I have a child page called DnD/DMs, for which I want admins to have full rights, players none, and DMs to have read and write access. It has the ACL line:
#acl DnDDMsGroup:read,write DnDPlayersGroup:
I then have grandchild page DnD/DMs/DragonLance, for which I want admins to have full rights and players and DMs none. It has the ACL line:
#acl DnDDMsGroup:
Everyhing was working fine in 1.8.1. After the upgrade, admins can no longer access the child page nor the grandchild page. Oddly, players can access the grandchild page.
What happened?
http://master19.moinmo.in/HelpOnAccessControlLists#Hierarchical_ACL_processing. -- EugeneSyromyatnikov 2010-06-04 07:00:12
Is it possible to have a password prompt on page approval?
I want to be able to prompt for a username and password when a user tries to approve a page or has updated/edited a page. Do you know if this is possible?
Take a look at http://moinmo.in/action/show/HelpOnAccessControlLists?action=show&redirect=HelpOnAcl You can add ACLs that require a user to be logged in before editing a specific page or any page within the whole wiki.