[Bug] regenerate-token nutzt SERVER_URL statt #189-Transport-Auswahl → falsche URL für VPN-Nodes #193

New issue

Closed

opened 2026-06-26 18:52:13 +00:00 by chinux · 1 comment

chinux commented

2026-06-26 18:52:13 +00:00

Owner

Bug (Nachzügler zu #189)

regenerate_token (admin_router.py:649ff) baut die install_url aus dem globalen SERVER_URL (:663):

install_url = f"{SERVER_URL}/install/{raw_token}"

Das ignoriert die in #189 eingefuehrte Transport-Auswahl. Fuer einen VPN-Node liefert es damit die falsche URL (public/Default statt VPN-Adresse) → der erneute Install-Lauf landet im https-Pflicht-400er bzw. verbindet gegen die falsche Adresse. Praktisch reproduziert: VPN-Node ITD-PROX01, regenerate-token gibt eine nicht-VPN-URL aus.

Fix

Die Install-URL-Erzeugung muss dieselbe Auswahllogik nutzen wie der /install-Endpoint (main.py, #189):

node.vpn_transport == True → Basis = node.vpn_server_url falls gesetzt, sonst SERVER_URL_VPN.
sonst → SERVER_URL_PUBLIC (bzw. Legacy SERVER_URL).
Beide leer im VPN-Fall → 400 mit klarer Meldung (kein stilles Public-Fallback), wie im /install-Pfad.
Am besten die Auswahl in eine gemeinsame Helper-Funktion ziehen (z. B. resolve_install_base(node)) und an beiden Stellen (regenerate-token + /install) verwenden, damit sie nie wieder auseinanderlaufen.
curl_command in der Response entsprechend mit der korrekten Basis.

Akzeptanz

regenerate-token eines VPN-Nodes liefert eine install_url mit der VPN-Adresse (ws/http) + fuehrt zu TRUSTED_TRANSPORT=vpn.
regenerate-token eines public-Nodes liefert die Public-Domain (https).
VPN-Node ohne jede VPN-Adresse → 400.
/install und regenerate-token teilen denselben Helper.

Branch

fix/regenerate-token-vpn-url

## Bug (Nachzügler zu #189) `regenerate_token` (admin_router.py:649ff) baut die `install_url` aus dem globalen **`SERVER_URL`** (:663): ``` install_url = f"{SERVER_URL}/install/{raw_token}" ``` Das ignoriert die in #189 eingefuehrte Transport-Auswahl. Fuer einen **VPN-Node** liefert es damit die **falsche URL** (public/Default statt VPN-Adresse) → der erneute Install-Lauf landet im https-Pflicht-400er bzw. verbindet gegen die falsche Adresse. Praktisch reproduziert: VPN-Node ITD-PROX01, regenerate-token gibt eine nicht-VPN-URL aus. ## Fix Die Install-URL-Erzeugung muss **dieselbe Auswahllogik** nutzen wie der `/install`-Endpoint (main.py, #189): - `node.vpn_transport == True` → Basis = `node.vpn_server_url` falls gesetzt, sonst `SERVER_URL_VPN`. - sonst → `SERVER_URL_PUBLIC` (bzw. Legacy `SERVER_URL`). - Beide leer im VPN-Fall → 400 mit klarer Meldung (kein stilles Public-Fallback), wie im /install-Pfad. - Am besten die Auswahl in **eine gemeinsame Helper-Funktion** ziehen (z. B. `resolve_install_base(node)`) und an beiden Stellen (regenerate-token + /install) verwenden, damit sie nie wieder auseinanderlaufen. - `curl_command` in der Response entsprechend mit der korrekten Basis. ## Akzeptanz - regenerate-token eines VPN-Nodes liefert eine `install_url` mit der VPN-Adresse (ws/http) + fuehrt zu `TRUSTED_TRANSPORT=vpn`. - regenerate-token eines public-Nodes liefert die Public-Domain (https). - VPN-Node ohne jede VPN-Adresse → 400. - /install und regenerate-token teilen denselben Helper. ## Branch `fix/regenerate-token-vpn-url`

chinux added the

bug

label

2026-06-26 18:52:13 +00:00

chinux referenced this issue

2026-06-26 18:52:13 +00:00

[Frontend] UI-Knopf 'Token neu generieren' im Node-Aktions-Menü (Endpoint existiert, UI fehlt) #194

chinux referenced this issue from a commit

2026-06-26 19:00:53 +00:00

fix/feat: regenerate-token Transport-richtig (#193) + UI-Knopf "Token neu generieren" (#194)

chinux closed this issue

2026-06-26 19:00:53 +00:00