fernandoacorreia wrote:

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";

Attached:

MediaWiki is open-access by design.

fernandoacorreia wrote:

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.

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.