• 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.



(Remove the <nop> ... never ending VERBATIM ERROR: why do I have top use <nop>???)

to login.tmpl

and visit a topic to which you've got no view access which generates a "500 Internal Server Error".

Maybe AccessControlExceptions should be consumed silently in some palces - as for FORMFIED tags - because they have been thrown before already. I.e. rendering an oops screen like an accessdenied should not generate another oops accessdenied on the same topic because a FORMFIELD tag is part of the page.

Here's a patch for renderFORMFIELD() that cures the symptoms for it so far:

--- lib/TWiki/Render.pm (revision 7086)
+++ lib/TWiki/Render.pm (working copy)
@@ -32,6 +32,7 @@

 use strict;
 use Assert;
+use Error qw( :try );

 # Use -any to force creation of functions for unrecognised tags, like del and ins,
 # on earlier releases of CGI.pm (pre 2.79)
@@ -903,9 +904,15 @@
     my $store = $this->{session}->{store};
     unless ( $meta ) {
         my $dummyText;
-        ( $meta, $dummyText ) =
-          $store->readTopic( $this->{session}->{user}, $formWeb, $formTopic, undef );
-        $this->{ffCache}{$formWeb.'.'.$formTopic} = $meta;
+       try {
+         ( $meta, $dummyText ) =
+           $store->readTopic( $this->{session}->{user}, $formWeb, $formTopic, undef );
+         $this->{ffCache}{$formWeb.'.'.$formTopic} = $meta;
+       } catch TWiki::AccessControlException with {
+         # consume AccessControlException silently as this was thrown before already
+         my $e = shift;
+         $meta = '';
+       }

This does not look right to me and most propably there's a better way to fix it.


FORMFIELD allow to show the formfield from another topic in any web, so if reading that topic throw an AccessControlException it will get consumed too.

Perhaps a better solution is to mark the twiki instance as "unstable" (or something like that) when an exception is thrown and use that to decide if another thrown exception should be ignored.


I didn't trap the exception because I thought it was fairly obvious that throwning an access control exception in an access control handler was not going to work. Catching the exception in the way Michael shows above is very wrong. Preventing recursive exception calls is better. For now, don't use constructions in login.tmpl that may throw access control exceptions! (This should be documented somewhere, probly in a comment at the top of login.tmpl)


Summary using FORMFIELD in login.tmpl crashes
ReportedBy MichaelDaum
AppliesTo Engine
Priority Urgent
CurrentState No Action Required

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