Mediawiki im Intranet: Nur angemeldete Benutzer zulassen

Geschlossenes Mediawiki

restricted Ein Mediawiki im Intranet muss unter Umständen abgeriegelt und ausschliesslich einer geschlossenen Benutzergruppe zugänglich gemacht werden. Wenn man wissen will, welcher Benutzer welche Wikiseite bearbeitet hat, reichen leider die schönen Basic-Authentication Features von Apache nicht aus. Damit Mediawiki alle zur Anmeldung zwingt muss die Datei LocalSettings.php folgendermassen ergänzt werden:
############## Handmade ################
# Specify who can edit: true means only logged in users may edit pages
$wgGroupPermissions['*'    ]['createaccount']   = false;
$wgGroupPermissions['*'    ]['edit']            = false;
$wgGroupPermissions['*'    ]['read']            = false;
$wgGroupPermissions['sysop']['createaccount']   = true;
$wgGroupPermissions['user' ]['edit']            = true;
$wgGroupPermissions['user' ]['read']            = true;

# Logo
$wgLogo                         = "/images/bbbq.gif";

# Pages anonymous (not-logged-in) users may see
$wgWhitelistRead = array ("Spezial:Userlogin", "Wikipedia:Help");

Benutzer

Am Einfachsten ist sicher das Kopieren eines bestehenden Users (eventuell in MySQL). Dabei müssen user_id unduser_name eindeutig sein. Normalerweise braucht es keine weiteren Rechtemanipulationen. Sollen die Benutzer trotzdem gewissen Gruppen zugeteilt werden, gibt die Mediawiki-Dokumentation Auskunft über die Rechte und die Zuteilung zu Gruppen.

Passworte

In Mediawiki 1.10 ist die Passwortverschlüsselung in der Funktion includes/GlobalFunctions.php definiert:

function wfEncryptPassword( $userid, $password ) {
        global $wgPasswordSalt;
        $p = md5( $password);

        if($wgPasswordSalt)
                return md5( "{$userid}-{$p}" );
        else
                return $p;
}

$wgPasswordSalt kann in LocalSettings.php umdefiniert werden, aber normalerweise ist es in includes/DefaultSettings.php auf true gesetzt. $userid ist die user_id aus der Tabelle user.

Das Passwort kann mit php ausgegeben werden (angenommen für user mit id 15):

<?php echo md5('15-'.md5('PASSWORT'))."\n"; ?>

Oder direkt in Mysql:

UPDATE bi_user SET user_password=md5(concat(user_id,'-',md5('PASSWORT'))) WHERE user_id=15;

Excel und Powerpoint mit htdig indizieren

Möchte man xls und ppt in den Index der Intranet Suchengine htdig aufnehmen, muss man etwas Magie wirken lassen:

  1. Es braucht ein Umwandler „gewünscht2txt“. Ich habe xls2csv für Excel und catppt für Powerpoint gewählt.
  2. Die Mimetypes sollten aktualisiert werden. /etc/htdig/mime.types:
    [...]
    application/vnd.ms-excel        xls
    application/vnd.ms-powerpoint   ppt
    [...]
  3. Externe Parser müssen aktiviert werden in /etc/htdig/htdig.conf:
    [...]
    external_parsers: application/msword /usr/share/htdig/parse_doc.pl \
    application/postscript /usr/share/htdig/parse_doc.pl \
    application/pdf /usr/share/htdig/parse_doc.pl \
    application/vnd.ms-powerpoint /usr/share/htdig/parse_doc.pl \
    application/vnd.ms-excel /usr/share/htdig/parse_doc.pl
    [...]
  4. Nun muss noch /usr/share/htdig/parse_doc.pl angepasst werden:
    [...]
    #
    # Excel
    #
    $XLS2CSV = "/usr/bin/xls2csv";#
    # Powerpoint
    #
    $CATPPT = "/usr/bin/catppt";
    [...]
    } elsif ( $ARGV[1] =~  /excel/) {       # it's MS Excel - this detection is a kludge
        $parser = $XLS2CSV;
        # convert all possible sheets to ascii
        $parsecmd = "$parser "$ARGV[0]" |";
        $type = "MS-Excel";
        $dehyphenate = 0;               # Excel documents not likely hyphenated
    } elsif ( $ARGV[1] =~  /powerpoint/) {
        $parser = $CATPPT;
        # convert all possible sheets to ascii
        $parsecmd = "$parser "$ARGV[0]" |";
        $type = "MS-Powerpoint";
        $dehyphenate = 0;
    }
    [...]
  5. Nun sollts funzen.

Man könnte es wohl auch über html machen (mit dem Helfer xlhtml). Dazu müsste die Zeile in htdig.conf heissen:

application/vnd.ms-excel->text/html /usr/share/htdig/parse_doc.pl

und dann müsste inparse_doc.pl xlhtml mit den korrekten Parametern aufgerufen werden.

Generell können folgende Probleme auftreten:

Apache Index:
Indiziert man Verzeichnisse, die das Apache Index Modul erzeugt (Dateibaum ohne index.html), so können Seiten mehrfach gespeichert sein weil sich die Parameter unterscheiden. Um dies zu verhindern muss htdig.conf ergänzt werden:

bad_querystr: ?C=D ?C=S ?C=M ?C=N ?O=A ?D=A ?D=D ?M=A ?M=D ?N=A ?N=D ?S=A ?S=D C=D C=S C=M C=N O=A D=A D=D M=A M=D N=A N=D S=A S=D

Ghostscript-Hanger:
Mein Indexer hatte die Tendenz beim Aufruf von gs zu hangen. Nundenn, ein Umstellen von „pstotext“ auf „pdftotext“ hat das ganze subjektiv schneller gemacht und bis jetzt ist es nimmer gestalled. In /usr/share/htdig/parse_doc.pl:

[...]
#
# set this to your PDF to text converter
#
#$CATPDF = "/usr/bin/pstotext";                         # From "pstotext"
$CATPDF = "/usr/bin/pdftotext";                         # From "pdftotext"
if (! -x $CATPDF) { $CATPDF = "/usr/bin/pdftotext"; }   # From "xpdf"/"xpdf-i"
if (! -x $CATPDF) { $CATPDF = "/usr/bin/ps2ascii"; }    # From a ghostscript
if (! -x $CATPDF) { $CATPDF = "/bin/true"; }
[...]