See also: HierarchicalAccessControlList, HelpOnAccessControlLists

FAQs

• Q: Why is there no "page owner" concept (like giving admin rights to the user that created a new page)?
  • A: Giving admin rights to more or less anybody would open a door to abuse (like locking out users, "hijacking" of pages or posting nonsense on pages and then protecting that nonsense by ACLs). The problem in that case is, that soft security does not work here - you would need an admin to clean up the mess. If you really want to have a behaviour similar to that, see the usage scenarios - but this is not recommended for internet wikis.

ToDo

• JürgenHermann will refactor Page so that metadata/pragma parsing happens immediately, not in send_page

• a user w/o a password set is never trusted, i.e. he belongs to "Known", but he never gets assigned user or group specific rights

  • a user using basic authentication of apache (and other external authentication methods) is also trusted, of course

• i18n of messages

  • de

  • it

• docs on HelpOnAccessControlLists + i18n

  • en

  • it AiutoSuListeControlloAccesso (LeleGaifax)

• changed moin-editor-backup.txt to be an ACL-protected (sub)page of user homepage - otherwise we would disclose protected informations to all!

• a user should NOT receive a full diff in an email if they do not have read permissions on the page. Getting notification of change is OK, as the page change currently still shows up on RecentChanges -- JonathanDietrich

Ideas for later

If you want to have a feature added, please refer to FeatureRequests! (FeatureRequests/AclRefactoring)

• Translating ACLs to a more "cleartext" representation shown if any change was made.
• Nicer user interface.

• Display current rights (those from the page & defaults combined) on PageInfo.

  • Not sure about: ... but only to admins of that page; tell other users that there are special rights for that page, but no details

    • would lead to administrative delays: you can't ask a "admin" user because you don't know him, so you have to ask the admin, who gets lots of work then
    • this would prevent users from knowing whom to ask in case of problems
    • Maybe just display a list of the admins for non-admins
      • Maybe just display "admin" users - so let people know whom to ask
• When you try to go to a page now, to which you have no read access, when you arrive you will be told you cannot read it. It would be nice if the link to the page didnt exist, or maybe a "no entry" icon was displayed next to the wiki link, or the link didnt link but was in a different colour. It saves going backwards and forwards to links you can't read. And in the case where there is no link it would save the wiki processing time.

• To allow comments (additions) for locked pages, one could add a marker after which editing is allowed. The same could be had (w/o any additional work) by creating a subpage like /Comments. An extension would be to have ACLs for parts of pages, i.e. there is not just one marker, but a page falls aparts into page parts, each with its own permissions (much work, ROI questionable).

• "less-than-read right" (let's name it "nowiki") - "read" allows a user to see the wiki page the same way as any high-privilege user. For some CMS-like applications this is maybe not wanted, but "nowiki", a "content only" view, which shows the page content only, but no header and footer and other wiki-related functions.

  • should be easy to implement by doing it just like action=print

  • with acl_rights_default = Known:read,write All:nowiki any anonymous user would see a simple web page, not knowing that he is in a wiki, while any Known members see and edit the wiki as normal.

  • stuff like RecentChanges, FindPage can be linked normally where needed

  • Navigation macro can also help building custom navigation

  • one could even think about a simple template used to generate some header/footer for that case

  • As discussed on IRC, I really don't think this should be implemented on ACLs. IMO, this is not access control, and would be better implemented as a theme, when we get support for them. Meanwhile, the user can replace the header and footer, like the guys at http://www.d00dz.org have done.

    • Is there anything that explains what the folks at d00dz.org did?

    • May I argue, that having different contents displayed for the same url based on Username is exactly an Access Control. And this is really useful. And does not fit into the concept of theme. This is exactly choosing what to display based on access controls. Maybe this is theme based on access control, if you like, but this is a bit perverted .

        Example:
      You manage an corporate wiki, and your boss doesn't want to see there anything not related to corporate work.
      Using such acl controlled content you may publish your holiday's photos but only to a small group of permitted to see,
      and your boss can get only an empty page or page full of financial graphics and not an ACCESS DENIED

      • That is a humour, but you know, every joke have a bit of joke...

• Add ACL for create a new page. Only permitted user/group can make a new page. It prevents an anomymous user creating a test page. acl_default = 'Known:read,write,delete,revert,create All:read,write' .

  • you don't actually need that, just use acl_rights_default = u"Known:read,write,revert All:read" and unknown users won't be able to create new pages. You do need a “create” ACL if you want give (anonymous/group/whatever) users the rights to edit a existing pages (without an explicit #acl in each one) but not create new ones. -- LucaLesinigo

• "see-right". Even if a user is not allowed to read a wiki page, she still sees links to it on other wiki pages. This could be too much spoiler (e.g. in a Star Wars wiki, a page called EpisodeNr6/PalpatineDies). Consequences: censored (black box?) instead of wiki pagename on other pages

• Feature Request: Ability to automate creation and maintenance of large group acl lists. Example scenario: A hiking club with several hundred members provides a wiki open to the public but needs to restrict a small subset of pages containing private information to club members. A macro that could be put in an ACL list to grant rights to a logged in user whose email address is in a separate list of club member email addresses would be very useful. -- MikeEllis

  • You can just put all member (wiki) names onto a group page and use that group in ACLs.
• I considered that but there are some problems:
  1. I need to roll it out all at once for the entire club. There are 700 members. If I make up names and passwords for all the members it deprives them of their choice of names. OTOH, if I let them create their own names, I have to detect somehow that a new user has signed on, then manually check if he or she is club member, and add the names, one by one, to the list.
  2. The club membership list is maintained by another club member who wants to keep his familiar MS Access database and provide me with an updated CSV list from time to time. I'd have to manually check for additions and deletions since the members don't create wiki names when they send in their (paper) application forms.
  3. A large fraction of the club members are retired and rather unsophisticated in their understanding of computer user interfaces. Many of them can send email and click links and not much more. I have to make all this as simple and foolproof as possible

  I'm quite willing to write a macro and share it with the MoinMoin community, but before starting that task it would be comforting to know if it's possible. Does macro evaluation take place before ACL processing and is there an interface for a macro to read the email address of the user? --MikeEllis