Erreur serveur (version 0.2.1)

ClaireLagaye commented 4 years ago

J'ai déployé un Geonature v2 pour le PNV qui a l'air d'être à peu près fonctionnel. J'ai récupéré users et taxons de mon Geonature v1 et mes requêtes fonctionnent bien, notamment les taxons et users http://151.80.250.142/taxhub/api/taxref/ http://151.80.250.142/geonature/api/synthese/color_taxon http://151.80.250.142/geonature/api/users/roles En installant Sync, j'ai mis comme URl du serveur http://151.80.250.142/ Mais ça ne fonctionne pas "Erreur serveur"

log_sync.txt

ClaireLagaye commented 4 years ago

Toujours la même erreur avec mon serveur geonature 2, est-ce lié à l'URL/IP? http://151.80.250.142/taxhub/ pour Taxhub http://151.80.250.142/geonature pour Geonature Les deux applis et leur API semblent bien fonctionner mais quand je lance Sync j'ai une erreur serveur log_sync.txt

sgrimault commented 4 years ago

@ClaireLagaye Pourriez vous me communiquer un compte de test sur votre instance ? Coté logs, je n'ai pas grand chose (juste qu'il y a un souci coté GeoNature, rien de plus).

ClaireLagaye commented 4 years ago

@sgrimault Pour l'instance http://151.80.250.142/geonature , vous pouvez utiliser testdev/testdev comme compte de test

sgrimault commented 4 years ago

@ClaireLagaye Merci, j'ai oublié aussi de vous demander la valeur du paramètre application_id, obligatoire lors de l'authentification.

ClaireLagaye commented 4 years ago

@sgrimault application_id = 14 pour geonature chez nous

sgrimault commented 4 years ago

@ClaireLagaye Premier test, lors de l'appel à la route /api/meta/datasets, une fois connecté sur votre instance, j'ai cette erreur suivante :

GET ->/api/meta/datasets : erreur 403

"User \"1000207\" cannot \"R\" in module/app/object \"GEONATURE\""

camillemonchicourt commented 4 years ago

En effet, là j'ai du mal à voir si c'est le GeoNature qui a un problème, ou juste le compte testdev qui n'a pas les droits nécessaires pour accéder aux infos. Il faut commencer par investiguer la question du CRUVED de l'utilisation testdev.

ClaireLagaye commented 4 years ago

Je n'avais en effet rien spécifié dans le CRUVED de cet user, c'est fait et je n'ai pas d'erreurs pour GET -> /api/meta/datasets : erreur 403

sgrimault commented 4 years ago

Il ne reste plus que la route pour récupérer les utilisateurs. Actuellement la route est défini comme suit :

GET -> /api/users/menu/1 : erreur 404

Et je suppose que ce n'est plus la bonne valeur pour l'identifiant du menu de votre coté ?

camillemonchicourt commented 4 years ago

Oui bien vu. C'est pour ça que cet ID de liste d'utilisateurs doit être un paramètre.

ClaireLagaye commented 4 years ago

Oui en effet, ça doit donc être un paramètre Ici, c'est 8 /api/users/menu/8

sgrimault commented 4 years ago

Je ferai les ajustements pour ajouter ces paramètres dans le fichier settings_sync.json :

/api/users/menu/{user_menu_id}
/api/taxref/allnamebylist/{taxref_list_id}

Il n'y a que ces deux routes qui restent un peu particulières par rapport aux autres.

camillemonchicourt commented 4 years ago

OK et si jamais on a besoin de modifier une route un peu particulière, j'avais compris qu'on pouvait toutes les modifier quelque part dans une conf, mais je m'embrouille peut-être ?

@sgrimault indique :

L'application "Sync" embarque un client GeoNature (https://github.com/PnX-SI/gn_mobile_core/tree/develop/sync/src/main/java/fr/geonature/sync/api) dans lequel sont notamment déclarés les routes appelées coté GeoNature. Ce client est appelé par le module de synchronisation (https://github.com/PnX-SI/gn_mobile_core/tree/develop/sync/src/main/java/fr/geonature/sync/sync), pour notamment faire le mapping et importer les données dans la base de données locale. Ensuite, ces données sont exposées aux autres applications par un "provider" (fournisseur de données) (https://github.com/PnX-SI/gn_mobile_core/tree/develop/sync/src/main/java/fr/geonature/sync/data).

sgrimault commented 4 years ago

