Related topics: DatabaseForPreferences PrefsDotPm AddValuesToPreferenceVariable MetadataSucks MetaDataSucksMeasurement StepByStepRenderingOrder DatabaseForAccessControl SimplifyInternalMetaDataHandling MetaDataDefinition DatabaseForMETA MegaTWiki

---

Evils of In-Band Acccess Control

Benefit of Out-of-Band Access Control

I've discussed this in other topics at length so I'll summarise here:

• Modularisation by seperation of access control representation from the topic (making it out of band data) and handling (by making it a DB and not "Set" statements.
• Orthogonality, since the access control code does that and only that and can be tested and replaced independantly of other settings.
• Performance. While the individual speed gain may not be noticable, the reduced processing will reduce the overall loading on the machine.

At the moment, the "Set" mechanism subsumes a lot of things, one of them being access control. Seperating access controol from other settings is one aspect of this modularization. It offers oppotunities for simplification of the code and structure, for ease of testing and for tuning. Access control is a distinct case of "settings". These seetings are very specific where as things like SKIN and WEBBGCOLOR are varied and general and can be 'invented' to suit specific applications. Access control is part of the underlying structure.

All the current access control variables can be migrated to a DBM hash, which would allow for some regular GUI-stuff and probably simplify a lot of other code as well. Empty settings need not be migrated. The absence of a key is a fast way to determine the absence of a setting.

How the current implementation builds the acess control information

In the current implementation checkAccessPermissions relies on InitaialzePrefs habing read in and laborously scanned the site, main, web and user prferences (just so it can expand things like TwikiAdminGroup and things like "Set ALLOWEBCHANGE = %WEBMAIN%.AntonAylward). It then does a split of the text and applies the search for allow or deny in a loop. There is no way this can be faster than lookup of a per-web DBM has with the topic name and the access as the key. For most pages there will be neither and the processing will be very little - the DB search will fail to find a key.

More to the point, the amount of processing will be independant of the size of the topic.
At the moment, the ammount of processing "grows" linearly with the size of the topic, both the topic that is being viewed and the relevant Web, TWiki and user preference topics.

Specifically, when TWiki::Store calls TWiki::Meta:read() (as "meta->read()") we have quite an extensive loop because the $text (the whole topic as a variable) is split(), the META lines pulled out into a hash, and the text rebuilt. You might also check to see how many times that gets called to process 'view' for one ordinary topic in one ordinary web, since all the possible topics that might specify access control or things like %RED% and so forth.

Yes, the code that ends up in the loop, prvAddToPrefsList, called from getPrefsFromTopic, gets all the prefs, but it also takes the $text apart and rebuilds it, greping for the " * Set something = value" in the loop.

Sources of Inefficiency

There are two point worthy of notice here.

1. getPrefsFromTopic gets all the settings, regardless of which ones are to be used. For example, the colours and the smileys and other icons are all read, even if the topic doesn't make use of any of them.
2. The current access control works by over-writing with the more specific settings.
   Site, Twiki and Web preferences are read then the topic itself.
   All of the settings in all of the preferences are rad, regardless of whether they apply to access control or not.

The latter is interesting because it it offers an opportunity for efficiency improvements. If a hash DB is used, search the opposite direction:

Access Control with a DB

Well, more than one actually. I suggest more than one for locality of control and to simplify locking problems.

1. The Berekely DB hashes as used as database.
   These are implemented and compatible with Perl and with has access (see the 'tie' operation).
2. The 'hash' mode of the DB is used so that empty elements can simply be rpresented by absent keys.
3. Each web contains a DB '...data/%WEB%/.web.db' that contains the access control information that was previously in %<nopWEB%.WebPreferences
   • The keys to this DB are - potentially
     • DENYVIEW
     • ALLOWVIEW
     • DENYCHANGE
     • ALLOWCHANGE
     • DENYRENAME
     • ALLOWRENAME
     • FINAL
   • An absent key means the corresponding value is empty
4. Each web contains a DB data/%WEB%/.topicacc.db that contains the access control information that was previously in the individual topics in the web.
   • The keys to this DB are - potentially
     • %TOPIC%,DENYVIEW
     • %TOPIC%,ALLOWVIEW
     • %TOPIC%,DENYCHANGE
     • %TOPIC%,ALLOWCHANGE
     • %TOPIC%,DENYRENAME
     • %TOPIC%,ALLOWRENAME
   • An absent key means the corresponding value is empty
   • Experience shows that the majority of topics have no access control.
5. The %MAINWEB% contains a DB file .group.db that has the group information
6. The %TWIKIWEB% contains a DB file .site.db that conatins the site level access control settings. These are similar to the web level.
7. I'm still thinking about the user level stuff

and of course

• After extraction, any regular variables are expanded, recursively if necesarily
  • Example: %MAINWEB%/.topicacc.db("WebPreferences,ALLOWCHANGE) -> "%MAINWEB%.TWikiAdminGroup"
    This is textually expanded and expanded as a group, then all the elments of the group are textually expanded and recursed.

• Search statements exist to allow values to be displayed in web pages.
  • Example:

          %ACCSEARCH{ scope="web" key="*" format="  * Set WEB$key = $value"}%

• • Example:

          "Barring other restrictions, these people are explicitly allowed to view this topic:<br><ul>
          %ACCSEARCH{ scope="topic" key="ALLOWVIEW" format="<li>$expandedvalue</li>"}%
          </ul> 

• • Example: This implements a drop-down list of the members of the group

          %ACCSEARCH{ "scope="group" key="TWikiAdminGroup" seprator=" " format="<option value=$value</option>" }%

Note: Perhaps we need to have %SEARCH%, %METASEARCH% and %ACCSEARCH% with the ability to nest within each other and have conditionals ;-/

Access Control with a DB - example using 'view'

The 'view', the most common operation, isn't interested in any CHANGE settings, so don't bother with them.

• Search ~twiki/data/%WEB%/.topicacc.db, keys %TOPIC%,ALLOWVIEW and %TOPIC%,DENYVIEW

If that specific (i.e. most binding) doens't tell us, we go to the next level of generality

• Search ~twiki/data/%WEB%/.web.db, keys VIEWALLOW and VIEWDENY

If the Web-level DB doesn't tell us, we go up the to the next, and the next, which I'll leave as an exercise for the reader

KISS

Keeping It Simple leads to a few attitudes.

The first is to avoid unwarented compelxity. As I see it, having to implement a relational database just to use Twiki is unwarrented. That isn't to say that the back end implemented by Store.pm could not be a RDBMS, but that it shouldn't have to be.

The present implementation uses simple text files in a good, long standing UNIX tradition.

An "object" interface can hide the details of the storage mechanism.

Right now, the toopic text, the access cotnrol and the meta data are tightly coupled because they are in the same file. Hence the processing is tightly coupled.

Any move to an alternative store - CVS, RDBMS - will require the functinality to be clearly seperated. Think of it as 'normaliization'.

Think of it object terms, if you will.

• A topic can have zero or more access control directives associated with it.
• A topic can have one and only one META:PARENT associated with it
• A topic can have one and only one META:AUTHOR associated with it
• A topic can have one or more META:FILEATTACHEMENT associated with it
• A topic cna have one or more META:FORM associated with it
• A topic must have one or more META:FIELD associated with each META:FORM

I'll see about diagraming that.

-- AntonAylward - 03 May 2003

I've mentioned the evils of in-band access control. Well, TWikiAccessControl has been altered so as to be unreadable, which is an example of what I mean.

Mind you, I suspect that a setting what allows or restricts people from altering the access control on a topic or web is also needed

-- AntonAylward - 13 May 2003

---

See MetaDataSucksMeasurement for measurement and profile that reflects on Settings and Access Control

---