Sobald ein Client sich mit dem Server verbindet, schaut dieser nach, ob es bereits einen User mit dem selben Account eingeloggt ist. Falls nein, passiert nix weiter. Falls ja, sendet der Server dem alten Client eine “alive”-Nachricht und lässt den neuen Client erst einmal sich verbinden und wartet gleichzeitig auf die Antwortnachricht vom alten Client. Bekommt er eine, so kickt er den neuen User, da der User dann auf jedenfalls noch im Chat ist. Andernfalls kann man dann den alten Client kicken lassen.

Dieses Verfahren funktioniert sehr gut auf meinem Chat-Server. Um das Verfahren ebenfalls für Gäste, also User ohne festen Account einzusetzen, sollte man denen uniqueIDs vergeben, die als Flash Cookie browserübergreifend gespeichert werden. So kann man ebenfalls verhindern, dass User versuchen, durch Öffnen von verschiedenen Browsern mehrfach eine Verbindung aufzubauen.

Nach stundenlangem Testen, fand ich dann 2 Bedingungen, die erfüllt sein müssen, damit ExternalInterface in IE funktioniert.

1. Der Flash Film muss sichtbar sein. Es in einem verstecktem Div zu laden geht also nicht.
2. Es muss bereits vor dem onload Event geladen sein. Alle Flash Dateien, die danach geladen werden, können keine Funktionen mehr über ExternalInterface registrieren.

Es gibt außerdem noch ein Problem mit transparenten PNGs im IE 7. Ich hatte häßliche schwarze Hintergründe in einigen Bildern, wobei andere wieder gingen. Der Grund war wieder, dass die Bilder zuerst versteckt waren. Scheinbar kommt IE 7 mit versteckten Elementen überhaupt nicht klar.

<a href="http://www.junny.de/" rel="external">Junny's Blog</a>

Leute ohne Javascript oder Leute, die Javascript deaktiviert haben, sehen ganz normale Links, aber Leute mit Javascript bekommen einfach neue Fenster geöffnet. Das Script “Open In New Window” (oinw.js) gibt’s hier.

Einbinden kann man es ganz normal wie jede andere Javascript-Datei:

<script type="text/javascript" src="oinw.js"></script>

Da ich ja in letzter mit der Urania Webseite beschäftigt war und dazu noch mein neues WordPress Plugin qTranslate programmiert habe, hatte ich leider keine Zeit etwas zu posten. Sorry!

Man kommt normalerweise nicht in die schwarze Zone, aber manchmal schon. Und genau dann wird alles sehr anstrengend. Eine kleine Webseite kommt niemals von allein in die schwarze Zone, aber sobald man etwas auf den server macht. Das Hauptproblem besteht beim Speicherlimit. Wieso sagen sie dem viruellen Server, dass er mehr RAM hätte als er wirklich hat? Um es zum Absturz zu bringen sobald es mehr will als ich bezahlt habe?

Jedenfalls ist es eindeutig wieder Zeit für ein Rootserver. Ich hab mit meinem Kumpel Jonas gequatscht und wir entschieden uns für einen von Hetzner dieses mal. Hetzner bietet einen Athlon 3700+ mit 1 GB RAM und 2x 160GB Festplatten für nur € 49 im Monat an und das ohne einmalige Kosten. Traffic ist inklusive, das selbe gilt für 6 IPs! Also bestellte ich kurzerhand gestern einen. Mal schauen wann es verfügbar ist. Freue mich schon darauf, dass meine Webseiten wieder superschnell werden.

Da ich nicht von irgendwelchen Begrenzung seitens des Hoster beschränkt werden wollte, suchte ich also einen virtuellen Server. Um unnötigen Kosten vorzubeugen, wollte ich auch eine Traffic Flatrate. Mein persönlicher Limit war € 20 im Monat  für einen meinen Erwartungen entsprechendes Angebot. Ich fand nach einer kurzen Suche Keyweb, einer Hosting-Firma mit einem ziemlich veralterten, aber immer seriös aussehenden Seite. Sie boten zwei verschiedene Sorten von virtuellen Servern, eines heißt "VRS" und das andere "rootDS". Was ist also der Unterschied zwischen den beiden? Nun ja, bei rootDS wird einem eine CPU Geschwindigkeit garantiert, bei VRS nicht. Da Aber die rootDS Angebote erst bei € 25 anfingen, entschied ich mich für den "VRS Start" für € 13 im Monat. Dabei sind eine 10 Domain Plesk Lizenz, mindestens 256 MB RAM und 2 IPs inklusive. Perfekt, dachte ich, alles was ich brauche.

Ich bestellte es vor einer Woche und bekam es diesen Freitag, das ist drei Tage länger als die versprochene Lieferzeit. Hinzu kam, dass ich Keyweb mehrmals anrufen musste. Nach dem ersten Anruf jedoch war der Server innerhalb von 2 Tagen da, aber davor wurde mein Auftrag scheinbar gar nicht erst beachtet. Nachdem ich nun den Server hatte, fand ich heraus, dass es mit Plesk 8.01 lief, die schlecht möglichste Version von Plesk. Ich versuchte es zu updaten, aber das hat Plesk scheinbar total zerhauen und ließ sich nicht mehr starten. Ich wusste nicht wieso und probierte deshalb die "Reinstall VRS" Funktion von Virtuozzo. Eine schlechte Idee, wie es sich herausstellte. Es hat weder alle Daten gelöscht noch funktionierte die frische Neuinstallation. Ein Not-Ticket löste mein Problem aber innerhalb von 2 Stunden und das Samstag nachts um 1.

Nachdem der Server also nun lief, wollte ich alle meine Webseiten umziehen mit Plesk. Dies schlug aber immer wegen Speichermangels fehl. Wie kann das sein? Ich hatte nur Apache am laufen und das braucht keine 256 MB RAM. Ein Blick auf "top" zeigte mir, dass die System mit 2 GB RAM ausgerüstet sind. Da aber Virtuozzo die System deaktiviert sobald der RAM Verbrauch über 384 MB geht. Eine ziemlich dämliche Sache. Das System mit diversen anderen Prozessen schlucken einfach zu viel RAM weg, da die ja denken, dass noch haufenweise übrig ist (von den 2 GB). Eine Menge QoS Alerts in Virtuozzo zeigen, dass das System zwischen der gelben und grünen Zone pendelt. Die Dekomprimierung von Daten führt sofort in die schwarze Zone, wo Virtuozzo keine weiteren Speicheranforderungen mehr erlaubt. Das bringt wiederum andere Prozesse zum Abstruzt oder zum gefrieren, wobei das Gefrieren keinen RAM freigibt und damit das System dauerhaft in der schwarzen Zone lässt und das System damit wie bei einer DoS-Attacke lahmlegt.

Man merkt schnell, dass der "VRS Start" nicht wirklich nutzbar ist. Da aber Keyweb einen größeren virtuellen Server "VRS Premium" für € 20 im Monat anbietet, habe ich kurzerhand gewechselt. Ich will ja nicht, dass meine Webseiten bei ein paar gleichzeitigen Besuchern abschmiert. Das Upgrade war 10 Minuten nachdem ich es bestellt hatte auch schon aktiv. Ich muss sagen, dass die VRS scheinbar ziemlich schnell und stabil zu laufen und ich hoffe, dass ich auch keine weiteren Probleme damit haben werde.

Nach stundenlangem probieren und kämpfen (vorallem mit dem IE box model bug), fand ich endlich eine Möglichkeit dieses 2 Spalten Design mit Header und Footer in Firefox, Opera und Internet Explorer (5.5, 6.0 und 7.0) zum Laufen zu bekommen. Nun bin ich stolz das “W3C Valid XHTML 1.0 Transitional Logo” auf meiner Seite zu haben.
Nachdem ich das Design fertiggestellt habe, arbeite ich mich in Polygot rein. Es ist nicht sonderlich intuitiv, deshalb dauerte es auch ein Tag, die genaue Funktionsweise herauszufinden. Das Datum wurden nicht übersetzt und WordPress selbst hatte keinen Filter für “single_cat_title”, welches mein Design durcheinander brachte mit den langen Sprachtiteln. Ich musste mich also “durchhacken”. Jetzt ist nur noch die Übersetzung übrig. Da dies ein langwieriger Prozess ist, werde ich dies über Zeit machen. Wenn du also was findest, das noch nicht übersetzt ist, melde es mir bitte. Danke!

