CBlog

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.

If you missed my talk at the openSUSE conference or want to see the slides (including notes) again - here we are:

1001 bugs - or: the golden rules of bad programming as PDF
(If you need an editable LibreOffice file, just drop me a note.)

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...