archive_me1Add my vote for this tag create new tag
, view all tags

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.


TWiki version: TWikiRelease01Feb2003, TWikiAlphaRelease
TWiki plugins:  
Server OS:  
Web server:  
Perl version:  
Client OS:  
Web Browser:  

Follow up

I see three problems here:
  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

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff Access.pm.diff r1 manage 1.7 K 2003-07-06 - 17:52 PavelGoran Patch for AccessDotPm
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2004-08-20 - CrawfordCurrie
  • 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.