Se connecter via l’interface utilisateur de votre application au début de chaque test d’application mobile allonge la durée d’exécution et entraîne une instabilité non liée au test. Ce guide explique comment contourner cette étape de connexion en injectant un jeton d’authentification en direct pour que le test démarre déjà authentifié.
Le flux comporte trois parties :
Un test d’API se connecte à votre fournisseur d’authentification selon un planning et extrait un jeton d’accès.
Une variable globale provenant de ce test contient la valeur du jeton.
Votre test d’application mobile transmet la variable globale à l’application en tant qu’argument de lancement ou extra d’intention. Votre application le lit au démarrage et ignore son flux de connexion normal.
Comme le test d’API actualise le jeton selon un planning, la valeur de la variable globale se met à jour d’elle-même, sans aucun travail manuel ni appel à la Datadog API.
Étape 1 : Créer le test d’API de récupération de jeton
Si votre fournisseur d’authentification nécessite un secret client, stockez-le d’abord en tant que variable globale sécurisée, au lieu de le coder en dur dans la requête. Saisissez un nom tel que AUTH_CLIENT_SECRET et sélectionnez Hide and obfuscate variable value lors de sa création.
Créez un test HTTP qui demande un jeton à l’endpoint de jeton de votre fournisseur :
Requête : POST vers votre endpoint de jeton, tel que https://auth.yourdomain.com/oauth/token.
En-tête : Content-Type: application/json.
Corps : une charge utile JSON avec vos identifiants client, faisant référence à la variable globale AUTH_CLIENT_SECRET :
Variable extraite : extraire une variable nommée EXTRACTED_TOKEN du corps de la réponse, en utilisant une expression jsonpath qui correspond à votre champ de jeton, telle que $.access_token. Sélectionnez Hide and obfuscate variable value afin que le jeton n’apparaisse pas dans les résultats de test.
Définissez la fréquence de test sur une durée inférieure à la fenêtre d’expiration de votre jeton, afin que le jeton ne devienne pas obsolète entre les exécutions. Par exemple, exécutez le test toutes les 30 minutes pour un jeton qui expire après une heure. Vous pouvez également associer une alerte d’échec au test pour savoir s’il cesse de rafraîchir le jeton.
Étape 2 : Créer une variable globale depuis le test
Créez une variable globale à partir du test de jeton afin que votre test d’application mobile puisse référencer sa valeur:
Accédez à l’onglet Global Variables sur la Settings page. Cliquez sur + New Global Variable.
Sélectionnez l’onglet Create From Test et sélectionnez votre test de jeton.
Saisissez un Variable Name, tel que MOBILE_AUTH_TOKEN.
Sélectionnez Hide and obfuscate variable value afin que le jeton n’apparaisse pas dans les résultats de test.
Sélectionnez la source de la valeur :
Si votre test de jeton est une requête HTTP unique, sélectionnez Response Body et réutilisez l’expression jsonpath de votre assertion de test, par exemple $.access_token.
Si votre test de jeton comporte plusieurs étapes, sélectionnez la variable locale EXTRACTED_TOKEN que vous avez extraite à l’étape 1.
La valeur de cette variable se met à jour automatiquement chaque fois que le test de récupération de jeton s’exécute.
Étape 3 : Transmettre le jeton à votre test d’application mobile
Les tests d’applications mobiles prennent en charge la transmission de paires key:value à votre application au lancement via les options avancées. Référencez votre variable globale en tapant {{ dans le champ, afin que sa valeur actuelle soit substituée lors de l’exécution :
{"auth_token":"{{ MOBILE_AUTH_TOKEN }}"}
{"auth_token":"{{ MOBILE_AUTH_TOKEN }}"}
Étape 4 : Gérez le jeton dans votre application
Votre application doit lire la valeur injectée au démarrage, la stocker de manière sécurisée et l’utiliser pour ignorer son flux de connexion. Protégez ce comportement derrière un indicateur de build afin que le chemin de code n’existe que dans vos builds de test ou d’automatisation.
Stockez le jeton dans le trousseau d’accès plutôt que dans UserDefaults, afin qu’il soit protégé au repos comme un jeton que votre application reçoit d’une connexion réelle.
react-native-launch-arguments lit les arguments de processus sur iOS et les extras d’intention sur Android via une seule API. react-native-keychain stocke le jeton dans le trousseau d’accès ou le Keystore de la plateforme au lieu de AsyncStorage.
Considérations de sécurité
N’acceptez un jeton d’authentification injecté que dans les builds de test ou d’automatisation, jamais en production. Vérifiez un indicateur de build avant de lire l’argument, et assurez-vous que cet indicateur n’est pas défini dans les builds que vous distribuez sur les magasins d’applications.
C’est particulièrement important sur Android. Un extra d’intent envoyé à une activité de lancement exportée Activity peut provenir de n’importe quelle application sur l’appareil, pas seulement du test runner de Datadog. Sans check par indicateur de build, une application de production qui lit et fait confiance à auth_token provenant de son intention de lancement permet à n’importe quelle application locale de s’authentifier en tant que compte de test.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles: