• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

First the symptoms:

The TablePlugin fails to be loaded depending on the user being logged in or not.


Go to TestCaseItem345. It does not work here.


Watch for the column being sortable or not depending of you being logged in to ntwiki or not.

How to try it out at home (on your own dakar installation) with different means:

add the following line to TablePlugin.pm

TWiki::Func::checkAccessPermission('CHANGE', TWiki::Func::getWikiName(), $topic, $web);
just before the line
my $sort = TWiki::Func::getPreferencesValue( 'TABLEPLUGIN_SORT' );

Try out a TestTopic with the above mini-table using the TablePlugin with and without the code line given above and again: watch for the column being sortable or not.

After some digging the problem reveils of being a bigger one, possibly security related as topic variables are forgotten. The TablePlugin tries to decide whether it should be loaded or not depending on the SORT setting on TablePlugin or whether there's a %TABLE% tag in the current topic. So the bug does not manifest itself if there's a %TABLE% tag in the current topic.

As far as I've understood the code topic variables are cached in a hash using the topic name as a key not taking the web into account. This alone is critical. Imagine where MyWeb.SecretTopic is under my control and SecretWeb.SecretTopic has view restrictions. So in theory it should be possible to pollute the topic variable cache with the settings read from MyWeb.SecretTopic and not being reconsulted for SecretWeb.

Nevertheless, values of topic variables get lost when two unrelated topics are involved. Under certain circumstances that I still don't understand, but which are reproducable, the cache is not invalidated and recomputed for a different topic, appart from this being a suboptimal strategy anyway.

As this code stems form good ol' cairo, cairo is insecure too. Has this been reported somewhere?

Please, please, please proove that I am totally wrong.


You are totally wrong - now.

SVN 6292

Cairo is not insecure, IMHO. I'm pretty sure I introduced this problem.


Summary critical error parsing and caching topic variables
ReportedBy MichaelDaum

AppliesTo Engine
Priority Urgent
CurrentState Closed

Checkins 6292
Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2005-09-11 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback