« JWT SPA symfony exercice pratique » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 135 : | Ligne 135 : | ||
La valeur doit être basée sur l'utilisateur, le jeton d'actualisation valide actuel et un sel aléatoire. De cette façon, il ne dépend toujours pas de la session du serveur mais des valeurs de la base de données. Nous aurions également la possibilité de forcer une déconnexion globale en modifiant le sel utilisé sur le serveur. Une petite méthode pour cela pourrait ressembler à ceci: | La valeur doit être basée sur l'utilisateur, le jeton d'actualisation valide actuel et un sel aléatoire. De cette façon, il ne dépend toujours pas de la session du serveur mais des valeurs de la base de données. Nous aurions également la possibilité de forcer une déconnexion globale en modifiant le sel utilisé sur le serveur. Une petite méthode pour cela pourrait ressembler à ceci: | ||
==== generateSecurityCookieHash ==== | ===== generateSecurityCookieHash ===== | ||
<pre> | <pre> | ||
private function generateSecurityCookieHash(User $user, RefreshTokenInterface $refreshToken): string | private function generateSecurityCookieHash(User $user, RefreshTokenInterface $refreshToken): string | ||
| Ligne 149 : | Ligne 149 : | ||
Dans celui-ci, nous créerons le cookie en fonction du jeton d'actualisation de l'utilisateur authentifié. Le service complet ressemblera à ceci: | Dans celui-ci, nous créerons le cookie en fonction du jeton d'actualisation de l'utilisateur authentifié. Le service complet ressemblera à ceci: | ||
==== AuthenticationService ==== | ===== AuthenticationService ===== | ||
<pre> | <pre> | ||
<?php | <?php | ||
| Ligne 231 : | Ligne 231 : | ||
Pour définir le cookie, nous ajoutons un gestionnaire de réussite de connexion et utilisons notre service d'authentification là-bas: | Pour définir le cookie, nous ajoutons un gestionnaire de réussite de connexion et utilisons notre service d'authentification là-bas: | ||
==== security.yaml ==== | ===== security.yaml ===== | ||
<pre> | <pre> | ||
security: | security: | ||
| Ligne 242 : | Ligne 242 : | ||
</pre> | </pre> | ||
==== LoginSuccessHandler ==== | ===== LoginSuccessHandler ===== | ||
<pre> | <pre> | ||
<?php | <?php | ||
| Ligne 298 : | Ligne 298 : | ||
Vient maintenant la partie qui ne me satisfait toujours pas, car je n'ai pas trouvé de bon point d'entrée. Le garde utilisé lors de l'utilisation du bundle JWT est le JWTTokenAuthenticator. Le moyen le plus simple d'attacher le cookie serait d'écouter la réponse, mais malheureusement, il n'y a aucun moyen d'y parvenir. Et dans tous les cas où j'ai accès à l'utilisateur, nous n'avons pas accès à la réponse. Donc, le seul moyen que j'ai trouvé était de créer mon propre authentificateur, d'étendre le JWTTokenAuthenticator, d'utiliser la même méthode onAuthenticationSuccess et d'appeler la méthode parente pour avoir le même comportement qu'avant juste avec la vérification des cookies ajoutée. L'authentificateur complet sera configuré comme authentificateur dans le fichier security.yml et ressemble à ceci. | Vient maintenant la partie qui ne me satisfait toujours pas, car je n'ai pas trouvé de bon point d'entrée. Le garde utilisé lors de l'utilisation du bundle JWT est le JWTTokenAuthenticator. Le moyen le plus simple d'attacher le cookie serait d'écouter la réponse, mais malheureusement, il n'y a aucun moyen d'y parvenir. Et dans tous les cas où j'ai accès à l'utilisateur, nous n'avons pas accès à la réponse. Donc, le seul moyen que j'ai trouvé était de créer mon propre authentificateur, d'étendre le JWTTokenAuthenticator, d'utiliser la même méthode onAuthenticationSuccess et d'appeler la méthode parente pour avoir le même comportement qu'avant juste avec la vérification des cookies ajoutée. L'authentificateur complet sera configuré comme authentificateur dans le fichier security.yml et ressemble à ceci. | ||
==== security.yaml ==== | ===== security.yaml ===== | ||
<pre> | <pre> | ||
security: | security: | ||
| Ligne 311 : | Ligne 311 : | ||
</pre> | </pre> | ||
==== JWTAndSecurityCookieAuthenticator ==== | ===== JWTAndSecurityCookieAuthenticator ===== | ||
<pre> | <pre> | ||
<?php | <?php | ||
| Ligne 373 : | Ligne 373 : | ||
Nous avons un problème similaire à celui du bundle JWT en ce sens qu'il y a des événements que nous pourrions écouter, mais jamais ceux avec un accès à la demande et à la réponse en même temps. Par conséquent, la seule solution que j'ai trouvée était de copier le service de jeton d'actualisation utilisé comme point de terminaison pour l'itinéraire de jeton d'actualisation et de l'étendre. Signification au lieu de cette route qui est la valeur par défaut: | Nous avons un problème similaire à celui du bundle JWT en ce sens qu'il y a des événements que nous pourrions écouter, mais jamais ceux avec un accès à la demande et à la réponse en même temps. Par conséquent, la seule solution que j'ai trouvée était de copier le service de jeton d'actualisation utilisé comme point de terminaison pour l'itinéraire de jeton d'actualisation et de l'étendre. Signification au lieu de cette route qui est la valeur par défaut: | ||
==== routes.yaml ==== | ===== routes.yaml ===== | ||
<pre> | <pre> | ||
api_refresh_token: | api_refresh_token: | ||
| Ligne 383 : | Ligne 383 : | ||
==== Nous utilisons le suivant ==== | ==== Nous utilisons le suivant ==== | ||
==== routes.yaml ==== | ===== routes.yaml ===== | ||
</pre> | </pre> | ||
api_refresh_token: | api_refresh_token: | ||
| Ligne 393 : | Ligne 393 : | ||
La copie complète est annotée avec les espaces où je place la validation du cookie et la création du cookie après l'ajout du nouveau jeton d'actualisation. | La copie complète est annotée avec les espaces où je place la validation du cookie et la création du cookie après l'ajout du nouveau jeton d'actualisation. | ||
==== RefreshTokenSecurityCookieService ==== | ===== RefreshTokenSecurityCookieService ===== | ||
<pre> | <pre> | ||
<?php | <?php | ||