Panel klienta WaveHost

WaveHost ist ein Hosting-Anbieter, der einen einzigen Ort für seine Kunden brauchte: Sie bestellen einen Server, bezahlen, empfehlen weiter, alles aus demselben Panel. Dieser Teil allein ist handwerkliche Arbeit, die wir schon früher gemacht haben. Die eigentliche Herausforderung lag daneben: beim Anbieter lief bereits ein separates Game-Panel mit eigenen Konten, und diese beiden Welten mussten so verbunden werden, dass der Kunde ein System spürt und nicht zwei.

Am einfachsten wäre es, die Leute zweimal einloggen zu lassen und ein Konto von Hand per E-Mail zu verknüpfen. Das ist aber ein direkter Weg zu Fehlern, und beim Verknüpfen von Konten hat ein Fehler einen konkreten Preis: verknüpfen Sie jemandem ein fremdes Konto, haben Sie ein Problem, das sich mit einem gewöhnlichen Entschuldigung nicht rückgängig machen lässt. Wir wollten eine Verbindung, der man vertrauen kann. Diese Fallstudie handelt hauptsächlich von dieser Verbindung.

Das Fundament des Panels ist der Betrieb, zu dem der Kunde täglich zurückkehrt. Das Bestellen und Verwalten von Servern umfasst sowohl VPS als auch dedizierte Maschinen, mit ihrem Zustand und ihrer Konfiguration in einer Ansicht sichtbar. Der Kunde springt nicht zwischen Werkzeugen hin und her, um zu prüfen, was er hat und in welchem Zustand es ist.

Darum herum lebt der Rest des Betriebs. Wallet und Rechnungen liegen nebeneinander, sodass Saldo, Zahlungen und Dokumente ein Ganzes bilden und nicht drei getrennte Tabs, die man selbst in Einklang bringen muss. Das Empfehlungsprogramm fügt einen Empfehlungslink und einen klaren Provisionsfluss hinzu, eingebunden in dieselbe Wallet. Das Ganze steht auf einem modernen Stack mit sicherer Authentifizierung, denn das ist ein Panel, in dem Geld und Serverzugänge liegen.

Der Kern des Projekts ist die Verbindung des Kundenpanels mit dem bestehenden Game-Panel. Aus Sicht des Kunden ist das Problem zugleich banal und ärgerlich: zwei Konten, zwei Logins, zwei Welten, die ihn nicht interessieren, weil er einfach alles an einem Ort verwalten will. Aus ingenieurtechnischer Sicht ist genau das der Teil, in dem es leicht ist, etwas Gefährliches zu tun.

Die naive Lösung lautet: der Kunde gibt seinen Login aus dem Game-Panel an, und wir verknüpfen ihn. Das Problem ist, dass auf diese Weise jeder einen fremden Login angeben und sich an ein Konto hängen könnte, das ihm nicht gehört. Manuelles Verknüpfen per E-Mail ist langsam und genauso löchrig. Wir brauchten einen Weg, auf dem ein System dem anderen die Identität des Kunden beweist, ohne irgendetwas zu vertrauen, was durch den Browser geht.

Die Lösung ist ein auf HMAC basierender Handshake. Wenn der Kunde im WaveHost-Panel auf "Konto verknüpfen" klickt, erzeugt das Panel einen Link, der die Nutzer-id, einen Zeitstempel und eine mit einem Secret berechnete Signatur trägt, das nur die beiden Panels kennen. Das Game-Panel empfängt diesen Link, berechnet die Signatur mit seinem eigenen Secret neu und vergleicht. Stimmt sie überein, weiß es, dass die Anfrage wirklich aus dem WaveHost-Panel kam und nicht von jemandem, der die URL gefälscht hat.

Entscheidend ist, was der Browser nie sieht. Das Secret verlässt die Server nicht, also kann selbst jemand, der den Link mitliest oder abfängt, keine gültige Signatur für eine fremde id berechnen. Der Zeitstempel schließt die zweite Lücke: der Link ist kurzlebig, und ein abgelaufenes Token weist das Game-Panel einfach ab, sodass ein abgehörter Link später nicht mehr verwendet werden kann.

Es lohnt sich, das in Szenarien zu zerlegen, denn erst dann sieht man, dass der Komfort wirklich keine Sicherheit kostet. Jemand tauscht die id im Link gegen eine fremde aus, um sich an ein Konto zu hängen, das nicht seins ist. Die Signatur passt nicht mehr, weil sie für eine andere id berechnet wurde, und eine neue lässt sich ohne das Secret nicht erzeugen. Das Game-Panel weist die Anfrage ab.

Zweites Szenario: jemand fängt den gültigen Link eines Kunden ab und versucht, ihn zu verwenden. Hier rettet der Zeitstempel. Der Link lebt kurz, also ist er nach Ablauf schon wertlos, und das Game-Panel behandelt ein abgelaufenes Token genau wie ein gefälschtes. In beiden Fällen wird die Grenze auf der Serverseite geprüft, am Eingang, und nicht in der Oberfläche, die sich immer umgehen lässt.

Der Kunde führt den gesamten Betrieb von einem Ort aus. Er bestellt Server, verwaltet VPS und dedizierte Maschinen, bezahlt, empfiehlt weiter und behält die Wallet im Blick, ohne zwischen Werkzeugen zu springen. Die Verbindung zum Game-Panel funktioniert mit einem Klick statt über einen E-Mail-Austausch, sodass sich die beiden Systeme des Anbieters für den Kunden wie eines anfühlen.

Darunter ist dieser Komfort nicht mit Sicherheit erkauft, denn der Handshake ist kurzlebig und signiert und das Secret erreicht nie den Browser. Ein gefälschter oder abgefangener Link verknüpft kein fremdes Konto, weil der Server die Grenze am Eingang bewacht und nicht die Oberfläche. Das ist genau die Art Lösung, um die es im Projekt ging: einfach für den Kunden, hart dort, wo es hart sein muss.