Hier verkünde ich: Wer dieses tolle Tool zum Sortieren von HTML-Tabellen NICHT einsetzt, gehört zurückversetzt nach Klasse Web 0.9! So, basta!

Ich möchte es nie mehr missen!

Man-in-the-middle zwischen Client und Server

Ersteinmal beziehen sich alle Angriffe auf eine Situation namens Man-in-the-middle. Das heißt, der Angreifer sitzt zwischen Nutzer und Server. Er muss also einen Rechner besitzen, der die Anfragen des Client mitliest, an den Server weiterleitet und später dessen Antwort an den Client vermittelt. Ein Proxy, Gateway oder Router erfüllt diese Voraussetzung. Nennen wir ihn einfach mal Proxy. Ohne diese Gegebenheit ist ein SSL-basierter Datenaustausch grundlegend sicher, das ist schon einmal ein guter Ausgangspunkt. Doch wie nutzt nun der Proxy seine Rolle aus?

Während des Datenaustausches zwischen Client und Server kann der Proxy zum Beispiel einen Login-Ablauf des Client am Server mitlauschen und nachspielen. Er tauscht dazu innerhalb einer HTML-Seite mit Verweis zum Login-Bereich alle Aufrufe von https://meinhost.de/login.php durch http://meinhost.de/login.php aus. Der Benutzer wechselt also beim Eintippen gar nicht in den HTTPS- (also SSL-)Modus – und gibt dem Angreifer die gewünschten Informationen per POST-Formular bekannt. Jetzt kann der Proxy die Daten dem Server übergeben  – hier kann er verschlüsselt arbeiten – und dadurch sowohl Client als auch dem Server eine funktionierende, direkte Verbindung vortäuschen. Später kann er die Daten für Spionage nach Zahlungsdaten missbrauchen, verkaufen, vom Server aus weitere Angriffe im Namen des Clients starten oder darüber Spam versenden.

Wie kann man nun diesen Angriffen begegnen? Alle Ideen sind hier gefragt! Denn sollte sich herausstellen, dass die verschlüsselte, intime Kommunikation zweier Internet-Teilnehmer untereinander nicht gesichert ist, so ist das Fortbestehen sämtlicher netzbasierten Dienste in Frage gestellt. Zwar ist solch eine Proxy-Situation heutzutage noch sehr selten gegeben. Doch wenn die Möglichkeiten infolge des Problems erst einmal bekannt sind, wird sich das schnell ändern. Ein Angriff auf die Vertrauenswürdigkeit der Internet-Infrastruktur hat im Informationszeitalter durchaus katastrophale Folgen – eine Schande, warum DNS noch so schwächelt!

Ideen sind gefragt

Der wunde Punkt ist wohl das Wissen der Kommunikations-Partner übereinander. Was weiß der Client über den Server? Was weiß der Server über den Client, was er gegen den Angreifer nutzen kann? Leider ist ein Service, zum Beispiel ein Shop oder eine Plattform, grundsätzlich für jedermann offen und auch bisher unbekannte Gäste sind herzlich eingeladen, den Server zu kontaktieren. Doch gibt es etwas, was sie vom Man-in-the-middle unterscheidet?

Mir ist folgendes dazu eingefallen: Wir könnten dem Client signalisieren, er müsse auf die Verschlüssung achten. Zum Beispiel an verschiedenen Stellen darüber informieren, dass wir grundsätzlich sicher kommunizieren wollen. Der Nutzer soll doch darauf achten, dass immer das Verschlüsselungssymbol aktiviert ist. Der Angreifer müsste dann diverse Ausgabetexte manipulieren, um dessen Anzeige zu verhindern. Aber nicht jeder Benutzer liest Hinweise oder folgt diesen gar, zu lange war Software so unausgereift, sodass eine grundsätzliche Ignoranz gegenüber Fehlermeldungen festzustellen ist.

Damit würde man auch nur den Punkt der Nicht-Verschlüsselung der Proxy-Client-Verbindung beheben. Letztenendes könnte auch der Proxy selbst mit dem Client verschlüsselt kommunizieren, mit seinem eigenen Zertifikat natürlich. Wir können aber kaum erwarten, dass der Nutzer nach dem Aufbau der verschlüsselten Verbindung zum Proxy das übermittelte Zertifikat prüft.

Desweiteren könnte man die Verschlüsselung per JavaScript testen. Dazu ruft man nach dem Aufbau der Seite deren URL im Browser ab. Dessen Filterung wäre allerdings sehr einfach und nicht jeder Browser kommt mit JavaScript daher, wenn auch viele. Ich weiß gar nicht, ob es JavaScript-Funktionen zum Auslesen der Zertifikatinformationen gibt. Falls überhaupt, wäre ein einfacher Austausch der JavaScript-Funktionsnamen alles, was der Proxy tun müsste, um seine Tarnung aufrecht zu erhalten.

Eine Idee wäre weiterhin, immer in SSL zu kommunizieren. Da SSL immer auf eine IP-Adresse bezogen ist, wüsste der Proxy im Falle eines Multihosters von vornherein nicht, um welche Domain es sich handelt. Größere Webauftritte haben eher mehrere IPs für eine Domain, da wäre es wieder einfacher – eine leichte Verwirrung also nur für kleinere Seiten, das ist keine Lösung.  Was er definitiv nicht weiß, ist, um welche URI, also abgerufene Seite mit Parametern, es sich handelt. Er müsste also darauf setzen, dass eine Session zumeist in einer der Index-Dateien beginnt und an sich keine Parameter mit sich bringt. Mißtrauen wir also allen Besuchern einer Index-Seite? Das geht ebensowenig.

Da das Zertifikat jedoch definitiv nicht passt (es sei denn, es ist für Kollisionen manipuliert), würde der Browser beim Aufbau der SSL-Verbindung zumindest eine Warnung ausgeben. Na das ist ja schon mal etwas. Jetzt muss man nur noch a) den Nutzer dazu bringen, seine eigene URL immer im SSL-Modus zu bookmarken und b) dafür sorgen, dass SSL-Fehler-Warnungen ganz deutlich wahrgenommen werden. Letztlich ist die SSL-Methode weiterhin sicher, nur der Wechsel von HTTP auf HTTPS nicht, weil die Inhalte im HTTP-Modus manipulierbar sind.

Theorie und Praxis

Leider erlebt man jeden Tag den umgekehrten Weg: Statt wenigstens nach dem Login die Session verschlüsselt weiterzuführen, wechseln große Provider gerne mal nach dem Login-Prozedere zurück in den HTTP-Modus. Ist ja auch schneller. Dass sie dabei ihre Nutzer Gefahren aussetzen, wird dabei schnell mal in Kauf genommen. Zum Beispiel ebay. Was man da alles machen könnte – dazu braucht man nicht einmal als Proxy mit SSL arbeiten. Sogar in das eigene Konto kann man per HTTP wechseln! Sicherlich besteht die Seite aus sehr, sehr vielen Bildern, und die müssten alle per HTTPS einzeln abgerufen werden. Das kostet Kondition für Client und Server. Doch was nützt Geschwindigkeit ohne Integrität? Da kann ich gleich eine Seite aus /dev/random ziehen.

In unserem ebrosia Wein-Shop ist eine Bestellung oder das Betreten des Konto-Bereichs ohne HTTPS-Modus gar nicht möglich. Selbst wenn man als Nutzer aus https:// ein http:// macht – unser Shop verlangt einfach die Verschlüsselung und korrigiert es entsprechend. Natürlich ist das heute keine Garantie gegen eine Man-in-the-middle-Attacke. Dazu müssten wir unsere Nutzer zu reinen SSL-Nutzern erziehen. Doch wenn es nötig sein sollte, wird das getan werden. Wir als Service-Betreiber sind das unseren Nutzern einfach schuldig.

Fazit

Nun, mit durchgehender Verschlüsselung wäre schon ein großer Schritt getan. Wenn wir jetzt noch einen Weg fänden, Server-initiiert das eigene Zertifikat auf Seiten des Nutzers zu prüfen, könnten wir den Proxy aus dem Rennen zu werfen…hat dazu jemand eine Idee? Vielleicht braucht man einen dritten Host, der das Geschehen von außen beobachten kann?

Doch warum gibt es immer wieder neue Sicherheitslücken?

Hier überlagern sich meines Erachtens mehrere Teilprobleme:

