Produits Entr'ouvert » Mandaye

Pas fan, magie trop fragile. Je verrais plutôt la possibilité de définir une fonction qui doit être vraie avant d'avancer (et exécuter cette fonction toutes les 200ms pendant max 2 secondes, par exemple).

            }
            // check authentication
            check_auth();

Il y a là un problème d'indentation.

Mais sur le fond, quand même, je préférerais qu'un module puisse déclarer sa propre fonction "en état de vérifier l'authent ?", plutôt qu'exécuter le code de vérification de l'authent et de demander à celui-ci de gérer non plus seulement "bon / pas bon" mais également un "ne sais pas trop encore" un peu foireux.

C'est mon idée: le module de l'application dispose d'une fonction supplémentaire en plus de auth_success ou password_change_required qui dit "pas bon" si impossible de vérifier l'authentification.
Et quand c'est bon, ça laisse la main à auth_success et compagnie.

Le nom que je propose dans le patch de plus haut n'est probablement pas terrible, à changer, mais l'idée est la même.

Peut-être que je me perds dans cette nouvelle lecture du patch (c'était il y a dix jours) mais sommairement, là, que l'expiration soit passée (counter > 10) ou que ça soit prêt (loaded), le code de vérification de l'authent est appelé, et doit donc pour moi gérer trois cas (bon / pas bon / oops ça avait pas chargé).

Retour sur la discussion du jour, un peu adapté suite à la lecture du code.

On définit aujourd'hui window.auth_success, on doit pouvoir également définir window.auth_failure. Quand les deux sont présents, s'il n'y a pas un retour positif d'un des deux, on attend un peu genre ¼ de seconde avant de réessayer. (en bout de course si ça n'arrive pas on aura #14606 pour tuer l'affaire).

Aussi, dans les consignes d'écriture de ces fonctions d'évaluations, il faut noter qu'il est mieux de tester l'existence d'un élément, plutôt que l'absence.

ex:

    window.auth_success = function(){
        if ($('#INDEX_TBL_LOGIN').length < 1)
            return true;
        return false;
    }

Retournerait que ça marche en cas de présence de mettons un bug qui retournerait une page blanche; on devrait plutôt avoir l'inverse, genre (en inventant le sélecteur) :

    window.auth_success = function(){
        if ($('#INDEX_TBL_LOGOUT).length)
            return true;
        return false;
    }

Sur une application comme Ermes, on peut directement taper sur des ws :

 
resp = logged_requests.post('https://mediatheques.montpellier3m.fr/DEFAULT/Ermes/Recherche/logon.svc/logon', data={'username': 'whatever', 'password': 'whatever'})

{"errors":[{"data":{"__type":"ObjectCollection:#Archimed.Serialization","badPasswordCount":1,"doCheckAdditionals":false,"checkAdditionalsResult":true},"id":"TPA6+H6iiIlZT0oyliNXCLuaPkU=","msg":"Le mot de passe saisi est incorrect, vérifiez la syntaxe et réessayez.","type":"InvalidCredentials"}],"message":"","success":false,"d":"Anonymous"}

Je pense qu'avec

Reponse en cas de succès

{"errors":[],"message":"","success":true,"d":"entrouvert"}

Je pense qu'en ajoutant une logique simple appel ws pour les applications utilisant des ws (Fred l'avait évoqué une fois je pense) ça devrait marcher. (je fais le test puis je mets à jour le ticket)

Ce que m'embête c'est de devoir gerer les cookies en provenance de requests comme le faisait l'ancien mandaye. Et de mes souvenirs ce n'était pas évident.

L'utilisation de phantomjs semblait apporter la solution de ne plus rien avoir à gerer à ce niveau, juste transférer les cookies.

Suite à la discussion de ce matin, patch à jour prenant en compte la définition de la fonction auth_failure dans chaque application.
Testé sur Ermes et Teamnet.

Patch absent.

Vraiment > 1 et pas >= 1 dans if ($('a.account_logoff').length > 1) et if ($('input[type="password"]#code').length > 1) ?

if (input.auth_failure !== undefined) {
// check authentication failure only if the function is defined
if (!input.auth_success && !input.auth_failure)

Je pense que ça gagnerait à un commentaire bien plus explicite, que le "on fait le taf uniquement si c'est pas undefined" est déjà bien exprimé par la première ligne; que la seconde condition par contre, elle exprime le fait qu'en présence des deux fonctions, si aucune n'est vérifiée, on lache l'affaire et le setInterval viendra rejouer plus tard.

Aussi, sur la situation où on aurait input.auth_success et input.auth_failure, je me dis qu'on doit traiter ça comme une situation d'erreur (et idéalement logguer ça de manière suffisamment critique pour qu'on soit informé parce que ça veut sans doute dire que l'application a changé de comportement).

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

Aussi, sur la situation où on aurait input.auth_success et input.auth_failure, je me dis qu'on doit traiter ça comme une situation d'erreur (et idéalement logguer ça de manière suffisamment critique pour qu'on soit informé parce que ça veut sans doute dire que l'application a changé de comportement).

Dans ce cas on doit revoir la façon dont on écrit les messages en sortie de phantom. Actuellement tout va dans stdout qui est lu par le code python et intepreté comme json.
Benj donnait une piste ce matin : https://github.com/ariya/phantomjs/blob/master/examples/stdin-stdout-stderr.js . On devrait passer les messages à logguer dans stderr et le stdout uniquement pour le json à interpreter.

Non; à nouveau ne mélangeons pas, pour le micmac de sortie, on a #14881. Ici, je dis qu'il faudrait arrêter le traitement sur une erreur, et que celle-ci soit logguée du côté Python, quand le code affirme que ça a à la fois été un succès et un échec.

Après des tests sur d'autres projets en prod comme le conservatoire de Vincennes et Teamnet à Meyzieu je découvre que si la fonction auth_failure n'est pas définie pour chaque application (et dans ce cas je lui attribue undefined) phantomjs l'interprete comme null et la condition d'arrêt de la fonction check_auth n'est pas respectée. Cela a comme effet une boucle pour les codes saisis éronnés.

Quand même du mal à piger cette explication sans précision sur la condition dont tu parles.

Tu dis que le "return undefined;" du code; quand on passe dedans et bien malgré tout input.auth_failure == null ?

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

Tu dis que le "return undefined;" du code; quand on passe dedans et bien malgré tout input.auth_failure == null ?

C'est ça.
Je detecte ça en voyant le code du if :

if (input.auth_failure !== undefined) {
 ...
}

Et donc, pour comprendre, isoler les choses, jouer avec les types, genre :

var page = require('webpage').create();
var input = Object();

page.open('http://localhost', function(status) {
    input.auth_failure = page.evaluate(function(){
       return undefined;
    });
    if (input.auth_failure == true) console.log('==true');
    if (input.auth_failure == false) console.log('==false');
    if (input.auth_failure == undefined) console.log('==undefined');
    if (input.auth_failure == null) console.log('==null');
    if (input.auth_failure === undefined) console.log('===undefined');
    if (input.auth_failure === null) console.log('===null');
    if (input.auth_failure != undefined) console.log('!=undefined');
    if (input.auth_failure != null) console.log('!=null');
    if (input.auth_failure !== undefined) console.log('!==undefined');
    if (input.auth_failure !== null) console.log('!==null');

    phantom.exit();
});

Plutôt que dire "on essaiera plus tard de comprendre".

        if result.get('error'):
            logger.error('Error occured: %s' % result.get('reason'))

On peut juste logguer le message; "error occured" c'est implicite. (et si la raison seule n'est pas top, on a la main dans le js pour mieux l'écrire).

À part ça, si les tests sont concluants, je me dis qu'on peut y aller.