Am 1. April begann der Anmeldezeitraum für die diesjährige BOM und damit auch der erste Praxiseinsatz von Version 0.5.0 von Convention. Die ersten Eindrücke sahen hier auch sehr gut aus, bis auf eine etwas besondere Problematik, welche nun doch noch eine Zwischenversion (v0.5.1) mit sich bringt.
Das Stichwort für besagte Problematik heißt WebSockets. Eine seit knapp 15 Jahren (in Sachen Internet also quasi steinalt) vorhandene Technologie, welche im heutigen Internet nicht mehr wegzudenken ist, selbst die letzte Version des allseits verhassten Internet Explorers unterstützt sie. Anders als das HTTP-Protokoll sind Verbindungen bei WebSockets nicht zustandslos und in beide Richtungen offen. Ein klassischer Einsatzzweck sind zum Beispiel Validierungen in einem Formular auf einer Website: Noch während man das Passwortfeld für den neuen Account ausfüllt, kriegt man eine Rückmeldung, wie sicher das gewählte Passwort ist. Häufig findet genau so eine Kommunikation zwischen Webbrowser und Server über WebSockets statt. Convention setzt im Backend ebenfalls WebSockets für verschiedenste Zwecke ein. Tatsächlich ist eine Nutzung des Backends im Browser nur dann möglich, wenn die Verbindung über WebSockets funktioniert. Und genau hier sind wir beim Problem…
In den vergangenen 2 Jahren ist die Südwestfalen-IT (kurz SIT) durch diverse Cybersicherheitsproblematiken aufgefallen. Über teils Monate lagen weite Teile der kommunalen IT in Südwestfalen lahm oder waren nur in Teilen nutzbar. Inzwischen sind die allermeisten Probleme behoben, jedoch mit einem entscheidenden Punkt: Man ist offenbar der Ansicht, WebSockets seien ein generelles Sicherheitsrisiko. Mit der Folge, dass diese innerhalb der Netzwerke der SIT gänzlich blockiert werden. Über weitere Hintergründe kann ich nur mutmaßen, die mir aus Nachfrage genannte Begründung bzgl. Sicherheit ist jedoch mehr als fraglich.
Soweit so gut, leider sind neben Teilen des BOM-Orgateams auch einige Aussteller auf der BOM kommunal (zB Stadtverwaltungen, Schulen, …). Als nun diese Anfang April versuchten, ihren Betrieb für die BOM 2025 anzumelden, trat genau das ein, was man jetzt vermuten könnte: Die Seite lud nicht korrekt, da eben besagte Verbindung über WebSockets nicht aufgebaut werden konnte. Entsprechend war für diese Betriebe keine Anmeldung für die BOM möglich.
Nach einer ersten Analyse dieser Problematik ergaben sich mehrere Lösungsansätze: Am technologisch sinnvollsten wäre sicherlich eine Art Whitelisting seitens der SIT für die BOM gewesen, sprich eine Freigabe dieser spezifischen Website für WebSockets. Leider war dies für die SIT keine Option. Ob dieser Weg überhaupt auf technischer Seite für die SIT möglich gewesen wäre, kann ich ebenso nicht beurteilen. Eine weitere Lösung wäre ein Verzicht auf WebSockets in Convention gewesen. Jedoch würde dies einerseits einen großen Zeitverlust bedeuten, da Teile von Convention umgeschrieben werden müssten, andererseits würde ein gewisser Funktionsumfang verloren gehen. Diese Art von beidseitiger Kommunikation ist ja an dieser Stelle kein Bug, sondern ein Feature. Was also tun? Die Anmeldung zur BOM lief ja schon…
„Moment!“, mag sich einer fragen, der in einem sehr restriktiven Netzwerk schon einmal arbeiten musste, „ich hab aber doch sehr wohl eine Live-Passwortvalidierung gehabt bei Seite XYZ“. Und genau hier sind wir bei der letztlichen Lösung, bzw. Notlösung. Genau für solche Fälle gibt es (noch aus Zeiten als WebSockets relativ neu und noch nicht in allen Bereichen unterstützt wurden) eine Alternative: LongPolling. Ein auf HTTP aufsetzender Weg, welcher eine Art beidseitige Kommunikation zumindest rudimentär ermöglicht. Genauere Details lasse ich an dieser Stelle einmal aus, es sei jedoch gesagt, dass LongPolling allgemein eher eine Art Notlösung sein sollte und im Zweifel immer WebSockets der Vorrang gewährt werden sollte. Das unter Convention liegende Phoenix Framework bietet hier genau eine solche Notlösung an: Es wird eine Kommunikation über WebSockets probiert, klappt dies jedoch nicht, wird auf LongPolling zurückgegriffen. Ich hatte (dummerweise) genau diesen Mechanismus nur für Convention deaktiviert, auch weil es bis dato keinerlei Probleme mit WebSockets in der Nutzung von Convention gegeben hatte.
Man mag es schon vermuten: Convention v0.5.1 aktiviert wieder genau diese Notlösung. Es ist folglich also auch Betrieben, welche die SIT als Dienstleister nutzen, möglich, Convention zu nutzen. Einen Vorteil hatte das Ganze letztlich doch noch: Ich konnte in dieser Zwischenversion 2-3 kleine Verbesserungen im Anmeldeprozess unterbringen, welche sonst erst mit Version 0.6.0 im Juni gekommen wären.
Was lernt man nun daraus? Man sollte im Zweifel lieber doch noch mit Besonderheiten und dem Unerwarteten rechnen.
Ich danke an dieser Stelle dem BOM-Orgateam, welches immer wieder Testpersonen für die Nachstellung dieser Problematik und der dann umgesetzten Lösung sein musste, da ich selbst keinen Zugang zum Netzwerk der SIT habe.