modale Fenster

[1unitedpower]

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.

Ich glaube, ich verstehe worauf du hinaus möchtest. Der Event-Handling-Mechanismus mit addEventListener macht den Fall aufwendiger einen Event-Handler auszutauschen, er macht es aber auch einfacherer einen Event-Handler hinzuzufügen. Traditionell unterstüzt das DOM daher auch zwei verschiedene Event-Handling-Mechanismen: Den klassischen mit oncancel und den modernen mit addEventListener (Beispiel). Deine Variante mit setCallback entspricht in etwa dem klassischen System.

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.

Ja, das halte ich ebefalls für gut.

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.

Ich möchte mal versuchen von den absoluten Begrifflichkeiten "sicher" und "unsicher" wegzukommen. Grundsätzlich unterliegen Software-Lösungen Unsicherheiten (im Sinne des englischen Uncertainty, nicht im Sinne von Insecurity). Die Risiken, die mit solchen Ungewissheiten einhergehen, lassen sich durch vielfältige Maßnahmen minimieren. Je mehr und je sorgfältiger diese Risiko-Minimierung betrieben wird, desto höher ist der Konfidenz-Level, dass sich das System zuverlässig verhält. Im Umkehrschluss gilt, wenn man nur wenig Risiko-Minimierung betreibt, besteht eine hohe Ungewissheit bzgl. der Zuverlässigkeit des Systems.

Jetzt gibt es mehrere Ebenen, auf denen man diese Risko-Mimimierung betreiben kann. Die erste Ebene betrifft den Entwickler persönlich, seine Qualifikation, seine Selbstreflexion, -kontrolle und Coding-Disziplin. Dieser Faktor ist von außen nur schwer mittelbar, es gibt aber Alarmsignale, z.B. wenn der Entwickler versucht sich durch überhöhte Statements, wie "mein Code ist noch nie gehackt worden" oder "mein System ist viel sicherer als Wordpress", Geltung zu verschaffen.

Die zweite Ebene betrifft die Einbeziehung und die Kommunikation mit Dritten. Ein klassisches Medium für diese Kommunikation ist der Code-Review, davon habe ich ein paar zu dem genannten Artikel geschrieben. Die sind allerdings nicht gut aufgenommen worden, zum Teil habe ich das auch selbst zu zuverschulden, indem ich damals nicht die richtige Tonart gewählt habe. Das Gegenteil von gut ist "gut gemeint".

Die dritte Ebene befasst sich mit technischen Maßnahmen zur Qualitätssicherung. Darunter fallen automatisierte Tests, statische Analyseverfahren und Programm-Verfikation. Um diese Verfahren zu ermöglichen, muss der Code aber bereits bestimmte Hygiene-Vorschriften erfüllen, die damals nicht gegeben waren. Ein Teil meiner Kritik damals bezog sich vor allem auch darauf, dass nicht einmal die Grundvoraussetzungen bestehen, um technsiche QS-Maßnahmen zu ergreifen unabhängig davon, ob sie denn nun wirklich ergriffen werden.

Zusammenfassend, ist es uns also nicht gelungen den Konfidenz-Level in die Vertrauenswürdigkeit des Login-Systems zu erhöhen, und inhaltlich stelle ich mich deshalb auch heute wieder auf den Punkt, dass es eine Fahrlässigkeit gewesen wäre, den Artikel unserer Leserschaft weiter anzubieten.

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.

Auf drei konkrete Sicherheitslücken haben ich ja in meinem vorherigen Posting verlinkt.

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).

Zum Beispiel mit eris, das ist eine Erweiterung für PHPUnit für generatives Testen.