Question (submitted as a BugReport)
My site uses partial authentication. I have created a Restricted web with all ALLOW* preferences set to a RestrictedGroup (UserOne, UserTwo). For the topic Restricted.UserOnePrivate, I set ALLOW* = MyUserName. When I login as UserTwo, if I don't specify a revision or if I specifically try to view the current revision, then I am restricted from viewing the topic Restricted.UserOnePrivate.
However, if I specify a previous revision, I can view the topic Restricted.UserOnePrivate as UserTwo! All revisions of Restricted.UserOnePrivate have ALLOW* set to UserOne only. The Index and Search pages seem hide the contents of Restricted.UserOnePrivate appropriately when I'm logged in as UserTwo. Just view/viewauth with previous revisions seems to be the problem.
I didn't find anything on this when I searched the Support Web. Is this a known bug? If so, is there a fix?
If not, which code do I start looking at so that I can restrict all permissions for all revisions of a topic?
--
RobKirk - 30 Dec 2004
Environment
--
RobKirk - 30 Dec 2004
Answer
This smells like a bug and should be filed as a
BugReport
--
PeterThoeny - 31 Dec 2004
Okay, it's filed as a
BugReport, but as I was updating it, I accidentally set the
TopicClassification to
AdminTopic and now I can't access the topic. Would you or another
CoreGroup member
please set the TopicClassification back to BugReport.
--
RobKirk - 31 Dec 2004
It's not the topic classification which has locked the topic up, it's the test case description where you entered
* Set ALLOWTOPICCHANGE = <nop>UserOne
* Set ALLOWTOPICRENAME = <nop>UserOne
* Set ALLOWTOPICVIEW = <nop>UserOne
without using
verbatim
tags. To fix it you need to create and login as the fictitious UserOne. Or wait until someone with override access can edit the topic (I can't. I can see what you've done, but not edit).
--
MattWilkie - 31 Dec 2004
OK, I changed the
verbatim
into a
pre
with escapes, this is to work around the
VerbatimMissesSetStatement issue.
--
PeterThoeny - 31 Dec 2004
Thank you both. So do we leave this here or remove this topic? Anybody smell a TWikiNuB?
--
RobKirk - 31 Dec 2004
uhm, I don't know, what is a
TWikiNuB ?
I'd probably leave it here as an
AnsweredQuestion to grab this-web-only searches for like issues.
--
MattWilkie - 31 Dec 2004
Found the same problem when i tried to lock the view on some topics (whole TWiki is authenticated per SSL+LDAP).
I changed the access check to be the first thing the script does, surely not the best solution but it works
quick'n dirty:
--- View.pm 2004-10-19 22:03:39.000000000 +0200
+++ ViewNew.pm 2005-01-17 13:07:44.000000000 +0100
@@ -64,6 +64,17 @@
my $revdate = "";
my $revuser = "";
+ # --- access check
+ my $viewAccessOK = 0;
+ $viewAccessOK = &TWiki::Access::checkAccessPermission( "view", $wikiUserName, $text, $topic, $webName );
+
+ if( !$viewAccessOK ) {
+ TWiki::UI::oops( $webName, $topic, "accessview" );
+ return;
+ }
+ else {
+ # ---
+
$skin = &TWiki::Prefs::getPreferencesValue( "SKIN" ) unless ( $skin );
# Set page generation mode to RSS if using an RSS skin
@@ -313,6 +324,7 @@
print $tmpl;
TWiki::UI::writeDebugTimes( "view - done" );
+ } # -- access check
}
1;
Maybe someone has a better suggestion?
--
ThomasBurgstaller - 17 Jan 2005
Couldnt make the fix above work, so I compared UI/View.pm and UI/RDiff.pm, which led to the following adjustment, that works for our installation:
--- View.pm 27 Jan 2005 07:16:10 -0000 1.1
+++ View.pm 27 Jan 2005 07:18:52 -0000
@@ -245,7 +243,7 @@
$tmpl =~ s/( ?) *<\/?(nop|noautolink)\/?>\n?/$1/gois; # remove <nop> tags (PTh 06 Nov 2000)
# check access permission
- my $viewAccessOK = &TWiki::Access::checkAccessPermission( "view", $wikiUserName, $text, $topic, $webName );
+ my $viewAccessOK = &TWiki::Access::checkAccessPermission( "view", $wikiUserName, "", $topic, $webName );
if( (!$topicExists) || $TWiki::readTopicPermissionFailed ) {
# Can't read requested topic and/or included (or other accessed topics
# user could not be authenticated, may be not logged in yet?
--
BoHedemarkPedersen - 27 Jan 2005
The quickest and the dirtiest fix: clear the
theTopicText
parameter right at the beginning of the
checkAccessPermission
sub:
$theTopicText = "";
-- Main.CostaShapiro - 06 Apr 2005