create new tag
, view all tags

Feature Proposals » Site configuration to restrict access to topics of a certain name in all webs


Current State: Developer: Reason: Date: Concerns By: Bug Tracking: Proposed For:
MergedToCore HideyoImazu AcceptedBy7DayFeedbackPeriod 2014-05-08   TWikibug:Item7530 KampalaRelease

Edit Form

DateOfCommitment:   Format: YYYY-MM-DD


AutomationAddOn#Access_control_implication requires this.

Description and Documentation

Basic design

You may want to restrict access to topics of a certain name in all webs. To this end, new configuration parameter {Access}{Topic} would be introduced.

The following setting would restrict viewing and editing of WebAutomation topic in all webs only to privileged users.

$TWiki::cfg{Access}{Topic}{WebAutomation} = {
    ALLOWCHANGE => 'nobody',

You may want to allow editing of WebPreferences of all webs only to privileged users. It would be achieved by:

$TWiki::cfg{Access}{Topic}{WebPreferences} = {
    ALLOWCHANGE => 'nobody',

{Access}{Topic} would be checked before DENYTOPIC* and ALLOWTOPIC* variables.

Denied reason

If access is denied based on {Access}{Topic}{TOPICNAME}, the access denied page would show either of the following reasons depending on the the user is in DENYXXXX or not in ALLOWXXXX.

  • access denied based on {Access}{Topic}{TOPICNAME} configuration
  • access not allowed based on {Access}{Topic}{TOPICNAME} configuration

This is analogous to the following reasons currently shown depending on situation.

  • access denied on topic
  • access not allowed on topic
  • access denied on web
  • access not allowed on web


You would be able to restrict editing of WebStatistics in all webs only to privileged users by:

$TWiki::cfg{Access}{Topic}{WebStatistics} = {
    ALLOWCHANGE => 'nobody',



-- Contributors: Hideyo Imazu - 2014-05-08


See see the need for this. What is the reason to do this as configure settings?

I am a bit concerned about complexity, the non-orthogonal syntax, and about users wondering why they can't change a topic (if not obvious where the access setting is hidden.)

Wondering if there is an alternate approach that extends the current spec with site level access settings in TWiki.TWikiPreferences / Main.TWikiPreferences?

-- Peter Thoeny - 2014-05-09

Having TWiki::Access::checkAccessPermission() refer to variables such as DENYVIEWWebAutomation and ALLOWVIEWWebAutomation might be cleaner. But if we take that route, when AutomationAddOn is installed, the site admin needs to put the following line to the %LOCALSITEPREFS% topic (Main.TWikiPreferences by default) manually.

   * Set ALLOWCHANGEWebAutomation = nobody

If we go for this proposal, the installation script would put the following lines to lib/LocalSite.cfg and the site admin doesn't have to do it manually.

$TWiki::cfg{Access}{Topic}{WebAutomation} = {
    ALLOWCHANGE => 'nobody',

(I changed configuration examples in the "Description and Documentation" section above)

-- Hideyo Imazu - 2014-05-10

All caps is more consistent. Basically we have a list of key value pairs. Several options to ponder:

  • Set ALLOWCHANGE = TopicOne: nobody, TopicTwo: TWikiAdminGroup
  • Set ALLOWSITECHANGE = TopicOne: nobody, TopicTwo: TWikiAdminGroup
  • Set ALLOWWEBCHANGE = TopicOne: nobody, TopicTwo: TWikiAdminGroup
  • Set ALLOWTOPICSCHANGE = TopicOne: nobody, TopicTwo: TWikiAdminGroup

Similar for DENY* and *VIEW settings.

Plural "*TOPICS*" is most consistent, but easy to confuse with singular. "*WEB*" is confusing because same name is used with different format.

As for topic specification, if only topic is specified it could mean for all webs, if Web.Topic it could mean for only one web.

Not sure if wildcards should be supported, such as Project*.ReportCard*. Feature creep?

-- Peter Thoeny - 2014-05-10

Permission syntax is: Allow/deny some action (view, change, etc). The permissions code already account for any action you throw at it.

Hence, in regards to automation setting, semantically it belongs at the end as you noted, but in capital AUTOMATION.

-- Peter Thoeny - 2014-05-10

What I intended with the following example is ALLOWCHANGE followed by a topic name.

  • Set ALLOWCHANGEWebAutomation = nobody
If we adopt your idea, how about using semicolon instead of comma to delimit sections? We may want to specify multiple items per topic.
  • Set ALLOWCHANGE = TopicOne: nobody; TopicTwo: TWikiAdminGroup, PeterThoeny
Topic wildcard would be handy, it has performance penalty. My gut feeling is the benefit is smaller than the effort.

It's really dangerous for WebAutomation to be editable by non-privileged users. So it's highly desirable to set its restriction simply by installing the add-on. What do you think about this aspect?

-- Hideyo Imazu - 2014-05-10

I think ALLOWCHANGEWebAutomation looks a bit odd and is not consistent with other access control settings.


I see the need on multiple groups or people per topic. I am OK with the semicolon approach. The other option is to stick with comma and have the limitation that only one group or user can be specified per topic.

-- Peter Thoeny - 2014-05-15

7 days past, so feature is accepted by feedback period, also accepted by release meeting at KampalaReleaseMeeting2014x05x15.

Feature is accepted as originally proposed with configure setting, e.g. without new preferences settings. Need to make sure that user hitting an access control restriction is informed where to look for setting.

-- Peter Thoeny - 2014-05-15

I realized that the access denied page now shows either of the following.

  • access denied on topic
  • access not allowed on topic
  • access denied on web
  • access not allowed on web
So I came up with an analogous way and described in the "Denied reason" subsection.

-- Hideyo Imazu - 2014-05-28


-- Peter Thoeny - 2014-05-28

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2014-07-04 - HideyoImazu
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.