Development #28643

Pas de persitance des cookies lors de la vérifiaction de la disponiblité ou dans un shell

Ajouté par Emmanuel Cazenave il y a 7 jours. Mis à jour il y a 5 jours.

Statut:NouveauDébut:05 déc. 2018
Priorité:NormalEchéance:
Assigné à:-% réalisé:

0%

Catégorie:-
Version cible:-
Patch proposed:Non

Description

Que j'aurais pu aussi intituler "planitech : check_status innopérant".

On a des cookies depuis #27654, mais vu l'implémentation, pas de persistance cookie lors des appels à availability depuis un cron ou un shell, le check_status de planitech essaie de s'authentifier (et il a besoin de cookie), boum.

J'hésite entre assurer la persistance des cookies dans cette situation ou revoir le check_status de planitech (qui pourrait juste commencer la danse d'authentification sans la finir, et considérer que ça suffit comme ça pour dire que le service est 'up').


Demandes liées

Lié à Passerelle - Bug #28651: planitech: revoir le echeck_status Résolu (à déployer) 05 déc. 2018

Historique

#1 Mis à jour par Benjamin Dauvergne il y a 7 jours

Je dirai d'assurer la persistance des cookies dans availability() si cookiejar n'est pas là, crée le.

#2 Mis à jour par Thomas Noël il y a 7 jours

J'ai en parallèle dit oralement à Emmanuel que le check_status pouvait aussi se limiter à un check minimal (planitech "à l'air d'être là"). Parce qu'à l'usage les cas de panne, à 99%, c'est le réseau HS, la machine éteinte, du 404/500...

#3 Mis à jour par Benjamin Dauvergne il y a 7 jours

On fait bien ce qu'on veut pour planitech, mais dans l'absolu quand on écriera d'autre check_status() c'est bien de se dire qu'on reste dans les mêmes conditions que celles d'un endpoints, sinon ça devient compliqué pour rien.

#4 Mis à jour par Emmanuel Cazenave il y a 7 jours

  • Sujet changé de Pas de persitance des cookies lors de la vérifiaction de la disponiblité à Pas de persitance des cookies lors de la vérifiaction de la disponiblité ou dans un shell
  • Tracker changé de Bug à Development

Dans un shell pour faire mumuse avec son connecteur, c'est la même histoire.

Et je ressort https://dev.entrouvert.org/issues/27654#note-10 de mon chapeau, qui nous aurait évité ce ticket.

#5 Mis à jour par Emmanuel Cazenave il y a 7 jours

  • Lié à Bug #28651: planitech: revoir le echeck_status ajouté

#6 Mis à jour par Benjamin Dauvergne il y a 7 jours

Emmanuel Cazenave a écrit :

Dans un shell pour faire mumuse avec son connecteur, c'est la même histoire.

Et je ressort https://dev.entrouvert.org/issues/27654#note-10 de mon chapeau, qui nous aurait évité ce ticket.

Qu'est qui empêche de mettre l'implémentation de def session() à la place de def requests() ?

#7 Mis à jour par Emmanuel Cazenave il y a 5 jours

Benjamin Dauvergne a écrit :

Emmanuel Cazenave a écrit :

Dans un shell pour faire mumuse avec son connecteur, c'est la même histoire.

Et je ressort https://dev.entrouvert.org/issues/27654#note-10 de mon chapeau, qui nous aurait évité ce ticket.

Qu'est qui empêche de mettre l'implémentation de def session() à la place de def requests() ?

Ça viendrait contrarier #24619, mais son utilité semble discutable.

#8 Mis à jour par Frédéric Péters il y a 5 jours

Ça viendrait contrarier #24619, mais son utilité semble discutable.

Oui, on a depuis vu que la situation n'était pas identique à Combo (où la session se trouvait partagée entre requêtes).

Formats disponibles : Atom PDF