Re: [TWiki-Dev] [SVN] KennethLavrsen r17203 - in twiki/branches/TWikiRelease04x02: data/TWiki lib/TWiki/Prefs

[Crawford C. <cc...@c-...>]

de...@de... wrote:
> Author: KennethLavrsen
> Date: 2008-07-29 19:01:39 -0500 (Tue, 29 Jul 2008)
> New Revision: 17203
> Trac url: http://develop.twiki.org/trac/changeset/17203
>
> Modified:
>    twiki/branches/TWikiRelease04x02/data/TWiki/TWikiVariables.txt
>    twiki/branches/TWikiRelease04x02/lib/TWiki/Prefs/PrefsCache.pm
> Log:
> Item3824: Possible to hijack TOPIC variable
> Not the major code refactor fix proposed in the bug item
> but then again noone did anything since April 2007
> This simple fix cures the problem so there is one less thing
> for an admin to worry about
>
>  
>      return 0 if $this->{CONTEXT}->isFinalised( $key );
> +    
> +    # Item3824 - we do not allow TOPIC and WEB to be altered by settings
> +    return 0 if ( $key eq 'TOPIC' or $key eq 'WEB' );
>   
That's horrendous. It would be far less messy to simply finalise TOPIC 
and WEB, so that

$this->{CONTEXT}->isFinalised( 'TOPIC' )

always returns true. Should be a simple case of adding TOPIC and WEB to 
the default hash, and would establish a clean pattern for any other 
similar pseudo-constants.

However it's not clear to me why overriding TOPIC and WEB should be a 
special case in the first place. TWiki is highly flexible, and any 
built-in can be overridden - that's a key feature. How is overriding 
TOPIC or WEB any worse than overriding anything else? (for example, IF 
or SEARCH)

C.

-- 
Crawford Currie
- C-Dot Consultants http://c-dot.co.uk
- A WikiRing Partner http://wikiring.com
- landline: +44-1606-330-242
- mobile: +44-7837-877-956
- public key http://keyserver.veridis.com:11371/search?q=Crawford+Currie