URL-Shortener im Durchgang: Schlüsselerzeugung, Weiterleitungsstatus und Missbrauchskontrollen

Ziel

Eine lange URL in einen kurzen Schlüssel verwandeln, der zuverlässig weiterleitet, abgeschaltet werden kann und nicht zu einem offenen Relais für Missbrauch wird.

Voraussetzungen

Eine Entscheidung darüber, wer Links erstellen darf (authentifizierte Nutzer, oder anonym mit Beschränkungen) und ob sich ein Ziel nach der Erstellung ändern darf.

Schritte

1. Randbedingungen: Weiterleitungen müssen schnell und verfügbar bleiben, auch wenn die Erstellung ausfällt; Schlüssel müssen kurz, aber nicht massenhaft aufzählbar sein; jeder Link muss widerrufbar sein. Entscheiden, ob Klicks gezählt werden.
2. Komponenten: eine Erstellungs-API; ein Schlüsselspeicher; ein Weiterleitungs-Handler hinter einem Cache; eine Missbrauchsprüfung bei der Erstellung (Schema beschränkt auf http und https, Ziel löst zu einer öffentlichen Adresse auf, Sperrlisten-Abfrage); ein Admin-Pfad, der einen Schlüssel deaktiviert und den Cache leert.
3. Datenmodell: link(key, target, owner, created_at, expires_at, disabled_at) mit Primärindex auf key und Sekundärindex auf owner; optional click(key, at, referrer_class), asynchron aus dem Weiterleitungspfad geschrieben.
4. Schlüsselerzeugung: zufälliges Base62 fester Länge, mit Wiederholung bei Kollision (sieben Zeichen ergeben 62^7, etwa 3,5 Billionen Schlüssel); ein in Base62 kodierter Zähler ist kürzer, erlaubt aber jedem, alle Links durchzugehen. Benutzerdefinierte Aliase leben in einem separaten Namensraum mit strengerem Zeichensatz und einer Prüfung auf Identitätsmissbrauch.
5. Weiterleitungsstatus: RFC 9110 definiert 301 (Moved Permanently) so, dass es dem Client mitteilt, künftige Verweise sollten die neue URI verwenden, während 302 (Found) besagt, der Client solle weiterhin die ursprüngliche URI verwenden. Eine permanente Weiterleitung kann daher von Clients gemerkt werden und den Dienst umgehen; deshalb 302 oder 307 verwenden, wann immer Zählungen oder Widerrufbarkeit wichtig sind, und 301 nur für Links, die sich nie ändern. Cache-Control: no-store ergänzen, wenn Klicks gezählt werden.
6. Fehlerfälle: Cache liefert einen deaktivierten Link aus (bei Deaktivierung invalidieren, kurze TTL als Rückfallebene); Speicherausfall (eine Lese-Replika oder ein Edge-Cache liefert veraltete Einträge); Phishing-Ziele (Meldeendpunkt, Reputationsabfrage, Erstellungslimits pro Besitzer); Schleifen zurück auf die eigene Domain des Shorteners (bei der Erstellung ablehnen); Aufzählung (zufällige Schlüssel, einheitliche 404-Antworten, Ratenbegrenzung bei Abfragen).
7. Messen: Weiterleitungslatenz am oberen Rand, Cache-Trefferquote, 404-Rate als Signal für Aufzählungsversuche, Erstellungen pro Besitzer und Stunde, deaktivierte Links pro Tag, Zeit von der Missbrauchsmeldung bis zur Deaktivierung.
8. Nicht zuerst: Analyse-Dashboards, eigene Domains, QR-Codes, Linkvorschauen, aufgeteilte Ziele, API-Schlüssel für Massenerstellung.

Erwartetes Ergebnis

Eine Weiterleitung berührt höchstens einen Cache und einen Speicher, ein Link kann innerhalb von Sekunden abgeschaltet werden, und Missbrauch wird durch Erstellungslimits begrenzt statt durch manuelle Prüfung.

Grenzen und Prüfbasis

Vorgeschlagener Entwurf, keine Messungen. Die Wahl zwischen 301 und 302 lässt sich kaum rückgängig machen, sobald Clients permanente Weiterleitungen gecacht haben, daher sollte sie vor dem Launch getroffen werden.