Marke je HOST aufloesen — `GET /host/:host` neben `GET /slug/:reseller`
Auftrag 3 (Teil 1 von 2) des Briefes `white-label-anmelde-host-form-b-umsetzen`.
Befund der Messung vom 2026-08-19 (Station 8): die Anmelde-Oberflaeche loest ihre
Marke ausschliesslich aus dem PFAD auf (`/:reseller` -> `GET /slug/:reseller`),
und `aYOUneResellers.domain` wird von NIEMANDEM als Host-Zuordnung gelesen. Auf
einem eigenen Anmelde-Host (`login.kunde.de`) gibt es kein Pfad-Segment — der
Besucher landet auf der aYOUne-Marke, obwohl er die Domaene seines
Wiederverkaeufers aufgerufen hat.
Die neue Route ist das fehlende Gegenstueck, mit byte-gleicher Feld-Auswahl wie
`/slug/:reseller`, damit die Oberflaeche beide Wege gleich behandeln kann.
Oeffentlich gemountet wie `/slug` und aus demselben Grund: gefragt wird VOR jeder
Anmeldung, ausgeliefert wird nur, was ohnehin auf der Anmelde-Seite steht.
🔴 An den Freischalt-Schalter gebunden (CEO-Entscheid 3): der Filter verlangt
`platformHostEnabled: true`. Ohne die Bindung antwortete die Route auch fuer
Wiederverkaeufer, die lediglich eine Domaene EINGETRAGEN haben — und liefe damit
den beiden anderen Toren der Kette zuwider, die genau daran haengen.
Der Schalter steht IM Filter, nicht in einer Pruefung danach.
⚠ 404 statt 403 bei fehlender Freigabe: die Route ist oeffentlich, ein
unterscheidbarer Fehler waere eine Aufzaehlungs-Hilfe.
Die reine Regel liegt in `lib/platformHostLabels.ts`, nicht in der Route — sie ist
die probenfaehige Haelfte (die Test-Konfiguration deckt `src/lib/**`) und die
Haelfte, die spaeter in den Kern wandert.
🔴 DRITTE Kopie der Etiketten-Liste, bewusst benannt: dieselbe Liste steht in
`domain-worker/shared/hostRouting.ts` (welcher DIENST) und in
`auth/lib/platformHostOrigins.ts` (welche HERKUNFT). Drei Kopien einer Regel
laufen auseinander — dieselbe Erfahrung, die `MANUALLY_MANAGED_ZONES` in den Kern
gehoben hat. Der Hub ist als eigener Auftrag angemeldet.
🔴 LATENTER BEFUND, in einer Probe festgenagelt: mit `mongoose.set('strictQuery',
true)` faellt `platformHostEnabled` aus dem Filter, und die Route lieferte die
Marke JEDES Wiederverkaeufers mit passender Domaene aus — eine stille Weitung,
kein Fehler. Heute tritt das NICHT ein, und das ist gemessen statt angenommen:
Mongoose-8-Vorgabe ist `false`, und weder core noch models noch dieser Dienst
setzen die Option. Die Probe faellt, sobald das jemand aendert.
Proben: neue `lib/__tests__/platformHostLabels.test.ts`, Reihe 54/54 (vorher 45).
Sicherheits-Grenzen mit Umkehr- und Positiv-Kontrolle: unbekanntes Etikett,
zwei Ebenen tief, `login.de` (das sonst `de` als Kandidat ergaebe).
Befund der Messung vom 2026-08-19 (Station 8): die Anmelde-Oberflaeche loest ihre
Marke ausschliesslich aus dem PFAD auf (`/:reseller` -> `GET /slug/:reseller`),
und `aYOUneResellers.domain` wird von NIEMANDEM als Host-Zuordnung gelesen. Auf
einem eigenen Anmelde-Host (`login.kunde.de`) gibt es kein Pfad-Segment — der
Besucher landet auf der aYOUne-Marke, obwohl er die Domaene seines
Wiederverkaeufers aufgerufen hat.
Die neue Route ist das fehlende Gegenstueck, mit byte-gleicher Feld-Auswahl wie
`/slug/:reseller`, damit die Oberflaeche beide Wege gleich behandeln kann.
Oeffentlich gemountet wie `/slug` und aus demselben Grund: gefragt wird VOR jeder
Anmeldung, ausgeliefert wird nur, was ohnehin auf der Anmelde-Seite steht.
🔴 An den Freischalt-Schalter gebunden (CEO-Entscheid 3): der Filter verlangt
`platformHostEnabled: true`. Ohne die Bindung antwortete die Route auch fuer
Wiederverkaeufer, die lediglich eine Domaene EINGETRAGEN haben — und liefe damit
den beiden anderen Toren der Kette zuwider, die genau daran haengen.
Der Schalter steht IM Filter, nicht in einer Pruefung danach.
⚠ 404 statt 403 bei fehlender Freigabe: die Route ist oeffentlich, ein
unterscheidbarer Fehler waere eine Aufzaehlungs-Hilfe.
Die reine Regel liegt in `lib/platformHostLabels.ts`, nicht in der Route — sie ist
die probenfaehige Haelfte (die Test-Konfiguration deckt `src/lib/**`) und die
Haelfte, die spaeter in den Kern wandert.
🔴 DRITTE Kopie der Etiketten-Liste, bewusst benannt: dieselbe Liste steht in
`domain-worker/shared/hostRouting.ts` (welcher DIENST) und in
`auth/lib/platformHostOrigins.ts` (welche HERKUNFT). Drei Kopien einer Regel
laufen auseinander — dieselbe Erfahrung, die `MANUALLY_MANAGED_ZONES` in den Kern
gehoben hat. Der Hub ist als eigener Auftrag angemeldet.
🔴 LATENTER BEFUND, in einer Probe festgenagelt: mit `mongoose.set('strictQuery',
true)` faellt `platformHostEnabled` aus dem Filter, und die Route lieferte die
Marke JEDES Wiederverkaeufers mit passender Domaene aus — eine stille Weitung,
kein Fehler. Heute tritt das NICHT ein, und das ist gemessen statt angenommen:
Mongoose-8-Vorgabe ist `false`, und weder core noch models noch dieser Dienst
setzen die Option. Die Probe faellt, sobald das jemand aendert.
Proben: neue `lib/__tests__/platformHostLabels.test.ts`, Reihe 54/54 (vorher 45).
Sicherheits-Grenzen mit Umkehr- und Positiv-Kontrolle: unbekanntes Etikett,
zwei Ebenen tief, `login.de` (das sonst `de` als Kandidat ergaebe).