Call to session.stop() with side-effect in UpdateAccessTokenFilter.java
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- java
- Área
- authentication, backend
Línea de trabajo
Comienza con src/main/java/org/ohdsi/webapi/shiro/filters/UpdateAccessTokenFilter.java, especialmente con las líneas 118-122; después, inspecciona su configuración de filtros y el historial relacionado con la llamada a session.stop(). Determina por qué se detiene la sesión durante el inicio de sesión y si las sesiones son necesarias; se considera terminado cuando haya una decisión documentada y se haya validado el comportamiento relevante.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
While reviewing the code in UpdateAccessTokenFilter.java I stumbled upon the following lines
which struck me as odd. In fact, session.stop() is called only twice in the whole WebAPI code base, both times in this UpdateAccessTokenFilter class. Given UpdateAccessTokenFilter's place in the grand scheme of filters configured, the above lines seem to always be called upon login, and result in an immediate end of the session that actually just started... The rest of the user interactions seem to continue based on token authentication alone.
Code blame shows that the code itself and the surrounding parts are many years old.
Questions:
- Would it be possible to find more details on why the
session.stop()was added here? - Do we need sessions at all?
- Lenguaje dominante
- Java
- Estrellas
- 153
- Forks
- 187
- Merge medio
- 2 d 12 h
- PR fusionados (30 d)
- 13
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin 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 OHDSI/WebAPI
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
CDM cache warming still fails when cache.achilles.usePersonCount=false (missing `cc` alias in getBatchConceptRecordCount.sql)Posiblemente ocupada @DG47 la tomó hace 3 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
GET /conceptset/{id}/expression returns items in nondeterministic order (query has no ORDER BY)Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 67/100
OHDSI/WebAPI#2543 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de OHDSI/WebAPI
Issues similares
-
status: needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
JabRef/jabref#17546 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
hiero-ledger/hiero-sdk-java#3010 ·
Los mantenedores suelen responder en 1 día
-
Optimize consumer version heatmap aggregation to avoid repeated scansPosiblemente ocupada @praykaria31 la tomó hoy. Abiertotype/enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Apicurio/apicurio-registry#10662 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
a:false-positive
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
Los mantenedores suelen responder en 1 día
-
status: waiting-for-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
spring-projects/spring-boot#52347 ·
Los mantenedores suelen responder en 2 días