Simplifier l'authentification

[camillemonchicourt]

L'authentification est nécessaire à la synchronisation des données pour accéder aux routes de GeoNature et de vérifier les droits de l'utilisateur.
Son processus est décrit ici : https://github.com/PnX-SI/gn_mobile_core/blob/master/docs/data_sync.adoc

Depuis la version 2.1.0 l'authentification n'est demandée que si une synchronisation est lancée et que si l'appareil a du réseau (#145).

Elle n'est donc lancée que si l'utilisateur lance une synchronisation lui-même.
Ou alors si les paramètres de périodicité de synchronisation automatique sont renseignés (https://github.com/PnX-SI/gn_mobile_core/tree/master/datasync#parameters-description), alors une synchronisation peut être exécutée automatiquement au lancement de l'application si la date de dernière synchro est supérieure à la période définie.
Quand une synchronisation est lancée, si le cookie de l'utilisateur a expiré et que l'appareil a du réseau, alors il est renvoyé sur le formulaire d'authentification.

---

Actuellement la validation de l'authentification est faite par l'application mobile qui stocke le cookie et sa date d'expiration. Cela reste complexe et fragile, par exemple s'il existe un décalage horaire entre la date système côté serveur GeoNature et la date côté terminal, la validation peut tomber en échec plus facilement surtout si la durée de validité du token est courte (1h par exemple), alors que côté serveur GeoNature, la session serait encore valide.

• Il a été remonté dans le ticket Tests de la version 2.1.0 sur Android 10 et 11 #151 le soucis autour de l'expiration du cookie où coté application mobile, l'utilisateur est invité à devoir se reconnecter de nouveau alors qu'il a déjà fait préalablement
• Côté application, il y a une vérification de la validité du token (attribut "expires" remonté après authentification) lors de la synchronisation des données et une vérification du cookie de session lors de l'appel sur chaque route de GeoNature
  • Si le token est expirée, l'application considère que l'utilisateur n'est pas connecté et donc si ça arrive lors de la synchronisation des données il sera invité à s'authentifier
  • Si le cookie est expiré, l'application fera malgré tout appel à la route mais sans le cookie. Si la route appelée est protégée, une 401 sera retournée
  • Cette vérification s'appuie sur l'heure système du terminal qui n'est pas forcément en phase avec celle du serveur GeoNature (surtout si la durée de validité est courte)
  • Il y a une double vérification (token et cookie) et si il y a un delta entre ces deux valeurs, ça va provoquer une déconnexion, notamment le fait qu'il est possible de configurer la durée de validité du cookie coté GeoNature (cf. Tests de la version 2.1.0 sur Android 10 et 11 #151).

---

En l'état c'est donc compliqué pour avoir au final quelque chose de peu fiable. La proposition de @sgrimault est donc d'avoir une approche "optimiste" coté application mobile :
Après authentification, l'application garde en local le cookie de session. Ce cookie est systématiquement envoyé sur chaque route de GeoNature appelée (peu importe sa date d'expiration). Si GeoNature répond 401 alors l'application "sait" que la session est expirée et donc supprime le cookie présent localement et peut notifier le cas échéant l'utilisateur pour l'inviter à se reconnecter de nouveau.

L'idée est donc de ne plus faire la validation du cookie au niveau de l'application mobile et tant que le token est présent localement, l'application fait appel aux routes de GeoNature avec ce token. Si en retour elle reçoit une 401, alors l'application n'a plus qu'à notifier l'utilisateur que la session est expirée (et donc de relancer l'authentification).
Et c'est de la responsabilité du backend de GeoNature de s'assurer que le token est bien valide lors de l'appel à une route protégée.

[DonovanMaillard]

Depuis la version 2.3.0, l'application Occtax-mobile repose sur l'approche "optimiste" décrite ci-dessus par Camille, à savoir que l'application ne fait plus de contrôle de cookies et interroge directement les routes de GéoNature coté serveur. C'est le serveur qui contrôlera si le terminal a une session active ou non, et selon la réponse du serveur le smartphone demandera - ou non - une connexion.
Cette authentification n'est requise que pour les phases de synchronisation des données. Il est donc possible de saisir avec les données disponibles sur le terminal (dernière synchro) en l'absence de connexion.

L'idée est donc de ne plus faire la validation du cookie au niveau de l'application mobile et tant que le token est présent localement, l'application fait appel aux routes de GeoNature avec ce token. Si en retour elle reçoit une 401, alors l'application n'a plus qu'à notifier l'utilisateur que la session est expirée (et donc de relancer l'authentification).
Et c'est de la responsabilité du backend de GeoNature de s'assurer que le token est bien valide lors de l'appel à une route protégée.