Schlagwort: PHP

Veröffentlicht am

Warum das Rad neuerfinden?

Wer eine Webpräsenz aufbauen will, steht immer vor der Entscheidung „Make or Buy?“. Einerseits gibt es für alles und jedes – Foren, Gästebücher, Content-Management-Systeme, eCommerce-Shops, … fix-fertige und oft genug sogar kostenlose Dinge aus der OpenSource Gemeinde. Andererseits sind doch immer noch genügend „Extrawünsche“ vorhanden, die doch der individuellen Programmierung bedürfen. Und leider ist bei einigen OS-Projekten die Codequalität und/oder die Dokumentation so schlecht, das man’s genauso gut (oder besser) gleich selbst neuprogrammiert anstatt sich in den Code des Kollegen einzufummeln.

Bei red@ktiv sind wir zwischenzeitlich dazu übergegangen, an uns herangetragene Projekte gegen folgende OpenSource-Lösungen zu prüfen:

  • Typo3: ein sehr mächtiges Content-Management-System, das mit TypoScript fast eine eigene Programmiersprache mitbringt. Ist die Einrichtung einer Präsenz mit der Festlegung von Templates, Funktionen und Gestaltung erst einmal erfolgt, wird man jedoch mit einem leistungsfähigen Tool belohnt, mit dem man dennoch Kunden nach kurzer Einarbeitung guten Gewissens bei der Pflege ihrer Seiten weitgehend alleine lassen kann. Insbesondere die Möglichkeit mehrere Sprachvarianten einer Seite zu haben ist ein schlagendes Argument pro Typo3. Vorgehende Versuche ähnliches mit Mambo zu realisieren endeten in einem ziemlichen Desaster, so daß wir davon komplett abgekommen sind. Auch wenn die Einrichtung und Verwaltung unter Mambo sehr viel einfacher und oft genug auch ausreichend wäre, greifen wir auch für kleinere Projekte bevorzugt auf Typo3 zurück.
  • WordPress: Blog-Systeme sind nach wie vor en vogue und für kleine, private Webseiten ein gutes Mittel der Wahl um aktuelle Begebenheiten zu erfassen und zu publizieren. Darüberhinaus können Blogs eine wichtige Begleitmusik in Sachen Suchmaschinenoptimierung spielen. Aktualität ein wichtiges Kriterium für das Ranking bei Suchmaschinen. Und einfacher als mit einem Blog lassen sich aktuelle Dinge kaum erfassen. Über ein gut ausgebautes System von PlugIns lassen sich leicht zusätzliche Funktionen in WordPress implementieren.
  • xt:Commerce: auch wenn das Vertriebskonzept mit kostenpflichtiger Zwangsmitgliedschaft im Supportforum der Hauptentwickler mit dem Opensoure-Gedanken in krassem Widerspruch steht und etliches am HTML- und CSS-Code von xtCommerce ziemlich krank ist – es ist das Mittel der Wahl, wenn es um einen guten Webshop geht! Sowohl funktional als auch gestalterisch (wenn man denn die elementarsten Fehler mal gerade gerückt hat) bietet xt-Commerce eine exzellente Basis für eCommerce Anwendungen. Wie auch bei Typo3 ist die Möglichkeit mehrere Sprachvarianten zu verwalten sehr ausgeprägt und für ein Online-Business geradezu elementar. Über das smarty-System das für die Generierung der Templates verantwortlich ist, kann man zu dem die Gestaltung der Seiten sehr gut anpassen und in valides XHTML überführen, so daß ein gute Grundlage für die Gestaltung mit CSS besteht. Die in der Szene gehandelten oder bereitgestellten total veralteten Tabellenlayout-Konstrukte, die mit i
  • phpiCalender/phpMyCal: wenn es um die Erfassung und Verwaltung von Terminen geht kann es nur eine Wahl gegen – ein System das den iCal-Standard unterstützt. phpiCalendar tut dies vorbildlich. In Zusammenarbeit mit phpMyCal entsteht noch ein Webfrontend über das Termine zu erfassen und zu pflegen sind. Leider ist phpMyCal derzeit vom Netz verschwunden, so daß wir hier eine von Relate Me >bereitgestellte Version, die wir auf Standalone-Betrieb rückentwickelt haben, nach den Regeln der GPL zum Download einstellen.

