Platonides wrote:
Jim Hu wrote:
> We discovered this when we had a split wiki with private and public
> parts. And then we ran a Nutch search engine against our own wiki
> and saw all these hits that weren't supposed to be there.
>
> The watermark idea sounds like it might be interesting. You wouldn't
> have to map the IPs...so what if the public users see the fact that
> it's a public wiki?
> Or, maybe you could just set up your private users to use a different
> skin that displays the warning.
No need to use a different skin (though doable), simply
use an external
item, like an image. E.g if you display '/image/editNS0.png',
private.domain.com/image/editNS0.png will be a horrible warning, while
public.domain.com/image/editNS0.png a smily face saying, "you're welcome
to edit".
OK, so here's what I eventually did (based on MediaWiki 1.8.2):
In Monobook's main.css under
span.subpages {
display: block;
}
I added the following:
#bodyContent textarea {
background-image: url(secure.png);
}
That way, the watermark only appears in TEXTAREA elements. For MediaWiki, this is the
article editing box. Normal viewing of the articles does not give any watermark. Editing
/ creating a new article does - perfect !! In fact, I couldn't find the right CSS
element to try and get it appearing for the regular article pages. The TEXTAREA only
solution is actually much nicer.
Next, the priority of Interwiki links versus Namespace links in articles. The Namespace
wins out, which makes sense. Thus even though my two wikis share a common interwiki MySQL
table, if the namespace exists (which is the case on the "Private" wiki) then it
correctly looks at that. For the Public wiki, the interwiki link points the user to the
Private wiki (which they can only access if Apache thinks their IP address is OK via
access/deny rules). Another win !
So, what about Special:RecentChanges and RSS/Atom feeds ?
A small hack to includes/SpecialRecentChanges.php, function function
wfSpecialRecentchanges( $par, $specialPage ) on the Public wiki fixed that, as follows:
Under the section
# Namespace filtering
$hidem .= is_null( $namespace ) ? '' : ' AND rc_namespace' . ($invert ?
'!=' : '=') . $namespace;
I added
$hidem .= ' AND rc_namespace < 100';
A crude but effective way to block my Private custom namespaces from appearing.
And also for Image: pages where the Links section of the page reveals what other pages
refer to the image.
In includes/ImagePage.php, function imageLinks(), I did the following:
Under
$sql = "SELECT page_namespace,page_title FROM $imagelinks,$page WHERE il_to="
.
$dbr->addQuotes( $this->mTitle->getDBkey() ) . " AND
il_from=page_id";
I added
$sql.= ' AND page_namespace < 100';
Again, crude but effective.
Perhaps a $wgMaxDisplayedNamespace variable in LocalSettings.php would be cleaner than
hard-coding the value 100
I checked the Search box functionality, and of course on the Public wiki, the namespaces
do not go up to 100 and 101 which are my Private: and Private_Talk: namespace, so a user
has no way of finding them or selecting to search those namespaces.
Perhaps someone wants to comment on this hack so far. I know I have still got to attack
includes/SpecialWhatlinkshere.php.
Maybe I overlooked some other Special: pages ?
It basically looks good so far.
The only "gotcha" I found was that if I create a Private: link using my Public
wiki (e.g. as a "crossover" page), then it doesn't appear in
Special:Whatlinkshere for that page. Rebuilding all the links periodically via the
maintenance/rebuildall.php script would fix that problem, but for the most part there
would be very few that we need to create.
Likewise, any administrative operations need to be performed on the Private: wiki which
can see the total set of all namespaces. I'm prepared to make that sacrifice since
there are probablty very few such pages that would need to be created.
Cheers
Jason
