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

How to reproduce:

  • create a TestUser
  • create a TestTopic
  • set DENYTOPICVIEW on TestTopic to TestUser
  • login as TestUser
  • visit TestTopic

Blush.


Confirmed. And I see this in my error log:

Subroutine TWiki::Configure::Checker::tmpnam redefined at /usr/share/perl/5.8/Exporter.pm line 65.
at /usr/lib/perl/5.8/POSIX.pm line 19
OopsException(accessdenied/topic_access web=>Sandbox topic=>DenyTest keep=>1
params=>[VIEW,access denied on topic])[Tue Nov 28 11:48:57 2006] [error] [client 194.109.230.189] 
Premature end of script
headers: /home/twikiadmin/twiki4.visiblearea.com/twiki4/MAIN/bin/view

AC

Here's a preliminary patch:

--- UI.pm       (revision 12079)
+++ UI.pm       (working copy)
@@ -51,7 +51,7 @@
 sub run {
     my ( $method, %initialContext ) = @_;

-    my ( $query, $pathInfo, $user, $url, $topic );
+    my ( $query, $user, $url, $topic );

     # Use unbuffered IO
     $| = 1;
@@ -70,7 +70,7 @@
     # close STDERR after each request so that we need to reopen it here again

     # open(STDERR, ">>/dev/null");      # throw away cgi script errors, or
-    # open(STDERR, ">>$TWiki::cfg{DataDir}/error.log"); # redirect errors to a log file
+    open(STDERR, ">>$TWiki::cfg{DataDir}/error.log"); # redirect errors to a log file


     if( DEBUG || $TWiki::cfg{WarningsAreErrors} ) {
@@ -146,14 +146,19 @@
         unless( $session->{loginManager}->forceAuthentication() ) {
             # Client did not want to authenticate, perhaps because
             # we are already authenticated.
-            throw TWiki::OopsException('accessdenied',
-                                       def => 'topic_access',
-                                       web => $e->{web},
-                                       topic => $e->{topic},
-                                       keep => 1,
-                                       params => [ $e->{mode},
-                                                   $e->{reason} ]);
-            # Exception will be caught in next catch
+            try {
+              throw TWiki::OopsException('accessdenied',
+                                         def => 'topic_access',
+                                         web => $e->{web},
+                                         topic => $e->{topic},
+                                         keep => 1,
+                                         params => [ $e->{mode},
+                                                     $e->{reason} ]);
+            } catch TWiki::OopsException with {
+              my $e = shift;
+              my $url = $session->getOopsUrl( $e );
+              $session->redirect( $url, $e->{keep} );
+            }
         }

     } catch TWiki::OopsException with {

Note the previous comment in the sources:

# Exception will be caught in next catch
Adding poor-man's debugging (print STDERR "here..." in some places) shows that the second exception is NOT catched in the next catch {} block. I don't know why. The patch above creates a new try - catch block inside for the sole purpose to redirect to oops properly. There's most probably a more elegant way to do that...recasting the TWiki::AccessControlException into a normal TWiki::OopsException to accessdenied.

MD


Throwing from a catch block propagates the error to the next level, it doesn't just fall through into the next block. That bug was introduced when trying to fix Item3067 in r11901.

Instead of introducing an extra try/catch one can IMHO simply revert to the pre-11901 style of explicitly building the redirect URL in the same way that TWiki::OopsException does - only pass a true value as second operand to the redirect so that query parameters will be kept.

Ugly that AccessControlTests.pm can't catch this type of errors. I hope there's a test case for Item3067 (which I didn't find) so that my fix can be verified - a simple manual test demonstrates that URL parameters are kept, but I don't know whether there are more gotchas.

haj

ItemTemplate
Summary 500 internal server error when accessing a view restricted topic
ReportedBy TWiki:Main.MichaelDaum
Codebase

SVN Range TWiki-4.1, Tue, 28 Nov 2006, build 12081
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins 12084
TargetRelease n/a
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2006-12-30 - KennethLavrsen
 
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