In Cairo and earlier, TWiki access controls were difficult to use, and the rules for web and topic access rather obscure. Specific problems were things like the inability to override certain web level access controls at the topic level, and very opaque handling of errors when they did happen so it was hard to work out what went wrong.

TWiki access controls have been analysed and re-worked in Dakar, to make them more secure, easier to use and less prone to hacking. Specific changes are:

1. Access controls are enforced at the store level
2. Access failures are reported via exceptions, making them almost impossible to ignore in code
3. The semantics of the various ALLOW/DENY settings have been analysed, reworked and documented.
4. Search has been forced to respect web and topic level access permissions

The following documentation extract defines the new rules for access control settings.

---

How TWiki evaluates ALLOW/DENY settings

When deciding whether to grant access, TWiki evaluates the following rules in order (read from the top of the list; if the logic arrives at PERMITTED or DENIED that applies immediately and no more rules are applied). You need to read the rules bearing in mind that VIEW, CHANGE and RENAME access may be granted/denied separately.

1. If the user is a super-user
   • access is PERMITTED.
2. If DENYTOPIC is set to a list of wikinames
   • people in the list will be DENIED.
3. If DENYTOPIC is set to empty ( i.e. Set DENYTOPIC = )
   • access is PERMITTED _i.e _ no-one is denied access to this topic
4. If ALLOWTOPIC is set
   1. people in the list are PERMITTED
   2. everyone else is DENIED
      • Note that this means that setting ALLOWTOPIC to empty denies access to everyone except admins (unless DENYTOPIC is also set to empty, as described above)
5. If DENYWEB is set to a list of wikiname
   • people in the list are DENIED access
6. If ALLOWWEB is set to a list of wikinames
   • people in the list will be PERMITTED
   • everyone else will be DENIED
     • Note that setting ALLOWWEB to empty denies access to everyone except admins
7. If you got this far, access is PERMITTED

---

There are almost certain to be cases in the code where exceptions are not correctly trapped and reported using oops pages. However all exceptions will be reported to the browser (i.e. it won't die mysteriously because of an access failure).

Oh, and note that topic-level access controls are now done on a per-revision basis, so if an older rev of a topic was impossible for you to read, it will always be impossible to read.

-- CrawfordCurrie - 24 Mar 2005

In step 3, I think the i.e. should read Set DENYTOPIC =

-- DavidBright - 24 Mar 2005

I have a web with

    *  Default template for new topics and form(s) for this web:
          o WebTopicEditTemplate?: Default template for new topics in this web. (Site-level is used if topic does not exist)
          o TWiki.WebTopicEditTemplate: Site-level default template
          o TWikiForms: How to enable form(s)
          o Set WEBFORMS = TaskTemplate

    * Users or groups who are not / are allowed to view / change / rename topics in the Tasks web: (See TWikiAccessControl)
          o Set DENYWEBVIEW =
          o Set ALLOWWEBVIEW = SvenDowideit
          o Set DENYWEBCHANGE =
          o Set ALLOWWEBCHANGE = SvenDowideit
          o Set DENYWEBRENAME =
          o Set ALLOWWEBRENAME = SvenDowideit

    * Users or groups allowed to change or rename this WebPreferences topic: (I.e. TWikiAdminGroup)
          o Set ALLOWTOPICCHANGE =
          o Set ALLOWTOPICRENAME = SvenDowideit

BUT with the last 2-3 days worth of DEVELOP, when logged in as SvenDowideit, I can view and create new topics, but I cannot edit existing topics, when I try, it tells me that I don't have view permissions

-- SvenDowideit - 25 Mar 2005

In answer to an observation by Michael "666" Sparks on TWikiIRC, access permission to each individual revision depends on the Set statements within that revision. Once private, always private - though a revision can always be accessed by admin.

Thanks David - fixed in SVN.

Sven's problem was diagnosed on IRC, and appears to have been a typo.

-- CrawfordCurrie - 25 Mar 2005

i've made the following changes to TWiki.WebPreferences in order to lock down the system TWiki06x01 web: (SVN r4159)

• ALLOWWEBCHANGE, ALLOWWEBRENAME, and ALLOWTOPICCHANGE are set to TWikiAdminGroup

i've made the following changes to TWiki.TWikiPreferences: (SVN r4157)

• removed ALLOWTOPICCHANGE and ALLOWTOPICRENAME settings as they're redundant with settings in TWiki.WebPreferences

-- WillNorris - 28 Apr 2005

I'm still a bit confused. I'd like to set the web access settings to something like: view = all editweb = admins edittopic1 = group1 edittopic2 = group2 etc... Can I do this?

-- AdamCoven - 28 Mar 2006

If DENYTOPIC is set to NobodyGroup (a group with zero members), this accomplishes the same thing as if DENYTOPIC is set to empty : access is PERMITTED and no-one is denied access to this topic

• ( i.e. Set DENYTOPIC = NobodyGroup accomplishes the same thing as Set DENYTOPIC = )

Is there any argument for using one approach over the other ?

-- KeithHelfrich - 06 Jan 2008

I would always recommend the Set DENYTOPIC = NobodyGroup form. It is less easy to misinterpret.

-- CrawfordCurrie - 07 Jan 2008

Yep, that was my reasoning also. I just wanted to make certain that the specs weren't planning to change in a way that would undo this later. If it were up to me, I would include the empty NobodyGroup by default in the distribution. Thanks, Crawford !

-- KeithHelfrich - 07 Jan 2008

Curiously enough, there's a good reason not to do that; viz. if the group file does not exist, then there is no need to read it and parse it for group members. Having a nonexistant NobodyGroup lets you make a faster decision.

-- CrawfordCurrie - 08 Jan 2008

So if I have an existing NobodyGroup then I should delete it to speed up performance. Thanks!

-- KeithHelfrich - 09 Jan 2008