Modifizierte Version von phpiCalendar mit phpMyCal-Extension

Wie man an den aufgeführten Beispielen unschwer erkennen kann: es bleibt in allen Fällen genügend Arbeit übrig um die „fertigen“ System passend für die Kundenanforderunge zu modifizieren. Durch die Offenheit des Quelltextes ist es uns jedoch leicht möglich zusätzliche Funktionaliäten oder kundenspezifische Änderungen zu erstellen. Der Fall, das eine OpenSource-Software out-of-the-box die Anforderungen des Kunden erfüllt ist höchst selten. Mindestens die Identifikation und Installation von PlugIns gehört zum Standardrepertoire. Im nächsten Schritt steht dann die Entwicklung eigner Erweiterungen. Erst wenn die Anforderungen soweit vom Grundsystem abweichen, das schon die Umprogrammierung und -konfigurierung des Grundsystems einer kompletten Neuentwicklung gleich kommt, greift noch „Plan B“ und wir entwickeln Dinge von Grund auf neu und kundenspezifisch.

Veröffentlicht am

Spam, Eggs, Spam, Ham, Spam, Spam, Sausage and Spam

Jeder der über einen Mail-Account verfügt wird es schon verflucht haben: die unzähligen Werbebotschaften, die einem die Mailbox dermassen fluten, das wesentliche Informationen beinahe untergehen. Spam ist eigenlich Frühstücksfleisch. Als nerviges Element wurde es durch einen Sketch der Komiker-Truppe Monty Python geprägt. Stellt sich also für jeden die Frage wie man sich vor Spam – richtiger vor Unsolicited Bulk eMail, UCE – schützen kann.

