Call to session.stop() with side-effect in UpdateAccessTokenFilter.java
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- java
- Ambito
- authentication, backend
Direzione di ricerca
Inizia da src/main/java/org/ohdsi/webapi/shiro/filters/UpdateAccessTokenFilter.java, in particolare dalle righe 118-122, quindi esamina la configurazione del filtro e la cronologia relativa alla chiamata a session.stop(). Determina perché la sessione viene arrestata durante il login e se le sessioni sono necessarie; il lavoro è completato quando è stata presa una decisione documentata e il comportamento rilevante è stato convalidato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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?
- Lingua principale
- Java
- Stelle
- 153
- Fork
- 186
- Merge medio
- 2g 12h
- PR unite (30g)
- 13
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna 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 OHDSI/WebAPI
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
CDM cache warming still fails when cache.achilles.usePersonCount=false (missing `cc` alias in getBatchConceptRecordCount.sql)Forse già presa @DG47 l’ha presa 2 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
GET /conceptset/{id}/expression returns items in nondeterministic order (query has no ORDER BY)Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 67/100
OHDSI/WebAPI#2543 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di OHDSI/WebAPI
Issue simili
-
human-required sync-failed
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Azure/osdu-spi-file#63 ·
I maintainer di solito rispondono entro 1 giorno
-
frontend quick win
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
CodeForPhilly/benefit-decision-toolkit#571 ·
I maintainer di solito rispondono entro 1 giorno
-
approved
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
checkstyle/checkstyle#22129 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Add Hardcharger JDBC driverForse già presa @prmoore77 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno