Gerade bemerkte ich eine Lustige Angewohnheit der Auth-Component von CakePHP.
Nehmen wir an wir haben eine Userregistration, also mit Feldern wie Username, Password, E-Mail usw. nun trägt der User alles richtig ein, nur bei der E-Mail vertippt er sich bzw. trägt dort keine valide Mailadresse ein. Da ich natürlich in CakePHP auf das Feld eine ValidationRule gelegt habe die besagt das in das Feld nur valide Mailadressen eingetragen werden dürfen schlägt Cake Alarm und quittiert den Versuch mit einer Fehlermeldung.
Da Cake schlau ist füllt es alle Felder automatisch mit den zuvor eingegebenen Werten wieder aus, damit man auch wirklich nur das fehlerhafte Feld neu bestücken muss. Das lustige ist jedoch das die Auth-Component in das Passwort-Feld bereits den MD5-Hash als value übergibt. Merkt man das nicht und korrigiert nur das eigentlich fehlerhafte Feld, so wird der MD5-Hash nochmal in einen MD5-Hash verwandelt und man kann sich somit nicht mit dem angelegten Account einloggen. Für mich ist das ein klarer Bug, denn die Auth-Component sollte natürlich prüfen ob die Validierung einen Alarm ausgelöst hat, und nur falls alles Ok ist sollte der Wert in MD5 umgewandelt werden.
Im IRC-Channel zu CakePHP wurde mir nun gesagt ich solle doch einfach das Passwordfeld generell leer halten, denn das sei schließlich vollkommen normal das man bei einem Validierungsfehler auch die Passwörter nocheinmal eintragen müsse. Ja klar, das machen zwar einige Portale so, doch mich persönlich nervt das einfach gewaltig.
Sicherlich ist es unsicher das Passwort in das value zu setzen, doch ist sowas doch bei einer Adminoberfläche die nur 2-3 Personen nutzen zu vernachlässigen. Warum wird da ein offensichtlicher Bug also so bekämpft?
Eine Lösung habe ich dafür leider nicht, außer dem Feld dauerhaft ein value="" mit auf den Weg zu geben, damit eben das Feld bei einer Falscheingabe statt dem MD5-Hash wenigsten nichts beinhaltet und somit wieder Alarm schlägt falls man es versehentlich leer lässt.
Wie seht ihr das? Sollte man ein Passwordfeld bei einer Fehlerausgabe wieder mit dem Eingabewert befüllen oder den Nutzer nochmals dazu auffordern sein Passwort einzugeben, obwohl es ja eigentlich die Validierung absolviert hat?
Der Arne hatte heute ein Problem mit der Darstellung von animierten PNG-Grafiken mit Alphatransparenz im Internet Explorer 7.
Dieses Problem lief mir soweit ich mich erinnern kann bereits vor über einem Jahr im Zuge einer kleinen Webanwendung über den Weg, und da die Aufklärung darüber wohl noch nicht so weit her ist, will ich das hiermit mal schnell nachholen.
Wer ist für Überstunden, Haarausfall, Ratlosigkeit und Unproduktivität in unserer Branche verantwortlich? Richtig: Der Internet Explorer.
Nun ist bei David eine kleine Diskussion entbrannt, die sich darum dreht, in wie weit man heute bei der Umsetzung von Webseiten den Internet Explorer unter Version 7 unterstützen sollte.
Meine Meinung: Für Webseiten mit geschäftlichem Hintergrund, bei der es auf jeden Besucher ankommt, ist eine Optimierung für den Internet Explorer ohne zweifel notwendig, bei meiner Arbeit sogar teilweise noch für den IE5… je nach Zielgruppe.
Auf der anderen Seite sehe ich jedoch, das es wohl keinen anderen Weg mehr gibt die Nutzer zumindest zu einem Update auf den Internet Explorer 7 zu bewegen, als diese ganz einfach zu zwingen. Was helfen kleine Hinweise wie “Sie setzen einen veralteten Webbrowser ein, bitte aktualisieren Sie auf eine aktuelle Version”, wenn der Nutzer am anderen Ende eh alles auf der Seite ansehen kann? User sind Faul und niemanden interessiert solch ein Hinweis, solange nicht drastische Nachteile für Ihn dadurch entstehen.
Meine Gebete wurden erhört, nur leider habe ich das wohl zu spät mitbekommen.
Gerade eben habe ich die DebugBar für den Internet Explorer entdeckt. Das ist für mich schon fast eine kleine Sensation! Die DebugBar sieht auf den ersten Blick so aus wie der kleine Bruder von Firebug, einer Extension die wohl kein Webentwickler mehr missen möchte.
DebugBar bildet nun die annähernd gleichen Funktionalität auch für den Internet Explorer ab. Man kann die einzelnen DOM-Elemente per Drag & Drop aktivieren oder durchklicken, sich deren (vom IE “interpretierten”) CSS-Eigenschaften ansehen, einzelne Elemente wie Bilder, Formulare und Links auflisten lassen, AJAX-Calls verfolgen, JavaScript-Funktionen einsehen und selbst das (X)HTML lässt sich on-the-fly validieren. Ein ebenfalls nettes Feature ist die grafische Darstellung des (meist kaputten) Boxmodels, also der width/height, padding, border und margins.
Ich denke das kann doch ein großer Schritt in Sachen Bug-Bekämpfung des IE sein. Zwar werden wir in einigen Fällen wohl um unsere Hacks nicht herum kommen, doch das “WARUM, WARUM VERDAMMT!!!” klärt sich vielleicht doch etwas schneller als bisher.
Mir ist zudem aufgefallen das sich die Toolbar wunderbar mit MultipleIE zu verstehen scheint, man kann sie also beim Debuggen auf einem System sowohl im IE6 als auch IE7 zeitgleich verwenden.
Doch aufgepasst, solltet ihr DebugBar für kommerzielle Projekte benutzen wollen, so wird eine Gebühr von 59$ für eine Single-User-License fällig. Für private Geschichten ist die nutzung der Software jedoch kostenlos.
Wir wissen gerade nicht wirklich woran es liegt, aber Patrick hatte gestern unseren VPS auf PHP 5.2.4 aktualisiert, seit dem kam es bei allen fast allen Seiten zu Problemen die wir aber irgendwie nicht genau lokalisieren konnten.
Wie ihr vielleicht mitbekommen habt wurde den ganzen Vormittag der Blog ohne CSS ausgegeben und auch die URLs mittels mod_rewrite liefen nicht mehr, und das obwohl Patrick den Apache gar nicht angefasst hatte. Auch einige CakePHP-Projekte die sich gerade in der Entwicklung befanden hatten keine Probleme, andere die jedoch gerade Produktiv arbeiten schon. Der Output war auch extrem seltsam. Mal erschien unter hackthenet.de das Textpattern-Fenster, mal wieder der Blog und umgekehrt, also seeeehr merkwürdig.
Wir haben nun hin und her überlegt wo der Fehler liegen könnte und haben dann Probehalber mal APC deaktiviert, und siehe da: Alle Seiten liefen wieder, und auch die mod_rewrite-Seiten kamen zurück.
Wir wissen gerade immer noch nicht woran es jetzt liegt, denn APC ist ebenfalls auf dem neusten Stand. Und warum laufen einige Seiten und andere nicht? Eine CakePHP 1.1 Version lief ohne Fehler, eine andere wieder nicht… sehr merkwürdig das ganze.
Solange wir den wirklichen Ursprung des Fehler nicht ausfindig machen können muss wohl erstmal APC deaktiviert bleiben. Da der Server aber derzeit nicht wirklich unter Last steht ist das kein großes Problem.
Mal sehen ob wir da nicht auch einfach auf einen bisher unbekannten Bug gestoßen sind.
Update:
Es scheint so als Wenn APC in der aktuellsten Version einige Fehler im Umgang mit mod_rewrite-URLs aufweist. Der Fehler scheint auch schon bekannt zu sein, wurde bisher aber anscheinend noch nicht gefixt. Seltsam ist, das der Fehler anscheinend nur in Verbindung mit PHP 5.2.4 auftritt, ein Downgrade auf PHP 5.2.3 “löste” unser Problem erstmal.
Wie ich ja bereits oft verkündet habe bin ich ein absoluter Fan von Googlemail (kurz GMail). Es ist einfach mein zentrales Office. Immer hat man Backups seiner E-Mails parat, auch wenn man gerade mal 3000Km entfernt eine Info benötigt.
Was mich jedoch seit einiger Zeit tierisch nervt ist der doch immer aggressivere Spamfilter von Gmail, das geht nun sogar schon so weit das mir dadurch wahrscheinlich schon einige Anfragen von potentiellen Kunden durch die Lappen gegangen sind, da diese im Wust der Spammails (immerhin ca. 600/Tag) einfach verloren gehen.
Nun sagt GMail eigentlich, das die Hauseigene Kontaktliste gleichzeitig eine Whitelist darstellt, dem ist aber oftmals nicht so. In letzter Zeit verschlingt GMail sogar Mails von Kontakten die ich schon lange in der Kontaktliste habe. Sogar manche Benachrichtigungsmails zu den Kommentaren werden geschluckt, aber eben nur manche. Viele Mails haben zudem einen ganz normalen Aufbau, kein Viagra, keine Monstergenitalien… einfach sachlicher Text.
Das verhalten des Spamfilters ist für mich nicht wirklich verständlich. Bei festen Adressen usw. konnte ich mir bisher oftmals über manuelle Filter helfen, aber auf Dauer ist das auch keine Lösung.
Ich möchte GMail nicht missen, aber da mir ein kaputtes Postfach im Prinzip mein Geschäft vermiesen könnte (z.B. wenn nur jede dritte Anfrage durchkommt) muss ich wohl doch wieder auf unseren eigenen POP3-Umziehen. Lieber umständlich als auftragslos.
Als ich vor einiger Zeit begann das PNG-Format für mich zu entdecken, machte sich auch sehr schnell Ernüchterung bei mir breit.
Der Grund dafür war, dass der Internet Explorer in all seinen Version ein Problem mit den Gammawarten von PNG-Grafiken hat. Im Resultat macht sich das in sofern bemerkbar, dass der IE in der Regel alle PNG-Grafiken ein wenig dunkler darstellt als es z.B. Opera und Firefox tuen.
Das machte sich bei der Anwendungen von PNG-Grafiken in sofern schlecht, da die Grafiken sich oft von ihrer eigentlichen Hintergrundfarbe abheben, und man somit im Prinzip eine gesonderte CSS-Datei für den IE anlegen müsste.
Doch dieser Spuk ist nun endlich vorbei. Des Rätzels Lösung ist das kleine aber durchaus feine OpenSource-Tool TweakPNG. TweakPNG kann verschiedene Default-Werte von PNG-Grafiken modifizieren, hinzufügen oder löschen. Somit lässt sich z.B. die Standardhintergrundfarbe für Browser ohne Alpha-Kanal festlegen u.v.m.
Für das fixen des Bugs ist jedoch im besonderen der Wert “gAMA” wichtig. Öffnet man eine PNG-Datei mit TweakPNG, löscht die Chunk-Zeile “gAMA” und speichert die Datei wieder, so lässt sich beobachten, dass die PNG-Grafik fortan in allen Browsern identisch ausgegeben wird.
Wahrscheinlich für viele ein alter Hut, ich wollte es den Unwissenden unter euch aber dennoch nicht vorenthalten.
P.s.: Ein sehr guter Hack um dem IE6 ebenfalls den Umgang mit einem Alpha-Kanal beizubringen, findet sich in diesem Tutorial.
