modale Fenster

[Felix Riesterer]

Lieber 1unitedpower,

vielen Dank für die ausführliche Rückmeldung. Jetzt kann ich mit Deinen Kritikpunkten umgehen.

Vorschlag zur Güte: Du hast ja selber vorgeschlagen den Artikel aufzuteilen, ich glaube das Polyfill wäre eine sinnvolle Schnittmarke und könnte in einem eigenen Artikel untergebracht werden.

@Matthias Scharwies und ich arbeiten an einer solchen Aufteilung. Und ja, die Sache mit dem Polyfill verdient dabei eine ganze eigene Sektion.

Außerdem möchte ich vorschlagen, statt setCallback das native Event-System mit addEventListener zu benutzen. Die Spec definiert für das dialog-Element zwei mögliche Events: close und cancel.

Auf den ersten Blick klingt das überzeugend. Aber wenn ich etwas mehr darüber nachdenke, dann habe ich folgenden Zweifel:

EventListener kann man an Elemente binden und wieder lösen. Wenn ich nun eine Funktion für das cancel-Event anbinde, muss ich die später wieder lösen, sonst wird sie bei Wiederbenutzung der Dialog-Box erneut ausgeführt, was ich ja nicht will, wenn diese Funktionalität dynamisch übertragen werden soll.

Auf der aufrufenden Seite, muss der Aufruf dialog.setCallback('cancel', fn) durch dialog.addEventListener('cancel', fn) getauscht werden.

Dann verwaltet also nicht meine setCallback-Methode, welche Funktion gerade an das cancel-Event gebunden ist, sondern das DOM selbst. Das ist unhandlicher, denn ich müsste ja nach der Ausführung des Events den EventListener wieder entfernen. So habe ich diesen einmal eingerichtet, aber was er jeweils tut, regelt meine Komfort-Funktion, die das einfach in einer lokalen Variable (Closure) verwaltet.

Ich könnte mir also vorstellen, für die beiden Events close und cancel jeweils einen EventListener anzubinden, der meine Komfort-Funktion bedient, damit auf der einen Seite weiterhin das Handling der Callback-Funktionen so einfach geregelt werden kann, aber auf der anderen Seite die (geplanten) nativen Merkmale im Sinne eines Polyfills unterstützt werden.

Dass meine Kritik [am Login-System] zu vage war, weise ich allerdings zurück. Ich habe mich regelmäßig an den Diskussionen um den Artikel beteiligt, dabei habe ich auf mehrere konkrete Sicherheitslücken hingewiesen.

Ich erinnere mich nur noch an eine Sache wirklich konkret, nämlich an einen Vorwurf, dass die ganze Sache für eine Veröffentlichung im Wiki deshalb zu unsicher und daher löschungswürdig sei, weil es keine automatisierten Tests gäbe. In dieser vagen und absoluten Form habe ich das in Erinnerung. Mag sein, dass die mittlerweile sehr gelitten hat und sich im Nachhinein manche Dinge in die eine oder andere Richtung verklärt haben, aber genau hierin hat mich Deine hiesige Kritik an den damaligen Vorgang erinnert.

Darüber hinaus habe ich mehrfach und ausführlich die schlechte Lesbarkeit des Codes und die Abwesenheit von Qualitätssicherungs-Maßnahmen bemängelt.

Richtig. Aber ein reines Bemängeln der Abwesenheit von QA-Maßnahmen ist das eine. Die Schlussfolgerung, dass daraus prinzipiell eine Unsicherheit des Systems abzuleiten sei, die eine Löschung aus dem Wiki nach sich zieht, ist eine ganz andere Form von Kritik. Mir ist nicht bekannt, dass Du eine konkrete Sicherheitslücke damals hättest benennen können, sondern nur allgemein auf eben diese Abwesenheit von automatisierten Tests als Begründung verwiesen hattest.

Gerade bei solchen sicherheitsrelevanten Dingen können automatisierte Tests ja auch nur das testen, was der Testersteller im Sinn hat. Für den Login-System-Artikel hätte es einen regelrechten Fuzzer gebraucht, von dem ich nicht einmal im Ansatz wüsste, wie man so etwas erstellt. Aus meiner Sicht heute ging Dein Bemängeln damals also sogar nicht weit genug (Test vs. Fuzzer). Aber deshalb im Umkehrschluss zu behaupten, dass ein Login-Script deswegen unsicher sei, und vor allem, dass deshalb eine Veröffentlichung im Wiki insgesamt schadhaft wäre, wage ich bis heute nicht.

Liebe Grüße

Felix Riesterer