1. Technologie-Wandel: Die Welt ist im stetigen Wandel. Software bildet aber immer nur einen Snapshot, einen momentanen Wissenstand ab. Was zukünftig damit zu verarbeiten ist, ist bei Erstellung der Software unklar.
2. Die Kommerzialisierung der Netzkultur fordert ihre Opfer: Das Netz wird zum Angriffsziel derer, die nicht zur Loge seiner offiziellen Beherrscher gehören. Im Zeitalter der Information ist der Besitz von Daten, Servern, Technologien wie auch das Wissen zur Manipulation und Zerstörung von Infrastruktur bares Geld wert.
3. Die Geschwindigkeit, in der Software erstellt, konsumiert (benutzt) und entsorgt wird, ist gegenüber traditionellen Produkten unvergleichbar erhöht. Die Kosten durch Schaden aus Software-Fehlfunktionen wird weiterhin unterschätzt – Software macht ja (zunächst) nichts wirklich kaputt. Aus diesem Kreativitätsdruck heraus wird viel zu unreife Software auf den Markt geworfen: Früher oft Bananensoftware – reift beim Kunden – genannt, findet im Netz seine Fortsetzung in der beta-Kultur des Web 2.0.
4. Die Schnittstellen von verschiedenen technologischen Bereichen sind inkompatibel. An diesen Reibepunkten entstehen Konvertierungsverluste, die nur mit ungemein hohem Aufwand optimal unterdrückt werden können. Gerade hier wird oft die 80:20-Regel der Softwareerstellung zugunsten der schnellen 80%-Funktionalität vorgezogen: Es funktioniert, im Prinzip, wenn man es so oder so benutzt. Ein Beispiel: Desktop und Netz. Sie funktionieren anders und sind für andere Daten konzipiert. Ein Übergang Netz -> Desktop oder Desktop -> Netz ist extrem fehleranfällig.
5. Software ist nicht immer frei. Unfreie Software kann weder von Sicherheitsexperten begutachtet, noch von so vielen freiwilligen Helfern verbessert werden. Firmen glauben leider immer noch an das Mysterium Software-Monopol. Aber das weiß der geneigte Leser dieses Blogs sicherlich besser…

In eingangs genannten Fall sind

• die Sicherheitsfunktionen der Browser auf dem Stand der Netzangriffe vor Erstellung der jeweiligen Version
• der Flash-Player eine proprietäre unkontrollierbare Software
• die Schnittstelle zwischen HTML und Flash mehr als unausgereift und nicht standisiert
• die Rückverfolgbarkeit von Angriffen auf das eigene System nur für Experten machbar

Man kann nur hoffen, dass der kommende Standard von HTML 5.0 unter Webentwicklern angenommen und durch die Integration von Ogg Theora und SVG die Verbreitung binärer Plugins eingedämmt wird.

just my 2 cents

Ich habe nun endlich das Problem, welches viele T-Online-Kunden beim Surfen auf so vielen Portalen haben, erkannt. Schuld ist der Browser selbst (Oh, welch Wunder!), der seine User-Agent-Kennung nach Lust und Laune wechselt!

So meldet sich der T-Online-Browser zunächst in dieser Form:

Mozilla/4.0 (compatible; MSIE 6.0; TOB 6.05; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Später erscheint folgende Kennung am Server:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Wie man sieht, wurde die spezielle T-Online-Kennung ” TOB 6.05;” in den späteren Clicks entfernt. Dies scheint ein nicht seltenes Phänomen zu sein, wenn ich unsere Logs richtig interpretiere. So liegt die durchschnittliche Click-Anzahl eines TOB-Surfers zwischen 1 und 2, d.h. die Session ging meist zwischen dem 1. und 2. Click verloren. Das ist nicht nur ärgerlich, das ist einfach katastrophal für jeden sicherheitsbewussten Webserver-Administrator.

Das Problem mit der Browser-Kennung

Viele Portale bieten Login-basierte Services an. Durch diese personalisierte Interaktion entstehen jedoch sensible, d.h. vertrauliche, Daten. Die Portale müssen daher sicherstellen, dass diese Daten nur der entsprechende Benutzer und ansonsten kein anderer Mensch der Welt sieht. Dabei verlassen sich Web-Applikationen unter anderem auf die Browser-Kennung des Gegenübers als eines von vielen Sicherheitsmerkmalen, um eine aktive Sitzung einem Kunden zuverlässig zuweisen zu können. Damit soll das sogenannte Session-Hijacking verhindert werden.

Session-Hijacking im Details

Session-Hijacking bedeutet das Kapern von aktiven Sitzungen eines Benutzers durch fremde Angreifer ohne Kenntnis von Passwörtern oder Login-Daten. Vielmehr zielt der Angreifer auf einen Sitzungsschlüssel, der vom Webserver zufällig für eine Sitzung als Schlüssel (Session-Key) erzeugt wird. Dabei wird die Tatsache ausgenutzt, dass Web-Server nur eine begrenzte Anzahl von Session-Keys generiert werden können, denn die Schlüssel sind immer 32-stellig und hexadezimal.

Durch genügendes Probieren kann bei einem sehr frequentierten Server in hinreichender Zeit ein aktiver Schlüssel entdeckt werden. Normalerweise wird der Schlüssel per Session-Cookie weitergegeben. Jedoch erlauben nicht alle Browser das Setzen eines Cookies, sodass die Weitergabe in der URL als Fallback-Methode häufig angeboten wird. Dort kann der Angreifer ansetzen und zufällige Session-Keys in hoher Geschwindigkeit durchprobieren. Hat er gar Kenntnis über die Existenz eines aktiven Session-Keys, so kann er mit deren Hilfe versuchen, die entfernte Sitzung zu übernehmen. Der betroffene Nutzer bekommt dies nicht unbedingt zu spüren.

Prävention: Die IP-Adresse

Neben der Browser-Kennung ist zum Beispiel die IP eine gute Methode, um Session Hijacking zu verhinden. Diese ist für einen Rechner im Internet eindeutig, allerdings nur für die Zeit der aktiven Nutzung, was in diesem Falle reicht. Durch die Knappheit der IP-Adressen halten Provider einen gewissen Pool von IP-Adressen bereit, von denen bei der Einwahl eine mehr oder weniger zufällig vergeben wird.

Allerdings ist hier Vorsicht geboten, da viele Nutzer hinter Web-Proxies surfen, die ihn in gewisserweise anonymisieren. Dies ist dem Surfer nicht immer bekannt, da große Zugangsprovider oft eigenes transparentes Proxy-Caching betreiben. In diesem Fall liegen viele Nutzer hinter nur einer sichtbaren IP-Adresse. Proxies können diese Weiterleitung über die HTTP-Header-Felder X_FORWARDED_FOR oder CLIENT_IP_ADRESS bekanntmachen. Doch die Angaben sind optional (ohne Gewähr) – verlassen kann man sich also darauf nicht.

Daneben gibt es fast überall lokale Netze (LANs), deren Benutzer alle mit der IP des Zugangsrechners (Gateways) surfen. Wenn wie in Firmen durch Standardisierung gleiche technische Bedingungen vorliegen, in dem Betriebssysteme und Browser vorgegeben werden, so erscheinen dem Server alle Benutzer dieses Netzwerks wie ein identischer Client.

Daneben kann es passieren, dass Zugangsprovider Proxying mit wechselnden End-IP-Adressen durchführen. AOL ist dafür bekannt. Dies erschwert dem Server, eine Session zumindest einer IP zuzuordnen. Um den Nutzer nicht zu verlieren, müssen Sub-Netze für die Weitergabe der Session erlaubt werden, doch selbst Class-B-Netze (zB. 123.5.xxx.xxx) werden hier oft verlassen.

Fazit: Mißtrauen ist gut, Kontrolle nicht möglich

In dieser Situation einen Spagat zwischen Kundendaten-Sicherheit wie den Schutz eingegebener Kreditkartendaten und das Angebot nutzerfreundlicher Sites hinzubekommen, fällt schwer. Was der Datenschutz auf der einen Seite richtig macht (das anonymisierte Surfen), erschwert den Datenschutz des Benutzers an anderer Stelle, nämlich in Online-Shops, Foren, Chat-Rooms oder Email-Services – überall dort, wo ein Login mehr als einen Click halten muss.

Letztendlich ist eine Sicherheitslücke wohl von schwererem Ausmaß als der Verlust einer Session – denn diese kann mit einem anderen Browser wiederholt werden. Daher gilt in meinen Augen folgende Regel: Strikte Prüfung des Logins und Vorbeugung von Session-Hijacking – kombiniert mit Empfehlungen (zB im Fehlerfall anderen Browser vorschlagen), die dem Surfer die Vertraulichkeit seiner eigenen Daten bewusst macht. Nur dies schafft langfristigen Datenschutz!

Man braucht im CSS nur die beiden Klassen direkt nacheinander angeben, à la:

div.klasse1.klasse2 {
  text-align:right;
}

Danach habe ich schon immer gesucht, denn es erlaubt letztendlich so etwas wie Mehrfachvererbung in objektorientierten Programmiersprachen: Das saubere Trennen verschiedener Funktionalitätsbereiche in Klassen und deren Vereinigung in einer konkreten Instanz. Sozusagen C++ statt Java. Funktioniert übrigens ab CSS 2.

Klar, denkt ihr vielleicht, hätte man ja einfach mal probieren können. Aber bei den diversen Browser-Bugs vor allem in Hinblick auf CSS hüte ich mich davor, von Browsern rückwärts auf den Standard zu schließen!

Jeder aktive Webmitmacher möchte natürlich auch solche Teilchen anbieten. Und der Weinshop, für den ich arbeite, gehört dazu. Also habe ich mal kurz zusammengesucht, wie das ganze funktioniert und dabei festgestellt: Für den Programmierer wie mich gibt es anscheinend zwei Strömungen dieser Widgets: Erstere laufen als komplett eigenständige Mini-Site und werden über object- oder iframe-Tags eingebunden, während eine weitere Gattung per JavaScript im Ziel-Dokument dynamisch aufgebaut werden. Beides hat seine Vor- und Nachteile. Was ist also besser? Jeder muss selbst entscheiden. Der folgende Vergleich ist sicherlich nicht vollständig, aber vielleicht für den ein oder anderen hilfreich.

Die im object oder iframe eingebundenen Sites haben eine größere Unabhängigkeit vom Dokument. Sie laufen wie in einer Art Schaufenster. Dabei haben Sie einen eigenen Namespace für JavaScript und können durch andere Elemente des Dokuments nicht berührt werden. Das ist in meinen Augen zunächst ein Vorteil, vor allem was die Stabilität und Sicherheit anbelangt. Durch die Separierung kann man es jedoch nicht mit anderen Elementen interagieren lassen – also bieten sich damit funktionell weniger Möglichkeiten. Man braucht eigentlich auch nicht einmal JavaScript dafür (Vorteil) und kann auch per Ajax direkt mit dem Widget-Server kommunizieren und die eigene Widget-Seite beliebig manipulieren (Vorteil). Ein Nachteil ist, dass es schwierig ist, das Teilchen persönlich zu gestalten. Dazu ist oft Vorarbeit auf dem Widget-Server (also ein Login und die lästige Konfiguriererei) notwendig. Ein Beispiel dieser Art ist Youtube.

Zweitere Art arbeitet im DOM des Ziel-Dokuments und wird meist per JavaScript eingebunden. Hier braucht man keine komplette Seite zu generieren und kann sich gleich auf die klitzekleinen Elemente konzentrieren (Vorteil). Allerdings muss man die globalen JavaScript-Variablen des aktuellen Dokuments beachten (Nachteil) und ist soweit ich weiß nicht in der Lage, Ajax-Requests an den externen Server abzusetzen – korrigiert mich, sollte ich hier falsch liegen. Ein weiterer Nachteil ist, dass das parallele Laden des gesamten Dokuments jeweils pro externem Widget-Script geblockt wird. Mit jedem zusätzlichem Widget wird also die Performance immer schwächer. Hier gibts sehr viele Beispiele dafür, eins ist Google’s Adsense.

Für alle, dies genauer wissen wollen, gibt in Englisch diese Seite zu empfehlen. Hier wird auch zwischen passiven, aktiven, JavaScript- und JSON-Widgets unterschieden wird. Ich denke jedoch: Wie dann am Ende gescriptet wird, hängt eher vom Widget-Zweck selbst ab. Aber die Code-Schnipsel sind auf jeden Fall auch ne coole Sache.

In nächster Zukunft werden wir an ein paar Widgets arbeiten, die unseren Kunden und Partnern erlauben werden, die nützlichen Helferlein für unsere Spezial-Angebote wie Tages- und Monatsaktionen einzublenden. Wenn diese fertig gestaltet sind, kann ich diese hier noch schnell einbauen – dafür sind sie ja geradezu geschaffen.

Das bringt mich auf eine Idee: In Zukunft hat jeder nur noch solche Mini-Homepages, die man als Signatur überall hinterlässt, so entfällt das lästige “Hey, check mal meine Seite aus…”. Allerdings kann ich mir vorstellen, dass das zu einer riesigen Traffic-Implosion führt: Irgendwann gibt es nämlich DAS RIESEN-DOKUMENT, deren Aufruf ALLE Websites mit aufruft, eingeschlossen SICH SELBST. Somit hat die Menschheit den Urknall 2.0 selbst geschaffen !!! Die Tragik ist, dass in der Universalbibliothek in entfernter Zukunft zu lesen sein wird, dass die ausgestorbene Spezies Homo sapiens sapiens es leider nie schaffte, das Web 3.0 fertigzustellen. Aber sie waren wohl auf jeden Fall trendy.

Umso erstaunlicher, dass ich selbst seit einigen Tagen an einer Web 2.0 Seite im Intranet unserer Firma bastle. Und ich muss zugeben, Web 2.0 hat etwas.

Am erfreulichsten fand ich die Tatsache, dass man keinen Installationsaufwand hat. Man braucht weder Servlet-Container, Apache-Module noch irgendwelche anderen Erweiterungen auf dem Server, sondern alles läuft auf der Programmier-Ebene ab. Zumindest die technische Seite von Web 2.0 kann auf folgenden Satz reduzieren: Man instanziiert eine Javascript-Klasse namens XMLHttpRequest, führt über die Methoden open() und send() einen asynchronen Request aus und verarbeitet dessen Response auf der bestehenden Seite. That’s it.

Klar, neben dem Request ist vor allem der JS-Code das schwierigste, um den per Response erhaltenen Content ordentlich auf der bestehenden Seite einzubauen. Hier bin ich bisher komplett ohne XML oder XSLT gefahren (also AJ statt AJAX), habe den Response in Stino-HTML erzeugt und einfach in ein dafür angelegtes Seiten-Element als innerHTML reingeworfen. Im Response eingebaut war dann auch schon der Code, um diesen per JS-Aufrufe weiter an andere Elemente zu verteilen. Mit etwas Nachdenken kann man hier mit ein, zwei Übergabeparametern (Element-ID’s, Präfixe) wunderbar generisch arbeiten, so dass sowohl die erstellte Request-Technologie als auch der Management-Code ausgelagert und für mehr als nur eine Seite nutzbar gemacht werden können.

Man kann also ganz klein und leicht beginnen, sich ein paar generische Abfragen und eine JS-Skript-Datei erstellen und schon hat man neue, interessante Werkzeuge, die man sogar noch ganz leicht in bestehende Seiten einbauen kann. Damit das ganze flüssig läuft, habe ich die Indizes unserer Tabellen auf die Abfragen hin ergänzt. Der Faktor der Beschleunigung betrug etwa 2 bis 3! Die schnellen Abfragen ohne JOIN machen dann auch richtig Spaß – es flutscht einfach mal.

Der einizige Nachteil ist natürlich: Der Anwender braucht Javascript! Und der Browser muss auch noch der Site vertrauen. IE7-Nutzer müssen die Seite also evtl. explizit eintragen. Daneben braucht der Nutzer evtl. noch Session-Cookies, damit man mit PHP auch noch die Ergebnise bequem weiterverarbeiten kann, ohne sich die Finger wund zu coden. Im firmeneigenen Intranet ist das alles weniger kritisch, hier kann man die Anforderungen selbst abschätzen/austesten, definieren und für alle verbindlich umsetzen.

Als nächstes gehts weiter mit der Praxistauglichkeit. Wie skaliert das ganze, wenn es auf einem stark frequentiertem Server läuft? Wie stark sind die Latenzen des Netzes? Sollte sich herausstellen, dass flüssiges Arbeiten möglich ist, eröffneten sich uns dadurch ganz neue Möglichkeiten, vor allem bei der Einbindung externer Partner.

Also schnell weiter machen…Tschüß!

Zuerst suchte ich eine schöne handliche Funktion, die mir eine Seitenstruktur aufwärts traversiert, um meine eigene, recht grobgeschnitzte Routine zur Anzeige der Navigation abzulösen.

Also erstmal nach CREATE FUNCTION gegoogelt, denn mein Buch PHP5/MySQL4 umschifft gekonnt dieses technische Terroir. Das Google-Ergebnis war frustrierend: Der wichtigste Link war schließlich die offizielle MySQL-Doku, in den Groups gab es ein paar Beiträge auf polnisch, was ich leider gar nicht verstehe.

Die auf der MySQL-Doku angegebene Syntax-Beschreibung waren abschreckend kompliziert dargestellt. Da muss jemand denken “Eine EBNF sagt mehr als 1000 Worte”. Da hat er wohl recht – wenn man einmal in der Materie drin ist. Wenn mans nicht ist, siehts ganz düster aus.

Eine andere Seite geht dafür den Top-down-Approach, auch mein Traversal-Problem ist hier als Beispiel-Lösung angegeben (juhu! dachte ich erst). Super einfühlsam, hier bleibt man jedoch nach den Überschriften etwas stecken. Denn das Beispiel funktionierte nicht.

Nach etwas Fiddelei stellte sich bei mir heraus: Zunächst war die Syntax “DELIMITER ;” nicht korrekt, dann muss man der Funktion immerhin noch sagen, ob diese READ SQL DATA oder anderen Typs ist. Nach der Syntax dann die Anweisung: Die Abbruchbedingung der WHILE-Schleife haute gar nicht hin. Angeblich soll ja diese Routine in MySQL-Syntax zu beherrschen sein, aber eine WHILE (NOT ISNULL(variable)) scheints nicht zu geben, hier rennt man in eine Endlosschleife. Mit Ctrl-C schießt man dabei leider nur seinen Client ab, der Server läuft mit dem Prozess dann in aller Ruhe weiter. Andere Bedingungen wie “(variable>)” stoppten bei NULL-Werten ebensowenig.

Nach ein paar Versuchen hatte der Server dann einen Load von 9.0 und MySQL eine Prozessorlast von konstant 200 Prozent erreicht. Mein vi hing, die Buchstaben waren eher per Fuß als per ssh auf dem Server. Mühsam schaffte ich es noch per top zu sehen, wer dran schuld war, so dass ich dann MySQL einfach stoppte und neu startete (die anderen in der Firma hatten hoffentlich gerade nix im Intranet zu tun:-)).

