chinux/theProx
0
0
Fork 0
Code Issues 40 Pull requests Projects Releases Packages Wiki Activity Actions

[HIGH] regenerate-token erzeugt install_url aus SERVER_URL statt VPN-Pfad — #189-Nachzügler (VPN-Node bricht) #191

New issue
Closed
opened 2026-06-26 18:51:14 +00:00 by chinux · 4 comments
chinux commented 2026-06-26 18:51:14 +00:00
Owner
Copy link

Bug (Nachzügler zu #189) — HIGH, blockiert VPN-Node-Re-Enrollment

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

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

Das ignoriert die in #189 eingefuehrte Transport-Auswahl. Fuer einen VPN-Node wird so die Public-/Default-Adresse ausgegeben → der anschliessende Install-Abruf laeuft in den https-Pflicht-400er (#113 Phase 1) bzw. der Agent bekommt die falsche SERVER_URL und scheitert am Transport (real beobachtet bei ITD-PROX01: connect_async failed ws://… + Dauer-Retry).

Fix

  • Die install_url-Erzeugung in regenerate_token muss dieselbe Auswahllogik nutzen wie der /install-Endpoint (#189):
    • node.vpn_transport True → Basis = node.vpn_server_url sonst SERVER_URL_VPN (→ ws/http, TRUSTED_TRANSPORT=vpn im Script).
    • sonst → SERVER_URL_PUBLIC (→ wss/https).
    • beide VPN-Adressen leer bei vpn_transport=True → 400 mit klarer Meldung (kein stilles Public-Fallback), analog #189.
  • Am besten die URL-/Scheme-Auswahl aus dem /install-Pfad in eine gemeinsame Hilfsfunktion ziehen und an beiden Stellen (/install UND regenerate-token) nutzen, damit sie nicht wieder auseinanderlaufen.
  • Gleiches fuer den Create-Node-Response pruefen, falls der auch eine install_url/curl_command zurueckgibt.

Akzeptanz

  • regenerate-token fuer einen VPN-Node liefert eine ws/http-VPN-URL + im Script TRUSTED_TRANSPORT=vpn.
  • regenerate-token fuer einen Public-Node liefert eine wss/https-URL.
  • VPN-Node ohne hinterlegte VPN-Adresse → 400, kein Public-Fallback.
  • /install und regenerate-token nutzen dieselbe gemeinsame URL-Auswahl (keine Duplikat-Logik).

Branch

fix/regenerate-token-vpn-url

## Bug (Nachzügler zu #189) — HIGH, blockiert VPN-Node-Re-Enrollment `regenerate_token` (admin_router.py:649ff) baut die `install_url` aus dem globalen **`SERVER_URL`** (Zeile ~663): ``` install_url = f"{SERVER_URL}/install/{raw_token}" ``` Das ignoriert die in #189 eingefuehrte **Transport-Auswahl**. Fuer einen **VPN-Node** wird so die Public-/Default-Adresse ausgegeben → der anschliessende Install-Abruf laeuft in den https-Pflicht-400er (#113 Phase 1) bzw. der Agent bekommt die falsche SERVER_URL und scheitert am Transport (real beobachtet bei ITD-PROX01: `connect_async failed ws://…` + Dauer-Retry). ## Fix - Die `install_url`-Erzeugung in `regenerate_token` muss **dieselbe Auswahllogik** nutzen wie der `/install`-Endpoint (#189): - `node.vpn_transport` True → Basis = `node.vpn_server_url` sonst `SERVER_URL_VPN` (→ ws/http, TRUSTED_TRANSPORT=vpn im Script). - sonst → `SERVER_URL_PUBLIC` (→ wss/https). - beide VPN-Adressen leer bei vpn_transport=True → 400 mit klarer Meldung (kein stilles Public-Fallback), analog #189. - Am besten die URL-/Scheme-Auswahl aus dem `/install`-Pfad in eine **gemeinsame Hilfsfunktion** ziehen und an beiden Stellen (`/install` UND `regenerate-token`) nutzen, damit sie nicht wieder auseinanderlaufen. - Gleiches fuer den **Create-Node-Response** pruefen, falls der auch eine install_url/curl_command zurueckgibt. ## Akzeptanz - `regenerate-token` fuer einen VPN-Node liefert eine **ws/http-VPN-URL** + im Script `TRUSTED_TRANSPORT=vpn`. - `regenerate-token` fuer einen Public-Node liefert eine **wss/https-URL**. - VPN-Node ohne hinterlegte VPN-Adresse → 400, kein Public-Fallback. - `/install` und `regenerate-token` nutzen dieselbe gemeinsame URL-Auswahl (keine Duplikat-Logik). ## Branch `fix/regenerate-token-vpn-url`
chinux commented 2026-06-26 19:56:24 +00:00
Author
Owner
Copy link

Umgesetzt in 8c94521 (auf main).

Gemeinsamer Helper resolve_install_base(node) in server/util/install_url.py: VPN-Node → vpn_server_url bzw. SERVER_URL_VPN (ws/http, kein https-Zwang, TRUSTED_TRANSPORT); leer → 400 (kein stilles Public-Fallback). Sonst → SERVER_URL_PUBLIC (Fallback SERVER_URL) mit https-Zwang. /install (main.py), regenerate_token und install_info (admin_router.py) nutzen jetzt denselben Helper; regenerate_token löst die Basis VOR der Token-Rotation auf (400 verbrennt den alten Token nicht).

Akzeptanz verifiziert (Container-Test): public → https://theprox.itdata-gera.de; VPN(global/override) → http://172.16.1.14:8765 + trusted; VPN ohne Adresse → 400. /install-Verhalten unverändert (reiner Refactor).

Hinweis: inhaltsgleich zum (versehentlich separat angelegten) #193. Lasse dieses Issue offen — bitte als Dup zu #193 schließen oder umgekehrt.

Umgesetzt in `8c94521` (auf `main`). Gemeinsamer Helper `resolve_install_base(node)` in `server/util/install_url.py`: VPN-Node → `vpn_server_url` bzw. `SERVER_URL_VPN` (ws/http, kein https-Zwang, `TRUSTED_TRANSPORT`); leer → **400** (kein stilles Public-Fallback). Sonst → `SERVER_URL_PUBLIC` (Fallback `SERVER_URL`) mit https-Zwang. `/install` (main.py), `regenerate_token` und `install_info` (admin_router.py) nutzen jetzt denselben Helper; `regenerate_token` löst die Basis VOR der Token-Rotation auf (400 verbrennt den alten Token nicht). **Akzeptanz verifiziert** (Container-Test): public → `https://theprox.itdata-gera.de`; VPN(global/override) → `http://172.16.1.14:8765` + trusted; VPN ohne Adresse → 400. `/install`-Verhalten unverändert (reiner Refactor). Hinweis: inhaltsgleich zum (versehentlich separat angelegten) #193. Lasse dieses Issue offen — bitte als Dup zu #193 schließen oder umgekehrt.
chinux commented 2026-06-29 21:23:26 +00:00
Author
Owner
Copy link

Teil-Verifikation: regenerate_token (admin_router.py:686-720) nutzt bereits resolve_install_base(node) (Z.692/704/720) → der Kern-Bug (VPN-URL bei Re-Enroll) ist behoben ✓.

Rest offen: Die Node-Anlage (create-node, admin_router.py:136) baut install_url weiter aus rohem SERVER_URL statt aus dem Helper → ein VPN-Node bekommt direkt beim Anlegen eine falsche Install-URL. node ist an der Stelle bereits vorhanden (inkl. vpn_transport) → einfach auf resolve_install_base(node)['http_base'] umstellen, analog regenerate-token. Bleibt offen, bis das gefixt ist.

**Teil-Verifikation:** `regenerate_token` (admin_router.py:686-720) nutzt bereits `resolve_install_base(node)` (Z.692/704/720) → der Kern-Bug (VPN-URL bei Re-Enroll) ist behoben ✓. **Rest offen:** Die **Node-Anlage** (create-node, admin_router.py:136) baut `install_url` weiter aus rohem `SERVER_URL` statt aus dem Helper → ein VPN-Node bekommt direkt beim Anlegen eine falsche Install-URL. `node` ist an der Stelle bereits vorhanden (inkl. `vpn_transport`) → einfach auf `resolve_install_base(node)['http_base']` umstellen, analog regenerate-token. Bleibt offen, bis das gefixt ist.
chinux commented 2026-06-30 07:41:03 +00:00
Author
Owner
Copy link

#191-Rest umgesetzt in 621a9f3 (auf main).

Letzte rohe SERVER_URL-Stelle beseitigt: admin_router.create_node baut die install_url jetzt via resolve_install_base(node)["http_base"] (gleicher Helper wie /install + regenerate-token). node ist dort bereits angelegt + refreshed (hat vpn_transport).

Akzeptanz: VPN-Node beim Anlegen → VPN-URL; public → Domain; VPN ohne Adresse → 400 (HTTPException aus dem Helper, kein stilles Fallback). Helper nicht dupliziert. /install + regenerate-token inhaltlich unverändert.

Bleibt offen wie gewünscht.

**#191-Rest** umgesetzt in `621a9f3` (auf `main`). Letzte rohe `SERVER_URL`-Stelle beseitigt: `admin_router.create_node` baut die `install_url` jetzt via `resolve_install_base(node)["http_base"]` (gleicher Helper wie `/install` + `regenerate-token`). `node` ist dort bereits angelegt + refreshed (hat `vpn_transport`). **Akzeptanz:** VPN-Node beim Anlegen → VPN-URL; public → Domain; VPN ohne Adresse → 400 (HTTPException aus dem Helper, kein stilles Fallback). Helper nicht dupliziert. /install + regenerate-token inhaltlich unverändert. Bleibt offen wie gewünscht.
chinux commented 2026-06-30 20:26:04 +00:00
Author
Owner
Copy link

Verifiziert → erfüllt, wird geschlossen. create-node (admin_router.py:139-140) nutzt jetzt resolve_install_base(node)['http_base'] statt rohem SERVER_URL; VPN-Node ohne Adresse → HTTPException(400), kein stilles Fallback. regenerate-token nutzte den Helper bereits. Damit liefern /install, regenerate-token und create-node konsistent die transport-korrekte URL.

**Verifiziert → erfüllt, wird geschlossen.** create-node (admin_router.py:139-140) nutzt jetzt `resolve_install_base(node)['http_base']` statt rohem SERVER_URL; VPN-Node ohne Adresse → HTTPException(400), kein stilles Fallback. regenerate-token nutzte den Helper bereits. Damit liefern /install, regenerate-token und create-node konsistent die transport-korrekte URL.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/vm-agent-update-error
fix/bulk-update-autoclose
security/tenant-scope-108
refactor/dashboard-page-split
fix/rust-agent-parity-features
feat/rust-agent-parity
archive/python-node-agent
Labels
Clear labels   
agent
Node-/VM-Agent

  
bug
Funktionaler Defekt

  
frontend
Svelte/TS Frontend

  
refactor
Umbau ohne Verhaltensaenderung

  
tech-debt
Altlast / Aufraeumen

No labels
agent
bug
frontend
refactor
tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
chinux/theProx#191
No description provided.