Sign-out: a logout to each marked URL carries the one stored Basic Auth credential
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- Medio día
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- authentication, security
Línea de trabajo
The payload names no files. Start by finding where the per-entity Basic Auth credential is saved and where sign-out loops over the URLs an entity is marked at, which is the logic added in #1969. Choosing between the two fix directions needs a maintainer decision first. Done when a logout to a URL the credential was not entered for is sent without that credential, with a test covering it.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What happens
Studio stores one Basic Auth credential per entity (a cluster or instance), not per URL. A sign-in marker records the URL signed into, and an entity can end up marked at more than one URL, for example after its domain changes. When a sign-out logs out each URL an entity is marked at (#1969), every one of those logout requests carries that single stored credential, including to a URL it was never used with.
Why it's small
The URLs belong to the same entity, and the request is a logout. But a credential going to a host it wasn't entered for is worth closing.
Fix direction
Either store the credential with the URL it was entered for and send it only there, or send the logout with the credential only to the URL the credential was saved for, and without it to the others.
Review-Deferral: face1e3da4c920f7 severity=nit category=security
Raised by the cross-model review of #1969 (#1968). Pre-existing; not introduced there.
🤖 Generated by Anthropic Claude Code (Claude Opus 5.5); posted via @dawsontoth.
- Lenguaje dominante
- TypeScript
- Estrellas
- 5
- Forks
- 4
- Merge medio
- 1 d 19 h
- PR fusionados (30 d)
- 144
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de HarperFast/studio
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
HarperFast/studio#2070 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
HarperFast/studio#2067 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
HarperFast/studio#2053 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
HarperFast/studio#2026 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
HarperFast/studio#2021 ·
Los mantenedores suelen responder en 2 días
Todos los issues de HarperFast/studio
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
duolicious/duolicious#1943 ·
Los mantenedores suelen responder en 1 día
-
bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
nightly-labs/openbot#6451 ·
Los mantenedores suelen responder en 1 día
-
complexity: easy good first issue impact: low
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ueberdosis/hocuspocus#1211 ·
Los mantenedores suelen responder en 1 día
-
e2e-failure ready-to-code
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
redhat-developer/rhdh-plugin-export-overlays#4733 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
S-Needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 2 días