« JWT SPA symfony exercice pratique » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 59 : | Ligne 59 : | ||
Depuis la version 0.7.0, le bundle de jetons d'actualisation contient une nouvelle option single_use qui supprime un jeton d'actualisation après utilisation et en émet un nouveau. Cela signifie qu'une fois qu'un attaquant vole un jeton d'actualisation, il n'a que jusqu'à la prochaine utilisation de l'utilisateur pour utiliser le jeton d'actualisation. Après c'est déjà inutile. Alors activons cela dans le fichier gesdinet_jwt_refresh_token.yml. | Depuis la version 0.7.0, le bundle de jetons d'actualisation contient une nouvelle option single_use qui supprime un jeton d'actualisation après utilisation et en émet un nouveau. Cela signifie qu'une fois qu'un attaquant vole un jeton d'actualisation, il n'a que jusqu'à la prochaine utilisation de l'utilisateur pour utiliser le jeton d'actualisation. Après c'est déjà inutile. Alors activons cela dans le fichier gesdinet_jwt_refresh_token.yml. | ||
gesdinet_jwt_refresh_token | gesdinet_jwt_refresh_token.yaml | ||
<pre> | <pre> | ||
gesdinet_jwt_refresh_token: | gesdinet_jwt_refresh_token: | ||
| Ligne 72 : | Ligne 72 : | ||
Pour cela, nous ajoutons un gestionnaire de déconnexion personnalisé à notre pare-feu qui est généralement appelé api dans mes applications. Cela signifie que j'utilise la fonctionnalité de déconnexion par défaut de Symfony, mais en étendant la gestion. | Pour cela, nous ajoutons un gestionnaire de déconnexion personnalisé à notre pare-feu qui est généralement appelé api dans mes applications. Cela signifie que j'utilise la fonctionnalité de déconnexion par défaut de Symfony, mais en étendant la gestion. | ||
security.yaml | |||
<pre> | <pre> | ||
security: | |||
firewalls: | |||
api: | |||
... | |||
logout: | |||
path: /api/logout | |||
handlers: [App\Service\Authentication\LogoutHandler] | |||
</pre> | </pre> | ||
| Ligne 230 : | Ligne 231 : | ||
security.yaml | security.yaml | ||
<pre> | <pre> | ||
security: | |||
firewalls: | |||
login: | |||
form_login: | |||
... | |||
check_path: /api/login | |||
success_handler: App\Service\Authentication\LoginSuccessHandler | |||
</pre> | </pre> | ||
| Ligne 297 : | Ligne 298 : | ||
security.yaml | security.yaml | ||
<pre> | <pre> | ||
security: | |||
firewalls: | |||
api: | |||
pattern: ^/api | |||
stateless: true | |||
... | |||
guard: | |||
authenticators: | |||
- App\Service\Authentication\JWTAndSecurityCookieAuthenticator | |||
</pre> | </pre> | ||
| Ligne 370 : | Ligne 371 : | ||
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 | |||
<pre> | <pre> | ||
api_refresh_token: | |||
path: '/api/token/refresh' | |||
defaults: { _controller: gesdinet.jwtrefreshtoken:refresh } | |||
methods: [POST] | |||
</pre> | </pre> | ||
*Nous utilisons le suivant : | *Nous utilisons le suivant : | ||
routes.yaml | |||
</pre> | </pre> | ||
api_refresh_token: | |||
path: '/api/token/refresh' | |||
defaults: { _controller: App\Service\Authentication\RefreshTokenSecurityCookieService:refresh } | |||
methods: [POST] | |||
</pre> | </pre> | ||