Last modified: 2007-05-03 12:52:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8825 - Search should not show pages the user can't read
Search should not show pages the user can't read
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Search (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-29 18:37 UTC by Fernando Correia
Modified: 2007-05-03 12:52 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
only shows in search results pages the user can read (489 bytes, patch)
2007-01-29 18:38 UTC, Fernando Correia
Details

Description Fernando Correia 2007-01-29 18:37:51 UTC
Special:Search shows titles and portions of text of pages that the user should
not be able to read.

The proposed patch performs standard MediaWiki access permission checks to only
show in the search results the pages that the user can access.
Comment 1 Fernando Correia 2007-01-29 18:38:37 UTC
Created attachment 3157 [details]
only shows in search results pages the user can read

Index: SpecialSearch.php
===================================================================
--- SpecialSearch.php	(revision 19680)
+++ SpecialSearch.php	(working copy)
@@ -288,7 +288,9 @@
		$out = "<ol start='{$off}'>\n";
 
		while( $result = $matches->next() ) {
-			$out .= $this->showHit( $result, $terms );
+			if ( ( $result->getTitle() != NULL ) && (
$result->getTitle()->userCanRead() ) ) {
+				$out .= $this->showHit( $result, $terms );
+			}
		}
		$out .= "</ol>\n";
Comment 2 Brion Vibber 2007-02-02 18:56:13 UTC
MediaWiki is open-access by design.
Comment 3 Fernando Correia 2007-02-15 10:25:36 UTC
I ask that you consider applying to this bug the same experimentation that was
applied to bug 8824. That is, trying to help extension writers plug the larger
read access holes.

MediaWiki is a great tool and can be valuable for information sharing on
work-related environments. But these require at least basic access control.
Extensions can try and provide it, but they can be simpler and more reliable
with some core support in the same line of basic read and edit access control
that already is part of the core.
Comment 4 Daniel Kinzler 2007-05-03 12:52:19 UTC
Fixed in r21821, but not using the suggested patch. Hiding "forbidden" pages
alltogether from search results screws badly with paging: you could get a
response saying "shoing 10 from 18 results", but actually showing none on the
first and two on the second page (because all the rest was "forbidden"). That
would be very confusing. But it can't be fixed without seriously messing with
the code of each search engine implementation.

As of r21821, "forbidden" pages are still listed with their title, but no
excerpt is show to users who don't have permission to see it.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links