Eine Patentlösung gibt es leider nicht. Aber über ein paar Instrumente kann man den Spamern wenigstens das Leben etwas schwerer machen.

  1. bei der Gewinnung von eMail-Adressen über Webseiten kann man Spambots ein paar Beine stellen. Spambots sind Roboterprogramme die das Netz nach einem eMail-Adressmuster auf Webseiten durchforsten. Klassisch sind dabei »mailto:« oder das »@«-Zeichen. Ggf. auch verfeinert durch sog. reguläre Ausdrücke, z.B. ob hinter dem @ auch noch irgendwann ein Punkt und ein »de«, »com» oder ähnlich erscheint. Tauscht man solche verräterischen Bestandteile durch URL-Codierungen aus, muß der Erkennungsfilter des Spambots darauf schon wieder trainiert sein. Etliche sind’s, aber ein paar eben nicht, und die sind dann schon mal draussen. Für den Mac gibt es das Programm SpamStopper, das einem hilft solche URL-Codierten Mail-Adressen zusammen zu bauen. Dieser Schutz geht allerdings nicht sehr weit und wird in der Netiquette z.T. als »unfreundlich« eingestuft.
  2. einen Schritt weiter geht unsere red@ktiv-Lösung. Wir codieren eMail-Adressen beim Seitenaufruf mit PHP-Funktionen und generieren aus dem Text des Maillinks ein Bildchen. Dieses Bildchen ist für jeden User Klartext lesbar, aber Spambots können mit dem .png-Format nichts anfangen. Der Link der um dieses Bild liegt ruft darüberhinaus nicht das lokale Mailprogramm auf (was »mailto:« machen würde), sondern verzweigt in ein eigenes WebForumular. Praktische Anwendung z.B. bei http://www.transalp.de/about/kontakt.php Sämtliche dort gelisteten eMail-Adressen sind solche Bildchen, die das Kontaktformular aufrufen. Nachteil der Lösung: es braucht ein Webhosting mit PHP-Unterstützung, was i.d.R. etwas teuerer ist.
  3. wenn schon PHP, dann richtig: in jeder Datei steckt ein Header drin, der überprüft, wer diese Seite gerade aufruft. Die Spambots identifizieren sich gegenüber dem Server, so wie das auch jeder Browser oder jede Suchmaschinen tut (ein Spambot ist genau genommen nichts anderes als eine Suchmaschine und eine Suchmaschine streng genommen auch nur ein Sonderfall eines Browsers). Da diese Kennungen bekannt sind, können Seitenaufrufe durch solche Kanditaten von vorherein unterbunden werden. Nachteil: ändert der Bot seine Kennung oder gibt sich als stinknormaler Browser aus, ist diese Bremse umgangen.
  4. Noch einen Schritt weiter geht die Methode von Daniel Rehbein: Dieser wirft per PHP-Programm den Spambots »getürkte« Mailadressen zum Fraß vor, die für einen normalen Nutzer unsichtbar sind (also garantiert nur von Spamern genutzt werden). Die krude Adresse hat aber dennoch einen realen Hintergrund. Durch entschlüsseln der Mailadresse kann der Zeitpunkt des Aufrufs, die IP des Aufrufers etc. bestimmt werden. Tauchen bestimmte IP-Bereiche dabei häufiger auf, kann man schon mal nachsetzen wer sich dahinter verbirgt und einen solchen Adresslieferanten dingfestmachen. Teleinfo.de, die in Daniels Falle geraten war, hatte jedenfalls ordentlichen Rechtfertigungsdruck :-D.
  5. für Registrierungen, Umfragen, etc. etc. sollte jeder mindestens eine »Mülleimer«-Adresse haben. Gerade Webmail-Anbieter wie http://freemail.web.de oder http://www.gmx.de etc. etc. taugen sehr gut für solche Adressen, die man den Spamern zum Fraß vorwerfen kann. Wird das Postfach zu voll, einfach den Account kündigen. Für die wirklich wichtigen Sachen hat man dann noch eine zweite Adresse, die nur im engen Kreis gestreut wird.
  6. Wer eine eigene Domain besitzt, verfügt i.d.R. auch über reichlich eMail-Adressen, die man über eine Weiterleitung oder ein Default-Postfach wieder zusammenführen kann. Damit kann man dann für ebay, amazon etc. etc. eigene Mailadressen wie ebay@meinedomain.de kreiieren. Läuft dann irgendwann mal Spam auf so einer Adresse ein, kann man nachvollziehen, woher dieser kam und ggf. auch den Betreiber einer solchen Seite angehen. Gerade namhafte Anbieter, die eine Weitergabe von eMail-Adressen vorher ausdrücklich ausgeschlossen haben. werden ein Eigeninteresse haben, undichte Stellen dann zu lokalisieren um nicht selbst in Verruf zu geraten.
  7. Spamfilter. Die aus AppleMail oder aus Eudora lassen sich schon recht gut trainieren, weitere Möglichkeiten gibt es insbesondere durch den Einsatz eines eigenen Mailservers (z.B. unter Linux) der über eigene Filterregeln verfügt und diese laufend mit dem Internet abgleicht. Im Netz werden sog. Blacklists von Spamern bereitgestellt, mit der sich bestimmte aktuelle Spamaufkommen sehr gut klassifizieren und filtern lassen. Eine Übersicht liefert http://www.spam-blockers.com/SPAM-blacklists.htm Mit einem solchen vorgeschalteten Server lassen sich weiterhin auch sehr gut Virenfilter aufsetzen.

Der Vollständigkeithalber, auch wenn’s nicht zum engeren Kreis von Spam gehört:

eMail-Verkehr geht Klartext über die Leitung. D.h. jede Zwischenstation (sog. Mail-Relays) können diese theoretisch mitlesen und auswerten. Auch wenn es keinen direkten Schutz für die eMail-Adressen von Sender und Empfänger bedeutet (logisch: die müssen Klartext lesbar bleiben) kann und sollte man wichtige Nachrichten PGP-verschlüsseln.

Nur einen geringen Schutz bieten die SSL-Verbindungen zu den Mail-Relays des jeweiligen Providers. Damit wird lediglich der Datenverkehr auf dieser einen Strecke verschlüsselt. Alle anderen Zwischen-Hops von Server zu Server die zwischen Mailabsender und -empfänger liegen laufen nach wie vor Klartext ab.

Fazit: Wie auch bei Viren, Firewalls, WLAN-Abschottung und anderen Sicherheitsthemen kann es immer nur darum gehen, Hürden aufzustellen, die Leuten mit unlauteren Absichten das Leben schwer machen. Je mehr Hürden desto schwerer, aber unüberwindlich ist in letzter Konsequenz keine dieser Hürden. Nur der Aufwand zur Überwindung wächst und zumeist entwickelt sich damit das Interesse an der Überwindung umgekehrt proportional ;-).

Der Monty Python Spam-Sketch