PHP

As part of the work for the openSUSE wiki upgrade and move, I had to package a bunch of MediaWiki extensions. We'll use the MediaWiki 1.27.x LTS release, which means the extensions need to work with this version.

When it comes to packaging, there are three categories of extensions:

The Good

These extensions are hosted on phabricator.wikimedia.org, and you can easily download a tarball matching your MediaWiki version using the "Download snapshot" link on the extension page.

Packaging these extensions is easy - just unpack the tarball and copy/package everything to the extension directory.

These extensions are standardized enough to use a spec file template - usually I only had to adjust the extension name, tarball name and version. Speaking of the version - most extensions don't have explicit version numbers, so I decided to use the tarball date instead.

An example for this category is Auth_remoteuser (extension page, package) which we use to keep the "nice" wiki login form.

The Bad

These extensions are hosted on GitHub and typically only have a "master" branch. They usually still work with MediaWiki 1.27.x, but there's a small risk that they require features added in newer MediaWiki versions, and this risk will grow over time.

On the packaging side, they are as easy as the "good" extensions.

An example is the ParamProcessor extension (extension page, package) which is needed by the Maps extension

The Ugly

These extensions can be hosted on phabricator.mediawiki.org or GitHub, so there are "god ugly" and "bad ugly" extensions ;-) The thing that makes packaging really ugly is that they don't include all the code they need. Instead, you have to download the missing parts with composer.

composer works fine in a "real" system, but makes packaging hard. Running it from the spec will obviously fail because OBS doesn't allow network connections while building a package (and even if it's annoying in this case, not having network access during build is a good thing[tm]).

My solution is a little script that unpacks the extension tarball and runs "composer install --no-dev" inside the extension directory. The most important part is the "--no-dev" parameter because that avoids lots of superfluous things. Afterwards, I build a tarball from the "vendor" directory and add it to the package.

Yeah, I know that's not nice - guess why I named this section "The Ugly" ;-)

One of the packages that need a "composer install" run is the GitHub extension (extension page, package including script to run composer).

Luckily, "ugly" only applies to packaging. The extensions and their maintainers are for sure not ugly - for example, the maintainer of the GitHub extension was very fast in fixing a bug :-)

I just released the long awaited PostfixAdmin 3.0.

Right. there isn't a beta label anymore :-) It's more than two years since we released the first beta for 3.0 (and even more years of working towards 3.0 - I started working on the PFAHandler class in 2011) so I think we can safely drop the beta label.

PostfixAdmin 3.0 is now officially the stable version of PostfixAdmin. I'll keep the 2.3 branch maintained for a while if someone finds critical or security bugs, but nevertheless it's probably a good idea to upgrade to 3.0 whenever you have some time.

See the official announcement for details and the changelog, and my PostfixAdmin 3.0 slides (which still wear the beta label) for a quick overview of PostfixAdmin and what's new in 3.0.

BTW: I already submitted PostfixAdmin 3.0 to openSUSE Tumbleweed and Leap 42.2. It will arrive there as soon as the submit requests get accepted.

Die Mediawiki-Extension MultiBoilerplate ermöglicht es, beim Anlegen einer Seite eine oder mehrere Vorlagen zur Auswahl anzubieten. Das ist schonmal gut. Noch besser ist es allerdings, wenn die Vorlagen-Liste je nach Namespace eingestellt werden kann - eine Vorlage für eine neue Seite ist z. B. nicht als Vorlage für eine Hilfeseite geeignet.

Die Lösung ist ein kleiner Patch, den ich für MultiBoilerplate geschrieben habe. Dieser ist im Mediawiki Bugtracker verfügbar (und wird hoffentlich in der nächsten MultiBoilerplate-Version aufgenommen ;-) Der Patch enthält auch eine Beschreibung der nötigen Config-Optionen.

The Mediawiki-Extension MultiBoilerplate allows to offer one or more boilerplates when creating a new page. That's quite good. It's even better to offer different boilerplates for each namespace - for example, a boilerplate for a new page is not necessarily a good boilerplate for a help page.

The solution is a small patch I wrote for MultiBoilerplate. You can download it from the Mediawiki Bugtracker (and will hopefully be included in the next version of MultiBoilerplate ;-) The patch includes a description of the necessary config options.

Prosit Neujahr und alles Gute für 2010! Dieser Artikel enthält einiges, das ich schon 2009 bloggen wollte, und außerdem eine kleine Neujahrsüberraschung von SpamAssassin ;-)

Happy New Year! This article contains some things I wanted to blog about in 2009 already, and a little new year surprise from SpamAssassin ;-)

