Actuellement, si l'authentification à l'API réussie (api.isogeo.com) mais qu'une erreur 204 est renvoyé suite à une requête de recherche (v1.api.isogeo.com), le plugin va lancer une autre demande d'authentification qui va réussir à nouveau puis une faire une autre requête de recherche qui va échouer et ainsi de suite dans une boucle infinie.
Ce comportement a été observé dans le cas suivant : le fichier config.json est rempli de sorte à pointer vers l'APi en PROD et le fichier quicksearches.json est rempli de sorte à pointer vers l'API en QA (ou inversement). Ainsi, à l'ouverture du plugin, la requête d'authentification faite à l'API en prod réussie le plugin obtient un token valide pour l'API en prod. Mais lorsqu'il fait une requête à l'URL de la recherche par défaut qui point vers l'API en QA, le code 204 est renvoyé car le token n'est pas valide pour l'API en QA. Il fait donc une nouvelle requête d’authentification à l'API en prod puis une nouvelle requête de recherche à l'API en QA qui renvoie un code 204 et ainsi de suite dans une boucle infini. Pendant ce temps, l'interface du plugin reste grisée.
Pour corriger ce comportement, 2 modifications :
410 pour corriger les URLs de recherche indiqués dans le fichier quicksearches.json de sorte à ce qu'ils soient conforme aux URLs d'API indiqués dans le fichier config.json
utiliser l'attribut loopCount du module ApiRequester pour que cette boucle s'arrête au bout de trois itérations dans le cas où les URLs api_base_url et api_auth_url du fichier config.json ne pointent pas vers la même API
Actuellement, si l'authentification à l'API réussie (api.isogeo.com) mais qu'une erreur 204 est renvoyé suite à une requête de recherche (v1.api.isogeo.com), le plugin va lancer une autre demande d'authentification qui va réussir à nouveau puis une faire une autre requête de recherche qui va échouer et ainsi de suite dans une boucle infinie.
Ce comportement a été observé dans le cas suivant : le fichier
config.jsonest rempli de sorte à pointer vers l'APi en PROD et le fichierquicksearches.jsonest rempli de sorte à pointer vers l'API en QA (ou inversement). Ainsi, à l'ouverture du plugin, la requête d'authentification faite à l'API en prod réussie le plugin obtient un token valide pour l'API en prod. Mais lorsqu'il fait une requête à l'URL de la recherche par défaut qui point vers l'API en QA, le code 204 est renvoyé car le token n'est pas valide pour l'API en QA. Il fait donc une nouvelle requête d’authentification à l'API en prod puis une nouvelle requête de recherche à l'API en QA qui renvoie un code 204 et ainsi de suite dans une boucle infini. Pendant ce temps, l'interface du plugin reste grisée.Pour corriger ce comportement, 2 modifications :
410 pour corriger les URLs de recherche indiqués dans le fichier
quicksearches.jsonde sorte à ce qu'ils soient conforme aux URLs d'API indiqués dans le fichierconfig.jsonloopCountdu module ApiRequester pour que cette boucle s'arrête au bout de trois itérations dans le cas où les URLsapi_base_urletapi_auth_urldu fichierconfig.jsonne pointent pas vers la même API