Call to session.stop() with side-effect in UpdateAccessTokenFilter.java
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Bug
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- java
- Domaine
- authentication, backend
Piste de recherche
Commencez par src/main/java/org/ohdsi/webapi/shiro/filters/UpdateAccessTokenFilter.java, en particulier les lignes 118-122, puis examinez sa configuration de filtre et l’historique autour de l’appel à session.stop(). Déterminez pourquoi la session est arrêtée lors de la connexion et si les sessions sont nécessaires ; le travail est terminé lorsqu’une décision documentée a été prise et que le comportement concerné a été validé.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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?
- Langage dominant
- Java
- Étoiles
- 153
- Forks
- 187
- Merge moyen
- 1 j 3 h
- PR mergées (30 j)
- 14
Préparer son environnement
- Fournit un Dockerfile ou un fichier Docker Compose
- Aucun modèle de pull request
- Aucun guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de OHDSI/WebAPI
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 1 jour
-
CDM cache warming still fails when cache.achilles.usePersonCount=false (missing `cc` alias in getBatchConceptRecordCount.sql)Peut-être pris @DG47 l’a pris il y a 5 jours. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
GET /conceptset/{id}/expression returns items in nondeterministic order (query has no ORDER BY)Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 67/100
OHDSI/WebAPI#2543 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
OHDSI/WebAPI#2513 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de OHDSI/WebAPI
Issues similaires
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
-
[Bug]: REST API URL starting with "http" but no scheme (e.g. httpbin.org/get) is not given an http:// prefixPeut-être pris @ItsDeadlyProgrammer l’a pris il y a 1 jour. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
appsmithorg/appsmith#42471 · 1 commentaire ·
Les mainteneurs répondent en général sous 2 jours
-
code-maintenance
Difficulté 2/5 1-3 heures Accessibilité débutants 77/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
-
bug priority: medium Review effort [1-5]: 3 status: needs-triage type: bug
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
carlos-emr/carlos#5258 ·
Les mainteneurs répondent en général sous 1 jour