AuthMiddleware pour React-Native

17/08/2018

Aucun commentaire

Se connecter une fois à l’application et le rester

Bien que la sécurité ne soit pas au cœur des préoccupations, ouvrir une application et devoir se reconnecter n’est sans doute pas le meilleur UX pattern qui soit.

En effet, cela devient même vite lassant! D’ailleurs, nous savons tous ce qu’il advient des applications qui nous fatiguent : POUBELLE!

Pour éviter d’en arriver là, nous allons voir comment utiliser l’outil Middleware de Redux. Il va nous permettre de rafraîchir le token avant qu’il expire. Pour celles et ceux qui ne sauraient pas ce qu’est un middleware, je vous invite à lire la doc !

Connaitre la date d’expiration

Dans notre cas l’API nous renvoie un JWT (JSON Web Token) lors de la connexion que l’on stocke dans l’AsyncStorage. Celui-ci contient des informations très utiles, notamment sa date d’expiration. Il suffit donc de décoder ce JWT et de comparer la date d’expiration avec celle en court. Si vous avez un token sous la main, vous pouvez voir ses informations sur ce site.

Les bons écrans

Certains écrans de l’application devaient être exclus. Cette fonction permet de vérifier que l’on se trouve sur un écran qui permet le rafraîchissement du token.

Le middleware

Grâce au middleware nous allons pouvoir vérifier pour chaque action, s’il faut ou non rafraichir le token. Tant qu’on n’a pas d’action concernant le rafraîchissement du token, on laisse le cycle de Redux se faire normalement. Par contre, une fois que le rafraîchissement est lancé, il faudra stocker les actions qui seront émises entre l’envoi de la requête au server et la réception du nouveau token. Il s’agira ensuite de re-dispatcher toutes ces actions. Voilà à quoi ça ressemble !

Explications

  • Ligne-4 : on crée notre buffer qui stockera les actions pendant le rafraîchissement du token.
  • Ligne-11 : si l’action est de type « REFRESH_TOKEN_REQUEST » alors pas la peine d’aller plus loin, on sort du middleware, pour continuer le cycle de Redux et ainsi lancer la requête au server.
  • Ligne-16 : si l’action est du type « REFRESH_TOKEN_SUCCESS », le server nous a bien renvoyé un nouveau token. Il faut donc continuer le cycle de Redux en envoyant l’action au callback « next() » sans sortir du middleware (pas de return). On vérifie en même temps si le buffer contient des actions. Si c’est le cas, on les « dispatch » de nouveau ligne 20. Attention, on n’oublie pas de vider le buffer !
  • Ligne-25 :  pour toutes les actions qui ne commencent pas par « REFRESH_TOKEN » on vérifie d’abord si le state existe. Il faut également s’assurer d’être sur un écran valide (ligne 27).
  • Ligne-28 : on regarde si le token est expiré ou non.

 

Pour cette application j’ai plusieurs reducers, dont celui du login. Je lui ai rajouté une propriété « refreshingToken » qui me permet de savoir si le rafraîchissement du token est en cours ou non. En même temps, je peux afficher un loader dans la vue de l’application.

Donc si le token est expiré (ligne 30) et qu’il existe, on regarde ensuite ligne 33 si le rafraîchissement n’est pas en cours et si le buffer est vide. Si toutes ces conditions sont valides alors on « dispatch » l’action qui déclenchera le rafraîchissement du token (ligne 34).

Si le rafraîchissement est en cours, alors on stocke l’action en cours dans le buffer ligne 37.

Ligne 42, on se retrouve avec toutes les actions sauf « REFRESH_TOKEN_REQUEST ». Il s’agira donc de filtrer l’action « REFRESH_TOKEN_SUCCESS » qui a déjà été passée au callback ligne 16 et bloquées celles pendant le rafraîchissement.

Dernière étape

Déclarer ce middleware lors de la création du store de votre application. Si comme moi vous utilisez redux-saga il faudra le déclarer avant.

Ce sera tout pour cet article, en espérant qu’il vous sera utile !

Pour finir voilà le fichier complet