@camillemonchicourt Oui on avait évoqué ce sujet il y a quelques temps, mais de mon coté j'ai des routes paramétrables selon le contexte. Par exemple pour les valeurs par défaut de la nomenclature :

/api/{{module}}/defaultNomenclatures

où module est le nom (code) du module pour lequel on souhaite récupérer ces valeurs (ici occtax).

De plus si on arrive à devoir changer totalement la route (évolution coté GeoNature ?) ça impliquera de toute façon des ajustements coté application de synchronisation pour parser et charger ces nouvelles données.

Donc actuellement, j'ai ceci comme paramètres additionnels (mais obligatoire :) ):

id_application (lors de l'authentification)
user_menu_id (pour sélectionner le "bon" menu pour récupérer la base des utilisateurs)
taxref_list_id (pour sélectionner la "bonne" liste pour récupérer la base des taxons)

ClaireLagaye commented 4 years ago

@sgrimault Bonjour, Je viens d'installer la nouvelle version du l'appli de Synchro. J'ai toujours le même problème, impossible de me connecter à mes instances Voilà ce que j'ai dans le fichier de settings { "application_id": 14, "users_menu_id": 8, "taxref_list_id": 500 } Je rentre les URL de geonature et taxhub dasn Sync http://151.80.250.142/taxhub/ pour Taxhub http://151.80.250.142/geonature pour Geonature

Et quand j'essaye de me logger (avec testdev/testdev ou mes comptes admin généraux), j'obtiens une erreur serveur

v. log log_sync.txt

sgrimault commented 4 years ago

@ClaireLagaye Par défaut et par sécurité, Android refuse tout appel en clair (non chiffré) sur un serveur distant. J'avais déjà ajouté une exception de sécurité juste en mode debug pour l'instance de démonstration de GeoNature pour que l'on puisse l'utiliser. Je vais du coup ajouter une exception globale (toujours en mode debug) pour que les appels puissent malgré tout se faire en clair. Mais à terme, il faudrait quand même configurer les instances en HTTPS uniquement.

J'ai pu réaliser de mon coté une synchronisation sur votre instance :)

J'ai rajouté aussi une note concernant https://github.com/PnX-SI/gn_mobile_occtax/issues/37 de façon à pouvoir attraper toutes les informations relatives aux taxons par zone géographique. Cette route peut potentiellement remonter beaucoup plus d'informations que la route des taxons.

ClaireLagaye commented 4 years ago

@sgrimault Merci pour ce travail, ça permet au moins de tester toutes les possibilités! L'appli de synchronisation fonctionne enfin ici. Dans le fichier de settings j'ai spécifié l'id de liste 500 pour mes taxons. Cette liste comporte 5132 noms de taxons (http://151.80.250.142/taxhub/#!/listes/500). Mais quand je lance la synchronisation, la console m'annonce 9179 taxons synchronisés. D'où peut bien venir ce nombre?

sgrimault commented 4 years ago

@ClaireLagaye Pour information, la route appelée pour charger les taxons est /api/taxref/allnamebylist/500, sur laquelle je prends les 10000 premiers de la liste (limit=10000 en attendant que la correction soit déployée). L'attribut cd_ref est utilisé comme identifiant interne coté application de synchronisation et il se trouve qu'il y a des doublons dans cette liste. Je pense que ce n'est pas normal ?

TheoLechemia commented 4 years ago

Si, c'est normal, le cd_ref n'est pas unique. Les synonymes ont tous le même cd_ref. C'est le cd_nom qui est unique

sgrimault commented 4 years ago

Au temps pour moi, coté application de synchronisation, c'est bien l'attribut cd_nom qui est utilisé comme identifiant interne.

Exemple de "doublon" coté Vanoise :


[
    {
        "search_name": "Rouvet blanc =  <i> Osyris alba L., 1753</i> - [ES - 111840]",
        "nom_valide": "Osyris alba L., 1753",
        "cd_nom": 111840,
        "group2_inpn": "Angiospermes",
        "cd_ref": 111840,
        "lb_nom": "Osyris alba",
        "id_liste": 500,
        "regne": "Plantae"
    },
    {
        "search_name": "Osyris alba =  <i> Osyris alba L., 1753</i> - [ES - 111840]",
        "nom_valide": "Osyris alba L., 1753",
        "cd_nom": 111840,
        "group2_inpn": "Angiospermes",
        "cd_ref": 111840,
        "lb_nom": "Osyris alba",
        "id_liste": 500,
        "regne": "Plantae"
    }
]

PnX-SI / gn_mobile_core

Erreur serveur (version 0.2.1) #5