[Bug]: CLIProxyAPI hub source accepts the panel URL (/management.html) and then shows only "The hub answered with HTTP 404."
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- Mezza giornata
- Idoneità per principianti
- 62/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- backend
Direzione di ricerca
Inizia da apps/server/src/usage/cliproxyApi.ts in CliproxyApi.management, dove l'URL della richiesta viene costruita da config.url con una barra finale, quindi un percorso come /management.html viene mantenuto. Controlla AddUsageLimitSourceDialog.tsx, che si limita a verificare che il campo non sia vuoto. Scegli una delle correzioni elencate nell'issue: normalizzare l'URL all'origine, validarla oppure includere l'URL richiesta nell'errore 404. È completato quando un URL del pannello si risolve nella radice dell'hub o produce un messaggio chiaro, e i test esistenti sull'utilizzo continuano a passare.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Summary
Settings → Add a CLIProxyAPI hub accepts the URL of the hub's management panel page (https://hub.example.com/management.html). That is the address a user has open in the browser, so it is the natural thing to paste. The usage reader then builds https://hub.example.com/management.html/v0/management/auth-files, the hub answers 404, and the Limits warning only says:
<environment> · hub.example.com: The hub answered with HTTP 404.
Nothing points at the Hub URL field. The management key is correct, and the same key works once the URL is changed to the bare origin.
Steps to reproduce
- Run a CLIProxyAPI hub with remote management enabled. Its panel is served at
https://hub.example.com/management.html. - In T3 Code, open Settings → Add a CLIProxyAPI hub.
- Enter
https://hub.example.com/management.htmlas Hub URL and a valid management key. Save. - Open Usage → Limits, or wait for the next refresh.
Expected behavior
One of these:
- T3 normalizes a known panel path such as
/management.htmlto the hub root before saving or requesting. - Or saving validates the URL with a probe and explains that Hub URL must be the hub root, not the panel page.
- Or the 404 warning names the URL it requested, or suggests checking that Hub URL is the hub root.
Actual behavior
cliproxyApi.ts resolves v0/management/${path} against config.url with a trailing slash added (apps/server/src/usage/cliproxyApi.ts, CliproxyApi.management). A URL with a path keeps that path:
new URL("v0/management/auth-files", "https://hub.example.com/management.html/")
→ https://hub.example.com/management.html/v0/management/auth-files (404)
The same key against https://hub.example.com/v0/management/auth-files returns 200. The warning shows only the status code, so the cause is invisible from the UI. The Add hub dialog (AddUsageLimitSourceDialog.tsx) only checks that the field is non-empty.
Impact
Minor bug or occasional failure
Version or commit
T3 Code 0.1.7-nightly.20261101. The same code is on main @ 976a23161d.
Environment
Linux server environment, CLIProxyAPI v8 hub behind an HTTPS reverse proxy.
Logs or stack traces
UsageLimitSourceError: The hub answered with HTTP 404.
at CliproxyApi.management
at CliproxyApi.authFiles
at CliproxyApi.readAccounts
at UsageLimitSources.readSource
Workaround
Edit the source so Hub URL is the bare origin (https://hub.example.com).
- Lingua principale
- TypeScript
- Stelle
- 24.8k
- Fork
- 6.4k
- Merge medio
- 13h 49m
- PR unite (30g)
- 179
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di pingdotgg/t3code
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
via-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Pi provider reports "timed out" on pi --version because the version probe timeout is only 4 sApertavia-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: Dragging a sidebar thread from the lower part of the list auto-scrolls the sidebar to the bottomForse già presa @juliusmarminge l’ha presa 3 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
pingdotgg/t3code#27146 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di pingdotgg/t3code
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
ready-for-agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
LucasSantana-Dev/Lucky#2951 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
danielmiessler/LifeOS#2567 ·
I maintainer di solito rispondono entro 9 giorni
-
refactor(react-pi): classify base64 images with core's parseBase64Forse già presa @jimmyallinai l’ha presa oggi. Apertamaintenance
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
assistant-ui/assistant-ui#10293 · 2 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
brijeshb42/monaco-vim#175 ·