Also das war schon mal ein kleiner Reinfall. Meine Routine blieb.

Heute dann mehr Glück, wenn auch mit einem anderen Thema: Views und Indexes. Ich hatte zwischenzeitlich die Shop-Homepage mit einer Menge von Profiling-Anweisungen ausgestattet und konnte so die einzelnen Arbeitsschritte genau analysieren. Erstaunlich schnell konnte ich die “wunden Punkte” erkennen.

Mein erstes Fazit war: Lange Dateien per include in PHP-Code zu laden ist nicht schneller, als wenn es zwei kleinere Dateien sind. Meine Arbeitshypothese lautete bis dato noch: Weniger Dateien zu öffnen dauert nicht so lange wie ein sequentieller Lesevorgang einer Datei. Da lag ich wohl falsch, und bin nun froh, dass sinnvolles Strukturieren von include-Dateien “erlaubt” ist.

Zweites Fazit: Meine Arbeitshypothese, dass ich in Zukunft auf Apache’s mod_mem_cache setzen sollte, damit die ständig geladenen Seitenanteile nicht bei jedem Aufruf von der Platte gelesen werden müssen, ist hinfällig geworden: Nur 10% der gesamten Server-Bearbeitungszeit geht auf das Laden von Seiten zurück:

[PROFILING] => Array
(
[0] => Start
[1] => 0.0000: session.inc.php geladen (0.0000)
[2] => 0.0002: request.inc.php geladen (0.0002)
[3] => 0.0004: ssl.inc.php geladen (0.0002)
[4] => 0.0005: locale.inc.php geladen (0.0001)
[5] => 0.0009: sage.inc.php geladen (0.0004)
[6] => 0.0034: basic.inc.php geladen (0.0026)
[7] => 0.0036: waehrungen.inc.php geladen (0.0002)
[8] => 0.0040: db.inc.php geladen (0.0003)
[9] => 0.0043: db verbunden (0.0004)
[10] => 0.0043: Sortierung berechnet (0.0000)
[11] => 0.0066: konto.inc.php geladen (0.0023)
[12] => 0.0071: aktionen.inc.php geladen (0.0005)
[13] => 0.0074: menue_js.inc.php geladen (0.0003)
[14] => 0.0084: left.php geladen (0.0010)
[15] => 0.0084: goInsite(); (0.0000)
[16] => 0.0091: kategorie.inc.php geladen (0.0008)
[17] => 0.0096: Kopf ausgegeben (0.0005)
[18] => 0.4466: Artikel gefunden (0.4369)
[19] => 0.4471: Sortieren/Blaettern ausgegeben (0.0005)
[20] => 0.4521: Artikel ausgegeben (0.0050)
[21] => 0.4523: Blaettern ausgegeben (0.0001)
[22] => 0.4524: Entering _post.php (0.0001)
[23] => 0.4525: footer.inc.php geladen (0.0001)
[24] => 0.4584: right.inc.php geladen (0.0059)
[25] => 0.4600: menue.inc.php geladen (0.0016)
[26] => 0.4605: Seitenende (0.0005)
)