• PostfixAdmin 2.3 wurde im Oktober 2009 releast, RPMs gibt es natürlich im openSUSE Build Service
  PostfixAdmin 2.3 was released in october 2009, RPMs are available in the openSUSE Build Service


• Postfixadmin 2.4 (oder 3.0?) wird Smarty für die Templates verwenden
  PostfixAdmin 2.4 (or 3.0?) will use smarty for the templates


• PostfixAdmin 2.3.1 (alle Bugfixes seit dem 2.3-Release, aber ohne Smarty) ist in Arbeit
  PostfixAdmin 2.3.1 (with all bugfixes since 2.3 release, but without smarty) is under development


• openSUSE 11.2 wurde im November 2009 releast, und auch gleich von uns (Jan, Jan-Simon und mir) auf der Open Source Expo in Karlsruhe präsentiert
  openSUSE 11.2 was released in november 2009, and presented by us (Jan, Jan-Simon and me) at the Open Source Expo in Karlsruhe


• und die Neujahrsüberraschung von SpamAssassin: 2010 bekommt jede Mail erstmal 3.188 Punkte... - Bugreport
  and the new year surprise from SpamAssassin: every mail in 2010 gets 3.188 points... - Bugreport
  

Auf der Typo3-Website eines Kunden verwende ich th_mailformplus für ein Webformular mit Dateiupload. Funktioniert auch soweit, allerdings wurde die hochgeladene Datei (trotz entsprechender Konfiguration des Formulars) nicht an die Maill angehängt.

Seit vorhin kenne ich den Grund: Der Mail-Funktion wird nur der Dateiname ohne Pfad angegeben, und dadurch findet die Funktion natürlich die Datei nicht und kann sie auch nicht anhängen :-(  Außerdem endet der Dateiname noch mit \n.

Ich habe eben einen kleinen Patch in den Typo3-Bugtracker hochgeladen, der den Pfad beim Dateinamen einfügt und das \n per trim() entsorgt. Und schon werden Mails mit Anhang verschickt :-)

I use th_mailformplus for a mailform with file upload on a customer's typo3 website. Works mostly, but the uploaded file was not attached to the mail (even if the mailform config was correct).

Since a short while ago I know the reason: The mail function is called with the filename without path, and therefore obviously can't find the file :-(  Besides that, the filename ends with \n.

I just uploaded a small patch to the Typo3 bugtracker which inserts the path into the filename and removes the \n using trim(). Now mailformplus sends mails with attachments :-)

Schöner Titel zum Mitraten, oder? ;-)

Paste Search ist ein unspektakuläres PHP-Script, das aber die Usability von Konqueror (und anderen Webbrowsen) enorm verbessert. Konkret geht es um das Verhalten beim "Mittelklicken" des Browserfensters, das normalerweise eine Google-Suche auslöst und nach dem Begriff in der Zwischenablage sucht. Dieses Standardverhalten ist schonmal gut, aber oft habe ich andere Ziele - beispielsweise ein Bugreport auf bugzilla.novell.com oder im SourceForge Tracker.

Die Lösung ist relativ einfach: Das folgende PHP-Script wird auf einen Webserver hochgeladen und als Standard-Suchmaschine im Browser eingetragen. Ab diesem Zeitpunkt wird bei Zahlen automatisch im Bugtracker gesucht (die Unterscheidung erfolgt anhand der Nummer - alles bis 500000 geht an bugzilla.novell.com, der Rest an SourceForge), bei Text mit Google.

Nice title to guess on, right? ;-)

Paste Search is an unspectacular PHP script that greatly enhances the usability of Konqueror (and other web browsers). To be exact, it is about the behaviour when "middle-clicking" the browser window which usually starts a google search for the content of the clipboard. This default behaviour is not bad, but sometimes I have other targets - for example bugreports on bugzilla.novell.com or in the SourceForge trackers.

The solution is quite simple: Upload the following PHP script to a webserver and configure your browser to use it as default search engine. If you paste numbers to your browser now, it will go to the bugtracker automatically (the selection depends on the bug number - up to 500000 goes to bugzilla.novell.com, everything above to the SourceForge tracker). If you paste text, you will be redirected to Google.

<?php # cbPasteSearch.php
if (empty($_GET['q'])) {
    echo "Please run me with ?q=searchterm";
} else {
    $q = trim($_GET['q']);
    if (preg_match("/^[0-9]+$/", $q)) { # numeric
        if ($q < 500000) { # Novell bugzilla
            header("Location: https://bugzilla.novell.com/show_bug.cgi?id=$q");
        } else { # SF tracker
            header("Location: https://sourceforge.net/support/tracker.php?aid=$q");
        }
    } else { # not numeric - ask Google
            header("Location: http://www.google.de/search?q=$q");
    }
}
?>

