DonovanMaillard
commented
2 years ago 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.
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 (https://github.com/PnX-SI/gn_mobile_occtax/issues/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.
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.