Hier sieht man schnell: von den 460 Millisekunden gehen 436 für die Artikelsuche in der Datenbank drauf.

Nach der Einführung von Indizes für einige Bereiche der Website und der Einführung eines Views für die Darstellung aller zur Zeit aktiven Artikel sieht das Ergebnis gleich ganz anders aus:

[PROFILING] => Array
(
[0] => Start
[1] => 0.0000: session.inc.php geladen (0.0000)
[2] => 0.0002: request.inc.php geladen (0.0002)
[3] => 0.0004: ssl.inc.php geladen (0.0002)
[4] => 0.0005: locale.inc.php geladen (0.0001)
[5] => 0.0009: sage.inc.php geladen (0.0004)
[6] => 0.0035: basic.inc.php geladen (0.0026)
[7] => 0.0037: waehrungen.inc.php geladen (0.0002)
[8] => 0.0040: db.inc.php geladen (0.0003)
[9] => 0.0044: db verbunden (0.0004)
[10] => 0.0044: Sortierung berechnet (0.0000)
[11] => 0.0067: konto.inc.php geladen (0.0023)
[12] => 0.0072: aktionen.inc.php geladen (0.0005)
[13] => 0.0074: menue_js.inc.php geladen (0.0003)
[14] => 0.0084: left.php geladen (0.0009)
[15] => 0.0088: goInsite(); (0.0004)
[16] => 0.0096: kategorie.inc.php geladen (0.0008)
[17] => 0.0102: Kopf ausgegeben (0.0006)
[18] => 0.0106: Artikel gefunden (0.0004)
[19] => 0.0111: Sortieren/Blaettern ausgegeben (0.0005)
[20] => 0.0142: Artikel ausgegeben (0.0031)
[21] => 0.0144: Blaettern ausgegeben (0.0001)
[22] => 0.0145: Entering _post.php (0.0001)
[23] => 0.0146: footer.inc.php geladen (0.0001)
[24] => 0.0205: right.inc.php geladen (0.0059)
[25] => 0.0236: menue.inc.php geladen (0.0031)
[26] => 0.0236: Seitenende (0.0000)
[max] => Array
(
[0] => 0.00587892532349
[1] => right.inc.php geladen
)
)

Und so wurden aus 461 ms 24 ms Gesamtladezeit.

Ich muss aber dazu sagen, dass die Einführung eines Views selbst zu keiner nennenswerten Performance-Steigerung führte. Die dabei gemessenen Ergebnisse sahen genauso, wenn nicht noch schlechter als die Abfrage der Originaltabelle aus. Erst die Indizes bringen die Performance, im obigen Beispiel ist dies immerhin eine Reduktion auf 5% der Original-Antwortzeit. Das eigentliche Problem, nämlich 1-2 Sekunden Rendering der Seite im IE7, ist damit (natürlich rein statistisch) auf 0.6-1.4 Sekunden geschrumpft. Dennoch werden wir hier nochmal ran, und diesmal den CSS-Code studieren müssen.

PS: Ich habe das View schließlich doch benutzt, damit mein Code einfacher und leichter wartbar wird. Eventuell werde ich den View noch auf die zur Artikelsuche relevanten Felder begrenzen, und die Messung damit wiederholen. Die großen Unterschiede wird es jedoch nicht mehr machen können. Und die Abweichungen jeder Messung sind augenscheinlich. Zweimal nacheinander eine ähnlich Abfrage bringt allein durch das Caching der Datenbank alle Ergebnisse durcheinander.

Im Firefox habe ich bisher nur kleine Macken entdeckt. Davon ist eine sehr witzig: In einem CSS-gesteuerten Popup-Menü hatten wir vier einfache Einträge, in einer geordneten Liste als einfaches a-href-Element. Immer wurde dieses Menü anders als alle anderen dargestellt: Der Rollover-Effekt klappte nicht, die li’s waren nicht so breit wie die Liste etc. Nachdem ich den (sehr einfachen) HTML-Code sehr lange intensiv studierte und nix, aber auch gar nix fand, habe ich die Elemente in der Reihenfolge getauscht, aber das brachte keinen Verbesserungseffekt. Schließlich benannte ich einen der Links einfach um – jetzt gehts.