Natürlich kann man sich das Script nach Bedarf durch zusätzliche if-Abfragen anpassen. Vorschläge dazu nehme ich in den Kommentaren gern entgegen ;-)

Of course you can customize the script as needed by adding additional if statements. Please add your ideas to the comment section ;-)

Auch wenn das Aufkommen an Gästebuchspam aktuell zurückgeht (im April nur noch 1/5 dessen, was zwischen November und März monatlich an Spameinträgen reinkam), wird es Zeit, dass ich mal wieder ein Update meines Gästebuch-Spamfilters veröffentliche.

Eine reine Filterung auf "<a href=...>" und "[url]" reicht leider nicht mehr aus, aber es gibt ja noch mehr Möglichkeiten. Aktueller Stand:

preg_match_all("@http://@", $eintrag, $http_count_tmp);
preg_match_all("@%@", $www, $prozent_count_tmp);
if (
    preg_match ( "/\[URL=.*\]|<a[^>]*href|^abc123$/i", trim($eintrag))
    || ( count($http_count_tmp[0]) > 3 )
    || ( $leerfeld != "" )
    || ( ( $name == $ort ) && ( $name != "" ) )
    || ( count($prozent_count_tmp[0]) > 10 )
) {
    echo "Verp*** dich, Spammer!";
    die;
}

Gefiltert wird also auf folgende Kriterien:

• der Eintrag enthält "<a href=...>" oder "[url]"
• lustigster Filter: der Eintrag lautet "abc123" - scheinbar lieben die Spammer solche Kurzeinträge ;-)
• im Eintrag kommt mehr als dreimal "http://" vor
• das Leerfeld (ein per CSS display:none ausgeblendetes Eingabefeld) wurde ausgefüllt
• die Homepage mehr als 10 %-Zeichen enthält (gern verwendet bei "Fremdhosting" von Spam, aka unsichere, gecrackte Forensoftware u. ä.)
• zwei Felder mit gleichem Eintrag

Die aktuelle Trefferquote liegt sehr nahe an 100%. Insbesondere das Leerfeld hat mir in letzter Zeit gute Dienste geleistet, weil viele Spammer nur noch einen kurzen Text (englisch, italienisch oder in kaputtem deutsch) ohne Links eintragen.

UPDATE 17.8.2007:
Filter auf >10 Prozentzeichen und auf Felder mit gleichem Eintrag hinzugefügt (ist schon seit einiger Zeit im Gästebuch-Spamfilter enthalten - seitdem ist wieder Ruhe.)

Im Gästebuch der Landjugend RheinhessenPfalz habe ich ein paar Zeilen PHP-Code verwendet, um Gästebuch-Spam abzufangen. Das Funktionsprinzip war recht einfach: wenn der Eintrag nach Spam aussieht, setze $_POST['firstname'] = "". Das Gästebuch hat dann den fehlenden Vornamen beklagt ;-) und den Eintrag zuverlässig abgewiesen.

Nach dem Update auf Typo3 4.0 funktioniert das so nicht mehr - scheinbar wird $_POST von Typo3 gecacht.

Der Einfachheit halber habe ich jetzt doch ve_guestbook gepatcht:

--- pi1/class.tx_veguestbook_pi1.php_ORIG   2006-10-22 03:07:02.000000000 +0200
+++ pi1/class.tx_veguestbook_pi1.php        2006-10-22 02:56:52.000000000 +0200
@@ -947,6 +947,11 @@  function checkForm() {
                        }
                }

