Bug: TWiki::Access::checkAccessPermission function improperly handles Main and TWiki webs

This function contains the following code:

    my $webPrefix = "";
    if( $theWebName ne $TWiki::webName && $theWebName ne $TWiki::twikiWebname && 
        $theWebName ne $TWiki::mainWebname) {
        # Different Web to current one, but we assume read access to twiki and main webs to
        # save frequent loading of these preferences
        $webPrefix = "Web$theWebName.";
        # A rather crude way of deciding if these preferences have already been loaded
        &TWiki::Prefs::getPrefsFromTopic( $theWebName, $TWiki::webPrefsTopicname, $webPrefix ) unless
            &TWiki::Prefs::getPreferencesValue( "$webPrefix"  . "WEBBGCOLOR" );
    }

The intent of the long condition at the beginning is to optimize away loading of preferences for Main and TWiki webs; the supposed side effect is making these webs always accessible. However, the real side effect is that Main and TWiki webs become accessible under the same restrictions as the default/current web.

See also AccessControlMainTopic.

Test case

The visible effect of this mis-behaviour could the following: when viewing an unprotected topic in a view-restricted web, if some topic from Main or TWiki web is included or otherwise accessed (for example, read by a plug-in that doesn't use internal flag), its contents gets replaced with "No permission to read topic ...", and/or AuthenticatedMode is activated.

• However, at present this exact behaviour can't be achieved due to ViewScriptPartiallyIgnoresTopicPermissions bug (it's impossible to view an unprotected topic in a view-restricted web); you can try to use RdiffCgiScript to see something close to the described effect.

Environment

Follow up

1. Main and TWiki webs are intended to be made always accessible.
2. The implementation of this feature is broken.
3. TWiki::Access::checkAccessPermission function uses the uncommon way of accessing specific (non-default) webs' preferences: it prepends their names with "Web$theWebName." prefix - just as plug-ins deal with their preferences. The rest of TWiki, as soon as I was able to check, retrieve preferences of non-default webs in a different way - specifically, by using the second parameter of TWiki::Prefs::getPreferencesValue function.

The first problem may be arguable - but personally I think that the TWikiSite administrator should have an option to restrict access to any webs without changing code (again, see AccessControlMainTopic).

The third problem doesn't hurt much, but it creates inconsistency in TWiki code. I don't know how this uncommon way of handling preferences impacts performance, because the current implementation of PrefsDotPm itself uses a poor approach to handling non-default webs' preferences. However, once OptimizePreferencesHandling is done, it will definitely worsen performance (though only slightly).

Fix record

The attached patch for AccessDotPm fixes all three mentioned problems. The patch was generated against Beijing release (AccessDotPm wasn't changed since then).

-- PavelGoran - 06 Jul 2003