Passer au contenu principal

Gestion des cookies de session pour les tests automatisés (par exemple, Entra ID)

Écrit par Ines

Commencez ici : les Profils authentifiés

Thunders peut désormais enregistrer une connexion une seule fois et la rejouer au début de chaque exécution, ce qui supprime le besoin de gérer les cookies de session à la main pour la plupart des applications. Enregistrez un Profil authentifié, puis ajoutez une seule étape Injection de profil à chaque cas de test.

Utilisez cette page quand un Profil ne peut pas vous aider, par exemple quand votre application conserve l'authentification uniquement en mémoire et que rien ne persiste dans les cookies ni dans le stockage.

Certaines équipes souhaitent exécuter leurs tests de bout en bout sans répéter le flux de connexion complet à chaque exécution. Lorsque l'authentification est gérée par un fournisseur d'identité comme Entra ID (anciennement Azure AD), cela peut soulever des questions sur la réutilisation des cookies de session existants pour accélérer les choses.

Bien que la réinjection manuelle des cookies d'authentification *puisse* fonctionner en théorie, elle n'est pas recommandée. Cette méthode crée souvent des risques de sécurité et conduit à des tests instables ou difficiles à maintenir.

Bonne nouvelle : il existe une méthode plus propre, plus sûre et entièrement contrôlée pour obtenir le même effet de "saut de connexion".


Pourquoi l'injection directe de cookies est déconseillée

La réutilisation ou le codage en dur des cookies d'authentification pose plusieurs problèmes :

  • Les cookies de session sont de courte durée et peuvent expirer de manière inattendue.

  • L'injection manuelle de cookies peut affaiblir la sécurité.

  • Les fournisseurs d'identité tels qu'Entra ID procèdent à une rotation des jetons et appliquent une validation stricte.

  • Cela conduit souvent à des tests peu fiables.

Pour ces raisons, nous ne recommandons pas de s'appuyer sur l'injection de cookies bruts dans les flux de tests automatisés.


Approche recommandée : construire un point de terminaison dédié "login-as-tester"

Au lieu d'injecter des cookies manuellement pendant l'exécution des tests, le client peut mettre en œuvre un petit mécanisme contrôlé de son côté.

Concept

Créez une route privée, par exemple :

/login-as-tester

Ce point de terminaison exécute les étapes suivantes :

  1. Connexion automatique à l'aide d'un compte de test dédié (pas un utilisateur de production).

  2. Génération ou récupération des cookies d'authentification valides.

  3. Injection de ces cookies dans la session active.

  4. Redirection de l'utilisateur ou de l'exécuteur de tests vers la page principale de votre application (par exemple : /).

À partir de ce moment, votre test automatisé commence déjà authentifié, sans passer par le flux de connexion standard.


Avantages de cette approche

  • Mécanisme de test contrôlé et sécurisé

  • Pas besoin de modifier les scripts automatisés

  • Pas d'exposition de cookies sensibles dans le code de test

  • Tests plus stables (pas de problèmes d'expiration des cookies en cours d'exécution)

  • Maintien d'une bonne hygiène de sécurité tout en permettant une connexion rapide pour les tests


Exemple de flux

  1. L'exécuteur de tests ouvre : https://your-app.com/login-as-tester

  2. Le backend gère l'authentification et la génération des cookies.

  3. Redirection automatique vers /.

  4. Les tests automatisés démarrent à partir de l'état authentifié.


Conclusion

Thunders peut exécuter des tests sans effectuer le flux de connexion à chaque fois, mais cela nécessite une configuration sécurisée et maintenable du côté du client.

La solution recommandée est de créer un point de terminaison dédié "login-as-tester" qui gère l'authentification et l'injection de cookies en toute sécurité avant le début des tests.

Avez-vous trouvé la réponse à votre question ?