Tags:
create new tag
view all tags

Question

Is it possible to disable editing for certain registered users.

The case being where certain users would be allowed to view restricted topics but never allowed to edit any topic.

Environment

TWiki version: TWikiRelease04x01x02
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS: EH linux
Web server: apache
Perl version: 5.8
Client OS: Windows XP, Linux, Mac
Web Browser: IE Firefox Safari
Categories: Security

-- PeterJones - 09 Dec 2007

Answer

ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

For editing TWiki topics, there are settings to control access rights as for viewing:

  • ALLOWTOPICCHANGE is the list of users and groups who may edit a topic
  • DENYTOPICCHANGE is the list of users and groups who may not edit a topic
  • ALLOWWEBCHANGE is the list of users and groups who may edit topics in the current web (if set in WebPreferences)
  • DENYWEBCHANGE is the list of users and groups who may not edit topics in the current web (if set in WebPreferences)
The order in which TWiki evaluates these variables is documented in a section of TWiki.TWikiAccessControl. So if you want to disable editing for a known list of users (and can not simply register new users) then DENYTOPICCHANGE and DENYWEBCHANGE are the settings you are looking for.

-- HaraldJoerg - 09 Dec 2007

Thanks for the reply. Overwritting of the access control settings is a little unclear. Lets say that we have a group call UnknownUsersGroup then if the following is set in TWiki:TWiki.Preferences

   * Set DENYTOPICCHANGE = UnknownUsersGroup

Then is it try that this setting holds true for all webs, sub-webs and their topics? And that any attempt to do an

   * Set ALLOWTOPICCHANGE = UnknownUsersGroup

will be ignored?

-- PeterJones - 09 Dec 2007

Sidenote: Thanks to PeterThoeny for unlocking this topic! This is a real trap when writing about access control: Access control is evaluated even if it is within verbatim, or HTML comments, for the current topic. The only way to do it safely can be seen when I repeat the second block, wrapped within verbatim tags:

   * Set <nop>ALLOWTOPICCHANGE = UnknownUsersGroup

With pre instead of verbatim (as in the text above) the access control setting looks as if it were active, but it isn't due to the extra <nop>.

But back to your original question: Defining an access control setting only has effect on the current topic for ALLOWTOPIC*, and on the current web for ALLOWWEB* in WebPreferences. There is no possibility to have ALLOWTOPICCHANGE in TWiki.TWikiPreferences affect any topic - other than TWiki.TWikipreferences itself.

If you want to lock out UnknownUsersGroup from all topics, the process is a bit tedious, and not really bulletproof. You'd have to define

   * Set DENYWEBCHANGE = UnknownUserGroup
in all webs' WebPreferences. And, for safety in _default.WebPreferences as well, so that it will be automatically activated for webs you create. But unfortunately this can be overwritten by an explicit setting in a topic, for that topic only:
   * Set ALLOWTOPICCHANGE = UnknownUserGroup

I normally recommend to use the DENY settings only for the set of unregistered users (all TWikiGuest), and use explicit ALLOW settings for all other cases. Having an AuthorsGroup and collecting all users with exception of members of UnknownUsersGroup would be the closest thing to meet your requirements, but it suffers from the need to replicate across webs as well.

-- HaraldJoerg - 11 Dec 2007

Thanks for your answer. I have tested your solution and I can see that it works ands it true that it is a little tedious.

Thanks also to Peter for unblocking my settings.

I think that it would be a good idea to have a mechanism that bocks certain users; places them in a blacklist or holding area such that they remain registered but are unable to edit any topics until TwikiAdmin decides that the user is not a spamer.

I like the TWiki culture but in some cases and for some users protective action must be applied.

What do you think?

-- PeterJones - 12 Dec 2007

Fending off spammers is necessary in all TWikis which are open to the internet. It is often done by an approach in the opposite direction of yours. The idea of collecting (few) potential spammers in a special group fails as long as they can just register new users, so a better solution is to have a positive list of users who can edit. This works as follows:

  1. With the same (tedious) process as above, set ALLOWWEBCHANGE to a group AuthorsGroup (choose any name you like) for every web.
  2. Now, users can register and view all topics, but not edit nor attach, they are effectively in your "holding area". They remain there until someone declares them members of the AuthorsGroup.
  3. If you set ALLOWTOPICCHANGE = AuthorsGroup in AuthorsGroup itself, then any approved member of the group may approve new registrants for editing, or remove spammers from the list. This can accelerate the process. Or you might define a subset of registered users as allowed to approve.
  4. Finally, you can use WebNotify for the Main web to inform all members of your approval group (and not only the wiki webmaster) about any changes. So, the approval process can be triggered fairly quickly.
The only use case in which I would not recommend this procedure is if you have many thousands of users so that access control becomes a serious performance bottleneck.

-- HaraldJoerg - 14 Dec 2007

Good advise by Harald. In addition I recommend to install the BlackListPlugin on a public TWiki.

-- PeterThoeny - 16 Dec 2007

Change status to:
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2007-12-16 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.