Deconnection, perte des données à synchroniser, données par défaut...

[amandine-sahl]

Nous avons eu des comportements étranges difficilement reproductibles.

Cas 1 : l'utilisatrice n'avait pas utilisé l'application depuis un moment

• jour 1 : elle saisit 3 observations
• jour 2 : elle veut ressaisir une observation et là il n'y a plus les données observateurs, jdd et les 3 relevés qu'elle avait créés précédemment ne sont plus visibles ni dans sync ni dans occtax
• jour 3: elle vient nous voir et nous constatons qu'effectivement il n'y a pas de données à synchroniser. Elle va sur l'application sync qui lui demande de se connecter, elle se connecte et la synchronisation (en mode récupération des données depuis GN2) est lancée. Nous sortons de sync, et là sur l'icône de l'application sync le chiffre "3" apparait (comme par magie), nous cliquons sur sync et les relevés sont bien synchronisés.

Cas 2 : Test cafouilleux suite à ce problème (reproduit 1 seule fois) Après un passage en mode avion, et nous ne savons pas quoi, les données observateurs, jdd ne sont plus accessibles.

Cas 3 : Déconnection de l'utilisateur 1 / Se déconnecter 2 / Créer un relevé 3 / 1 relevé non synchronisé apparait dans occtax (et pas dans les relevés en cours cf issue #78) 4 / 0 relevé non synchronisé sous sync qui n'affiche pas la page d'authentification 5 / Authentification de l'utilisateur 6 / Toujours aucun relevé à synchronisé dans sync (alors qu'il y en a 1 présent dans occtax) 7 / Fermeture de l'application 8 / 1 relevé non synchronisé sous sync

[sgrimault]

Bonjour @amandine-sahl Je ferai des tests complémentaires de mon coté, notamment sur le comportement de la gestion des relevés à synchroniser si l'utilisateur n'est pas connecté.

[joelclems]

je ne sais pas si ça a sa place ici mais avec la version 1.1.4.dev j'ai le comportement suivant

• connecté mais non authentifié
• quand j'ouvre l'appli sync il tente une synchronisation et affiche Erreur serveur
  • cause erreur 403 sur l'adresse des relevés (non authentifié)

il faudrait peut être rediriger vers la page de connexion dans ce cas

[sgrimault]

Bonjour @joelclems

C'est bien ici pour tout ce qui touche à la synchronisation des données depuis GeoNature. Concernant l'erreur, l'application n'attrape que les erreurs 401 (non authentifié sur une ressource demandée). Une erreur 403 veut simplement dire que l'utilisateur connecté n'a pas les droits suffisants sur la ressource en question.

Auriez vous la possibilité de me fournir les logs de l'application "Sync" (logcat) ?

[joelclems]

J'ai par exemple ces lignes là

02-24 19:16:12.302 8435 8579 D OkHttp : --> POST [ https://gngua.brgm-rec.fr/geonature/api/occtax/releve | https://gngua.brgm-rec.fr/geonature/api/occtax/releve ] (1478-byte body)
02-24 19:16:12.610 8435 8579 D OkHttp : <-- 403 [ https://gngua.brgm-rec.fr/geonature/api/occtax/releve | https://gngua.brgm-rec.fr/geonature/api/occtax/releve ] (307ms, 18-byte body)

du coté serveur j'avais Invalid Token : BadSignature

pour être plus précis je m'étaitsconnecté une première fois entre temps j'ai du redemarré les appli (GN, TH et UH) je ne sais pas si les token on une durée de validité ou si c'est le redemarrage qui est en cause

[joelclems]

GN peux sortir une erreur 403 si on est pas connecté par exemple

https://gngua.brgm-rec.fr/geonature/api/gn_commons/modules

[sgrimault]

Le cookie a une durée de validité (configurable coté GeoNature ?) et l'application de synchronisation le transmet à chaque requête faite lors de la synchronisation. Si une requête tombe en erreur, la synchronisation s'arrête et l'utilisateur est redirigé vers la page de login (en cas d'erreur 401 uniquement).

Il y a eu des changements récemment sur GeoNature ? Par exemple, sur l'instance de demo je n'ai plus d'erreurs sur les routes protégées, même non connecté avec une simple page Web en guise réponse :

• POST -> /api/occtax/releve
• GET -> /api/gn_commons/modules (cette URL n'est pas consommée par l'application de synchronisation)

Idéalement, il faudrait que ces routes soient protégées avec les erreurs suivantes :

• 400 si la requête est invalide (par exemple lors du POST d'un relevé et que ce dernier s'avère être incomplet ou non valide selon GeoNature)
• 401 si on n'est pas connecté (cookie expiré par exemple)
• 403 si l'utilisateur connecté n'a pas les droits suffisants pour accéder à la ressource demandée
• 404 si la ressource demandée n'existe pas

[TheoLechemia]

Il y a effectivement eu un changement 2.6. Si on appel une route de l'API depuis le backend (avec comme header accept: application/json) alors il y a bien le comportement attendu: 401 si non connecté, 403 si non autorisé. Si on appel la route depuis le navigateur, il y a une redirection vers la page de login à la place de la 401.

[sgrimault]

C'est déjà le cas côté client GeoNature de l'application de synchronisation. Toutes les requêtes jouées ont le header Accept: application/json.

Il y a effectivement eu un changement 2.6. Si on appel une route de l'API depuis le backend (avec comme header accept: application/json) alors il y a bien le comportement attendu: 401 si non connecté, 403 si non autorisé. Si on appel la route depuis le navigateur, il y a une redirection vers la page de login à la place de la 401.

[DonovanMaillard]

A priori à jour sur ces questions. @sgrimault, @amandine-sahl c'est OK pour fermer ce ticket ?

[sgrimault]

@DonovanMaillard Ok pour moi :)