Vue d’ensemble de l'authentification

Les applications Power Platform s’étendent sur deux domaines distincts, chacun nécessitant une session authentifiée distincte :

L’infrastructure gère les deux domaines en acquérant un état de stockage du navigateur une fois et en réutilisant toutes les exécutions de test. Cette approche évite de se connecter à chaque test, ce qui réduit considérablement la durée de la suite de tests.

Le fonctionnement de l’état de stockage dans Playwright

La fonctionnalité de storageState Playwright capture tous les cookies et le stockage local (y compris les jetons MSAL) à partir d’une session de navigateur authentifiée et les enregistre dans un fichier JSON. Lorsque les tests démarrent, le contexte du navigateur est initialisé avec cet état enregistré, en contournant le flux de connexion interactive.

Le framework stocke deux fichiers d’état :

Emplacement de stockage par défaut : packages/e2e-tests/.playwright-ms-auth/

Fournisseurs d’authentification

L’infrastructure prend en charge trois fournisseurs d’informations d’identification :

Authentification par mot de passe

Utilisez l’authentification par mot de passe pour le développement local lorsque l’infrastructure de certificat n’est pas disponible.

MS_AUTH_CREDENTIAL_TYPE=password
MS_USER_PASSWORD=<password>

Authentification par certificat

Utilisez l’authentification par certificat pour les pipelines CI/CD et les environnements partagés. Cette méthode évite de stocker les mots de passe et prend en charge les scénarios multifacteurs.

MS_AUTH_CREDENTIAL_TYPE=certificate
MS_AUTH_CREDENTIAL_PROVIDER=local-file
MS_AUTH_LOCAL_FILE_PATH=../../cert/<cert-file>.pfx
MS_AUTH_CERTIFICATE_PASSWORD=<optional-pfx-password>

Azure Key Vault

Utilisez Azure Key Vault pour les pipelines de production où vous gérez les certificats de manière centralisée.

MS_AUTH_CREDENTIAL_TYPE=certificate
MS_AUTH_CREDENTIAL_PROVIDER=azure-keyvault
AZURE_KEYVAULT_URL=https://<vault>.vault.azure.net/
AZURE_CERTIFICATE_NAME=<certificate-name>

Validation et expiration des jetons pour l’état d’authentification

Avant chaque exécution de test, l’infrastructure valide le fichier d’état de stockage :

• Power Apps state : Valide l’expiration du jeton d’accès MSAL à partir de localStorage
• MDA state : Valide les cookies de session Dynamics 365 à partir du domaine CRM

Si un fichier d’état a expiré, le framework le supprime et vous invite à vous authentifier à nouveau. Dans CI/CD, l’authentification s’exécute dans globalSetup pour acquérir un nouvel état avant chaque exécution du pipeline.

Plusieurs utilisateurs de test

Pour exécuter des tests avec différents comptes d’utilisateur (par exemple, tester l’accès en fonction du rôle), créez des fichiers d’état de stockage distincts en définissant MS_AUTH_EMAIL et en exécutant les scripts d’authentification pour chaque utilisateur :

MS_AUTH_EMAIL=user1@contoso.com npm run auth:headful
MS_AUTH_EMAIL=user2@contoso.com npm run auth:headful

Référencez ensuite le fichier d’état spécifique dans votre test :

test.use({
  storageState: getStorageStatePath('user1@contoso.com'),
});

Considérations relatives à la sécurité

• Les fichiers d’état de stockage contiennent des jetons de session. Ajouter .playwright-ms-auth/ à votre .gitignore.
• Renouvelez régulièrement les informations d’identification des utilisateurs de test et réauthentifiez-vous.
• Utilisez des comptes de test dédiés avec des autorisations minimales requises.
• Pour le CI/CD de production, utilisez l’authentification de certificat avec des certificats stockés dans Azure Key Vault.

Étapes suivantes

• Guide d’authentification Instructions pas à pas pour chaque fournisseur d’informations d’identification

Voir également

• variables d’environnement
• Intégration CI/CD