Produits Entr'ouvert » Mandaye

Ça me semble fragile de viser les messages d'erreur, particulièrement de manière si précise, il n'y a pas une différence plus fondamentale entre une authent réussie et authent ratée ? (genre une réussite fait une redirection vers le Default.aspx alors qu'un échec reste sur le Connect.aspx, ou un cookie positionné)

On était partie sur ça au départ, puis on en a discuté et on en avait conclu que le mieux c'était de rechercher les messages d'erreurs sur la page.

voici le lien du ticket en question https://dev.entrouvert.org/issues/9415#note-4

Ah, désolé, je me suis mal fait comprendre :

Le point important pour finir : j'avais suggéré que l'expression d'évaluation de succès (/ d'échec) soit paramétrable (comme locators), ici c'est un systématique uri !== input.homepath, il ne me semble pas que ça tienne la route. (pas bien difficile d'imaginer un site qui n'envoie pas vers la racine après une authent à succès) (ni une authent qui a lieu à la racine et dont l'échec reste sur la racine).

Ce que je veux dire là, c'est que ça doit être paramétrable, parce qu'il peut y avoir des sites où on ne pourrait pas se baser sur l'URL pour déterminer un succès ou un échec; je ne voulais pas dire que c'était une information à systématiquement négliger.

Une authent réussie finit toujours par un 302 sur Duonet, c'est cela qu'il faut tester.

Ca été une piste aussi. Le souci était de capturer la bonne redirection avec PhantomJS (http://phantomjs.org/api/webpage/handler/on-resource-received.html). Seul souci, duenot charge 1 Millions de js/css ... ce qui rend la capture de cette redirection difficile.

• normalement le premier onResourceReceived devrait être soit un 200 (page HTML) soit un 302, ensuite on doit pouvoir comparer l'URL de la ressource à celle chargé pour ne pas confondre avec les ressources (JS, CSS, etc...)
• il existe un autre signal onNavigationRequested[1], à priori si il est appelé après le open, c'est qu'il y a eu une redirection.

• https://code.google.com/p/phantomjs/issues/detail?id=185
• https://gist.github.com/amenzhinsky/5245915
• https://gist.github.com/amenzhinsky/5245915

C'est à toi de tester les différentes méthodes et de trouver la bonne.

¹ http://phantomjs.org/api/webpage/handler/on-navigation-requested.html

Il y a un truc que je ne pige pas, dans #9145 le test au début, il était bel et bien fait sur l'URL sur laquelle l'usager/phantomjs se trouvait après un submit. Il a juste (par mauvaise compréhension entre Josué et moi) été remplacé par une vérif sur le contenu de la page. Mais donc, le test sur l'URL il a existé et fonctionnait bien, tout simplement, avant. Je ne vois pas où je me perds.

Revenons à ce code alors si il fonctionne.

Revenons à ce code alors si il fonctionne.

Oui, mais posé dans la fonction de vérification injectée comme actuellement.

Ok. Est ce que on a pas plus de souplesse à verifier le succès de l'authent depuis un script ? Enfin personnellement je pense que avec un script on peut vérifier rechercher ce que l'on veut : rechercher des messages d'erreurs, vérifier une url ...

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

Revenons à ce code alors si il fonctionne.

Oui, mais posé dans la fonction de vérification injectée comme actuellement.

Plutot pour cette solution

Comme je ne sais pas de quoi vous parlez, je donne mon accord par défaut.

Il y'a dans le setting un parametre SITE_AUTH_CHECKER http://git.entrouvert.org/mandayejs.git/tree/README#n89

Ah ok, et ce serait pas plus sûr de faire:

window.mandaye_auth_success = window.location.href.indexOf('/Default.aspx') != -1

ou alors peut-être mieux:

window.mandaye_auth_success = window.location.href.indexOf('/Connect.aspx') == -1

(j'aime bien mettre des préfixes j'ai toujours peur d'une collision, et comme ça les gens de duonet qui testeraient leur application sauront d'où ça vient).