Produits Entr'ouvert » Mandaye

J'arrive pas très bien à comprendre ce qui se met dans replay_condition.

Aussi, l'idée générale, c'est dans le cadre de la création d'une liaison "directement" depuis le portail citoyen (i.e. #6068) ? Ce serait le point "donc webservice mandaye pour prendre les données et les vérifier (tenter une authent sur le service)" ?

J'arrive pas très bien à comprendre ce qui se met dans replay_condition.

Aussi, l'idée générale, c'est dans le cadre de la création d'une liaison "directement" depuis le portail citoyen (i.e. #6068) ? Ce serait le point "donc webservice mandaye pour prendre les données et les vérifier (tenter une authent sur le service)" ?

?

J'ai poussé ma branche review sur le dépôt distant et redmine à automatiquement changé le statut des tickets. Je n'ai rien poussé sur le master que ca soit pour mandaye ou mandaye-cam. Bref j'ai changé le statut des tickets manuellement.

J'arrive pas très bien à comprendre ce qui se met dans replay_condition.

Ca permet de mettre un test pour savoir si le rejeu a échoué ou réussi.

Aussi, l'idée générale, c'est dans le cadre de la création d'une liaison "directement" depuis le portail citoyen (i.e. #6068) ? Ce serait le point "donc webservice mandaye pour prendre les données et les vérifier (tenter une authent sur le service)" ?

Oui c'est très exactement ça. Mais ce patch ne gère que la partie test des credentials via un webservice json.

Jérôme Schneider a écrit :

J'arrive pas très bien à comprendre ce qui se met dans replay_condition.

Ca permet de mettre un test pour savoir si le rejeu a échoué ou réussi.

Tu aurais un exemple ? Voir comment ça se factorise avec ce qui existe j'imagine déjà niveau succès de rejeu…

Aussi, l'idée générale, c'est dans le cadre de la création d'une liaison "directement" depuis le portail citoyen (i.e. #6068) ? Ce serait le point "donc webservice mandaye pour prendre les données et les vérifier (tenter une authent sur le service)" ?

Oui c'est très exactement ça. Mais ce patch ne gère que la partie test des credentials via un webservice json.

Il y a une question d'architecture que je commence à me poser; dans quelle mesure on ne gagnerait pas à avoir un /__mandaye/ (ou autre) derrière lequel avoir les webservices, mais aussi les fichiers statiques, et tout ça pourrait être du django normal; je me demande si ça n'aiderait pas dans le développement, le bas niveau de reverse-proxying comme aujourd'hui, mais les trucs de haut niveau dans django.

Frédéric Péters a écrit :

Jérôme Schneider a écrit :

J'arrive pas très bien à comprendre ce qui se met dans replay_condition.

Ca permet de mettre un test pour savoir si le rejeu a échoué ou réussi.

Tu aurais un exemple ? Voir comment ça se factorise avec ce qui existe j'imagine déjà niveau succès de rejeu…

Une condition c'est par exemple response.code == 302 ou "Connecté" in response.msg.

Ce qui serait plus clair et plus sûr ce serait déjà dans le eval(condition) de spécifier explicitement un dictionnaire de variables locales pour éviter les incertitudes sur ce qu'on peut faire, par exemple eval(condition, {'response': response}) et à terme je verrai plutôt le remplacement de ce système par une fonction avec une signature précise, en supportant l'ancien système pour compatibilité.

   def condition(response : HttpResponse) -> bool
       return ....

Aussi, l'idée générale, c'est dans le cadre de la création d'une liaison "directement" depuis le portail citoyen (i.e. #6068) ? Ce serait le point "donc webservice mandaye pour prendre les données et les vérifier (tenter une authent sur le service)" ?

Oui c'est très exactement ça. Mais ce patch ne gère que la partie test des credentials via un webservice json.

Il y a une question d'architecture que je commence à me poser; dans quelle mesure on ne gagnerait pas à avoir un /__mandaye/ (ou autre) derrière lequel avoir les webservices, mais aussi les fichiers statiques, et tout ça pourrait être du django normal; je me demande si ça n'aiderait pas dans le développement, le bas niveau de reverse-proxying comme aujourd'hui, mais les trucs de haut niveau dans django.

Ça demanderait déjà de faire de mandaye un projet Django ensuite on pourrait l'envisager; ce sera pour un autre ticket.

Une condition c'est par exemple response.code == 302 ou "Connecté" in response.msg.

Ok, donc avant on avait quelque chose de cet acabit :

        {
            'path': r'/mandaye/login$',
            'method': 'GET',
            'response': {
                'auth': 'login',
                'values': {'condition': 'response.code==302'},
                },
            },

Et l'idée ici est de déplacer la condition vers la racine du mapper et la nommer replay_condition; c'est bien ça ?

Dans le patch, il y a déjà duplication des lignes "# XXX: to be removed test for compability only" et suivantes (jusqu'au eval()), elles pourraient aller dans une méthode verify_replay() ?

Ça demanderait déjà de faire de mandaye un projet Django ensuite on pourrait l'envisager; ce sera pour un autre ticket.

Ça me semble une question opportune en ce moment où ce patch commence l'ajout de webservices, plutôt qu'avoir à défaire par la suite.

Frédéric Péters a écrit :

Ça me semble une question opportune en ce moment où ce patch commence l'ajout de webservices, plutôt qu'avoir à défaire par la suite.

On peut en discuter sans souci, mais je me disais que la somme de travail pour aller vers cela est bien supérieure à ce qui était prévu pour cette simple fonctionnalité. Mais si elle n'est par urgente on peut la décaler et mettre ne priorité un portage au dessus de Django.

Dans ce cas on pourrait regarder du coté d'un bibliothèque d'intégration entre des applications WSGI et Django¹, où à l'inverse faire de l'application WSGI de Django une vue de mandaye.

[1]: https://pythonhosted.org/twod.wsgi/embedded-apps.html

Benjamin écrivait : "Ce qui serait plus clair et plus sûr ce serait déjà dans le eval(condition) de spécifier explicitement un dictionnaire de variables locales pour éviter les incertitudes sur ce qu'on peut faire, par exemple eval(condition, {'response': response}) [...]"; mais comme ça concerne le code de backward compatibility, on ignore, ok.