-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TECH] Rendre le code lié à l'authentification des users plus clair et corriger un test erroné (PIX-15878) #10907
Merged
pix-service-auto-merge
merged 7 commits into
dev
from
refactor-better-api-token-code-and-tests
Dec 30, 2024
Merged
[TECH] Rendre le code lié à l'authentification des users plus clair et corriger un test erroné (PIX-15878) #10907
pix-service-auto-merge
merged 7 commits into
dev
from
refactor-better-api-token-code-and-tests
Dec 30, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Une fois les applications déployées, elles seront accessibles via les liens suivants :
Les variables d'environnement seront accessibles via les liens suivants : |
lego-technix
changed the title
[TECH] Refactor better api token code and tests
[TECH] Refactor better api token code and tests (PIX-15878)
Dec 30, 2024
lego-technix
force-pushed
the
refactor-better-api-token-code-and-tests
branch
from
December 30, 2024 10:56
7c01838
to
2c1a51a
Compare
lego-technix
changed the title
[TECH] Refactor better api token code and tests (PIX-15878)
[TECH] Rendre le code lié à l'authentification des users plus clair et corriger un test erroné (PIX-15878)
Dec 30, 2024
EmmanuelleBonnemay
approved these changes
Dec 30, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lu et testé avec succès
lego-technix
added
Tech Review OK
🚀 Ready to Merge
Func Review OK
PO validated functionally the PR
and removed
👀 Tech Review Needed
👀 Func Review Needed
labels
Dec 30, 2024
…ted as an integration test
…as intended to be
pix-service-auto-merge
force-pushed
the
refactor-better-api-token-code-and-tests
branch
from
December 30, 2024 15:38
2c1a51a
to
23f9918
Compare
pix-service-auto-merge
deleted the
refactor-better-api-token-code-and-tests
branch
December 30, 2024 15:44
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🎄 Problème
Avant le travail de confinement des access tokens utilisateurs, des points gênants ont été identifiés :
🎁 Proposition
/api/token
le code assurant la validation dugrant_type
dissémine la logique de validation entre la route (avec la validation joi) et le controller (avec desif
-else
danstokenController.createToken
). Il faut choisir : soit la validation complète dugrant_type
est à faire au niveau dans la validation joi au niveau de la route, soit la validation complète dugrant_type
est à faire au niveau du controller. La philosophie actuelle du code est de plutôt mettre toute la validation de la payload (avec songrant_type
donc) dans la route. Cela a du sens car ce sont des paramètres plutôt techniques (très lié au domaine de l'authentification technique) que métier. Le refactor proposé est donc de rapatrier toute la logique de validation dans la définition de la route.🧦 Remarques
RAS
🎅 Pour tester
superadmin@example.net
)superadmin@example.net
en ayant au préalable dans le.env
configuréACCESS_TOKEN_LIFESPAN=10s
de manière à ne pas attendre trop longtemps la génération d'un nouvel Access Token à partir du Refresh Token)grant_type
autre quepassword
etrefresh_token
n'est autorisé et que le script ci-dessous renvoie une erreur400
(remplacerXXX
par le bon mot de passe) :