qin.at und qian.at

.at-Domains sind aus Österreich und ziemlich teuer, weshalb sie wahrscheinlich auch noch nicht registriert wurden. Aber dank eines Upgrades der Inklusivleistungen unseres Hosters bekam ich sie völlig kostenlos. Der normale Preis für eine .at-Domain liegt bei € 49,00 im Jahr zzgl. Einrichtungsgebühren. Nun ja, dort wirst du schon bald sachen über mich finden. Oder sollte sich sagen http://qian.at/neue.seite/basteln?

1. Moderation. Wenn man alle Kommentare erst liest und filtert, kann kein Spam durchsickern. Aber diese Methode hat einen gewaltigen Nachteil. Moderation braucht Zeit! Wenn man also zu beschäftigt ist, kommen keine Kommentare mehr online. Oder noch schlimmer, beim löschen der ganzen Spamnachrichten könnte man aus Versehen eine gute Nachricht löschen.
2. Grafische Prüfung. Viele große Seiten benutzen diese Methode. Sie zeigen einen Code in einem Bild ein und erwarten, dass der User diesen Code bestätigt. Da das Bild unleserlich für ein Bot ist, werden diese effektiv geblockt. Aber manchmal können diese Codes auch sehr anstrengend sein, da man sie öfters selbst nicht lesen kann.
3. Spamfilter. Wie bei Emails könnte man Spamfilter einsetzen. Aber mit Spamfilter kommt auch die Möglichkeit, gute Nachrichten zu löschen.
4. Netzwerkbasiertes filtern / Schwarze Listen. Einige Leute versuchen sich daran eine schwarze Liste mit IPs der Spammer zu erstellen. Diese Methode hat 2 wichtige Nachteile. Erstens ändert sich die IP der Spammer und zweitens lässt es immer erst den Spam durch, bevor er geblockt wird.
5. Prüfsummen. Damit diese Methode funktionieren kann, muss der User Javascript aktiviert haben. Wenn man ein Kommentar absendet, berechnet der Browser eine Prüfsumme für die Nachricht. Der Server prüft diese und schaltet die Nachricht frei, sofern der Code korrekt ist und löscht sie andernfalls. Diese Methode hat aber den Nachteil, dass Nutzer mit deaktiviertem Javascript keine Nachrichten mehr schreiben können.

Nichts davon passte mir wirklich, also überlegte ich herum und baute mir selbst eine Methode kombiniert aus 2 und 5. So funktioniert sie:

Der Server berechnet eine 3stellige Zahl und ein Bestätigungsfeld vor dem Kommentarfeld. Gleichzeitig versteckt er noch ein verstecktes Input-Feld mit dem Namen “code” welches die selbe dreistellige Nummer noch mal verschlüsselt auffindbar ist. Dies hört sich noch sehr nach Methode 2 an. Nun kommt der neue Teil. Als nächstes füge ich ein Javascript hinter dem Kommentarfeld. Das Javascript liest und entschlüsselt die Zahl und füllt sie für den Nutzer ein. Daraufhin versteckt es den Code und das Bestätigungsfeld, sodass der Nutzer weder den Code sieht, noch weiß, dass er einen Code bestätigen musste sofern er Javascript aktiviert hat. Dies blockiert effektiv alle Spammer ab, die Javascript deaktiviert haben. Javascript ist langsam und würde Spammern viel Zeit kosten, wenn sie es berücksichtigen müssten. Deshalb schalten sie es aus. Aber sobald es aus ist, müssen sie den Code bestätigen, was deren Bot natürlich nicht kann. So bleibt also der Spam draußen.

Diese Methode ist nicht perfekt, da es manuell geschriebenes Spam durchlässt, aber es wird keinesfalls gute Nachrichten blockieren. Der Vorteil ist aber, dass Javascript Nutzer es komfortabel nutzen können ohne jegliche lästige Bestätigung von irgendwelchen Codes.