+               if (!empty($this->postvars['entry'])) {
+                       if (preg_match ( "/\[url=.*\]|<a[^>]*href/i", $this->postvars['entry']))
+                           $error .= "<li>Bitte keinen Spam posten!</li>\n";
+               }
+
                if ($this->config['email_validation'] && !empty($this->postvars['email'])) {

                        if (t3lib_div::validEmail($this->postvars['email']) == false) {

Der Feature Request für eine offizielle "Eintrag Blacklist" Konfiguratonsoption in ve_guestbook, die ganz normal übers Typo3-Backend konfiguriert werden kann, ist übrigens auch schon beim Autor eingereicht ;-)

 

UPDATE (17.11.2006)

Der Fehler lag woanders - Typo3 4.0.2 cacht ve_guestbook zu aggressiv.

Das führte zum Einen dazu, dass mein Hack, $_POST zu verändern, nicht mehr funktioniert hat, und zum anderen dazu, dass keine neue Gästebucheinträge akzeptiert wurden - die Bestätigungsseite wurde gechacht und der Eintragen-Code im Gästebuch wurde deshalb nicht mehr ausgeführt :-(

Die Lösung: Die Seite komplett vom Cachen ausschließen (nicht wirklich empfehlenswert) oder im Typoscript plugin.tx_veguestbook_pi1 = USER_INT eintragen. (Quelle)

Und schon kann man wieder $_POST missbrauchen ;-)

In Single Sign-on in phpMyAdmin aus einer anderen PHP-Session habe ich erklärt, wie man mit einer bestehenden Session passwortlos zu phpMyAdmin kommt und einen entsprechden Hack für die config.inc.php gezeigt.

Inzwischen wurde phpMyAdmin 2.9.0-rc1 releast, in dem ein neues Authentifizierungsmoduls "signon", basierend auf meinem Hack, enthalten ist. Zu konfigurieren ist das Ganze über ein paar Variablen in der config.inc.php:

$cfg['Servers'][$i]['auth_type']     = 'signon';
$cfg['Servers'][$i]['SignonURL']     = '/login.php';
$cfg['Servers'][$i]['LogoutURL']     = '/logout.php';
$cfg['Servers'][$i]['SignonSession'] = 'PHPSESSID';

Die MySQL-Logindaten müssen natürlich in der Session hinterlegt werden. Gegenüber meinem ursprünglichen Code haben sich die Variablennamen leicht verändert. Die Session wird mit folgendem Code befüllt:

$_SESSION['PMA_single_signon_user'] = "username";
$_SESSION['PMA_single_signon_password'] = "password";
if (!isset($_SESSION['PMA_single_signon_token'])) {
    $_SESSION['PMA_single_signon_token'] = md5(uniqid(rand(), true));
}

Kleine Stolperfalle: PMA_single_signon_user und PMA_single_signon_password werden beim Logout aus phpMyAdmin gelöscht. /logout.php sollte also wirklich sofort den Logout machen. Wenn man eine Abfrage "wirklich ausloggen?" hat und der User "nein!" antwortet, wird man trotzdem von phpMyAdmin ausgesperrt (oder muss PMA_single_signon_* nochmal neu setzen). Ja, ich habe das reklamiert, der phpMyAdmin-Entwickler wollte das aber nicht ändern.

Übrigens: PMA_single_signon_token benötigt man immer dann, wenn man direkt auf eine Unterseite von phpMyAdmin verlinken will (z. B. um einen Datensatz direkt zu bearbeiten). Im Link zu phpMyAdmin muss der Wert dann im ?token= Parameter angegeben werden.

Ich habe eine Seite mit selbstgestricktem Login auf Basis von PHP-Sessions. Jetzt will ich phpMyAdmin einbinden, ohne dass man sich nochmal darin einloggen muss - schließlich sind die Leute ja schon auf meiner Seite eingeloggt.

Sowas schreit förmlich nach Single Sign-On. Schönes Buzzword, allerdings findet Google für phpMyAdmin recht wenig zu diesem Thema.

Nach einigem Trial&Error sowie einem Nachmittag in #phpmyadmin habe ich eine Lösung geschrieben, die nur eine Ergänzung der config.inc.php braucht, ansonsten nicht in phpMyAdmin eingreift und nichtmal das normale Login stört - ich kann also dieselbe phpMyAdmin-Instanz für Single Sign-On und Cookie-basiertes Login verwenden.

Vor ein paar Tagen habe ich einen Spamfilter ins Gästebuch von Landjugend-Insheim.de eingebaut, nachdem eine Handvoll Spameinträge aufgeschlagen war.

Weil das Gästebuch nur Plain Text-Einträge erlaubt, ist das Funktionsprinzip einfach: ich kann auf <a href=...> und [url=...]filtern. Die Spammer sind immer so nett, diese Tags in reichlicher Anzahl in ihre Einträge zu packen ;-)

Technisch gesehen sieht das so aus:

<?php
if ( preg_match ( "/\[URL=.*\]|<a[^>]*href/i", $eintrag)) {
    echo "Verp*** dich, Spammer!";
    die;
}
?>

Naja, die echte Fehlermeldung ist etwas freundlicher - es könnte ja auch mal jemand einen "guten" Eintrag schreiben und auf aktiviertes HTML hoffen. Der bekommt dann natürlich nach Entfernen der Links eine zweite Chance.

Gestern und heute hat mir dieser Filter reichlich Arbeit gespart - innerhalb von 36 Stunden hat er mir 170 Spameinträge vom Hals gehalten...