Perl: POST formulaire, attention je vous pose une colle !
Fermé
LezardMoo
Messages postés
554
Date d'inscription
mercredi 5 janvier 2011
Statut
Membre
Dernière intervention
21 janvier 2015
-
25 mars 2014 à 11:36
LezardMoo Messages postés 554 Date d'inscription mercredi 5 janvier 2011 Statut Membre Dernière intervention 21 janvier 2015 - 26 mars 2014 à 11:09
LezardMoo Messages postés 554 Date d'inscription mercredi 5 janvier 2011 Statut Membre Dernière intervention 21 janvier 2015 - 26 mars 2014 à 11:09
A voir également:
- Perl: POST formulaire, attention je vous pose une colle !
- Denon perl pro test - Guide
- Active perl - Télécharger - Édition & Programmation
- Can't open perl script "makefile.pl": no such file or directory - Forum Perl
- Perl ftp - Forum Perl
- Perl xampp ✓ - Forum Linux / Unix
1 réponse
[Dal]
Messages postés
6174
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
2 février 2024
1 083
25 mars 2014 à 14:30
25 mars 2014 à 14:30
Salut LezardMoo,
Tu pourrais inspecter le trafic http généré par l'usage de l'applet Java (en espérant que ce n'est pas du https), et répliquer son fonctionnement pour faire la même chose depuis Perl avec WWW::Mechanize.
Si son fonctionnement est trop opaque, je ne crois pas que Perl puisse intéragir avec la machine virtuelle Java pour piloter le fonctionnement de l'applet (et je ne crois pas que cela soit faisable non plus dans d'autres langages d'ailleurs, y compris Java, mais tu pourrais poser la question à des développeurs Java).
Une autre solution serait de créer un script automatisant l'envoi de touches du clavier à la fenêtre du navigateur. Tu n'auras pas trop de contrôle, car les éléments d'interface ne seront certainement pas identifiables, mais au moins tu pourras envoyer des touches "à l'aveugle" (naviguer avec tabulations, etc.).
Tu peux faire cela avec Perl, avec Win32-GuiTest pour Windows ou X11::GUITest pour Linux.
Ou tu peux utiliser des outils dédiés à ce type de choses.
Par exemple :
- sous Windows Autoit peut faire cela
- sous Linux, Autokey-gtk.
Ou alors, tu te plains à l'éditeur du logiciel, ou au constructeur de l'ipbx, qui fait des interfaces à la noix, et qui a peut-être un outil pour faire ce genre de choses, ou une solution maison à te proposer pour un usage "sérieux" de leur produit.
Dal
Tu pourrais inspecter le trafic http généré par l'usage de l'applet Java (en espérant que ce n'est pas du https), et répliquer son fonctionnement pour faire la même chose depuis Perl avec WWW::Mechanize.
Si son fonctionnement est trop opaque, je ne crois pas que Perl puisse intéragir avec la machine virtuelle Java pour piloter le fonctionnement de l'applet (et je ne crois pas que cela soit faisable non plus dans d'autres langages d'ailleurs, y compris Java, mais tu pourrais poser la question à des développeurs Java).
Une autre solution serait de créer un script automatisant l'envoi de touches du clavier à la fenêtre du navigateur. Tu n'auras pas trop de contrôle, car les éléments d'interface ne seront certainement pas identifiables, mais au moins tu pourras envoyer des touches "à l'aveugle" (naviguer avec tabulations, etc.).
Tu peux faire cela avec Perl, avec Win32-GuiTest pour Windows ou X11::GUITest pour Linux.
Ou tu peux utiliser des outils dédiés à ce type de choses.
Par exemple :
- sous Windows Autoit peut faire cela
- sous Linux, Autokey-gtk.
Ou alors, tu te plains à l'éditeur du logiciel, ou au constructeur de l'ipbx, qui fait des interfaces à la noix, et qui a peut-être un outil pour faire ce genre de choses, ou une solution maison à te proposer pour un usage "sérieux" de leur produit.
Dal
25 mars 2014 à 18:32
Alors en fait ma boite a déjà acheté un outil (fait meme par le constructeur des ipbx en question, mais sous un autre nom) or il apparait que les backups fait avec cette appli ne sont pas valides... soit pas backupé tout court soit backup mais lors de la restauration, echec.
Je suis sur un autre piste, il y aurait un port attaquable en RAW or je crois n'avoir jamais utilisé ce type de connexion, a part dans putty que je n'utilise pas.
Je vais donc chercher dans cette direction, mais je vais aussi explorer les tiennes qui m'interessent.
Merci :)
25 mars 2014 à 18:36
bon courage :-)
25 mars 2014 à 23:53
Modifié par [Dal] le 26/03/2014 à 10:56
Sinon, en production, je n'ai pas non plus de tels bricolages.
Par contre, j'ai eu un pb similaire au tien avec un routeur, qui ne proposait qu'une interface Web avec du javascript, et des requêtes Ajax. J'ai testé des scripts expect qui se loguent sur des routeurs pour intéragir avec l'interface Web. C'est du html et javascript, exécuté avec le navigateur texte elinks qui peut exécuter des scripts ECMA (avec le moteur SpiderMonkey de Gecko).
Cela marche, mais ce n'est cependant pas très robuste.
J'ai fini par utiliser Firebug pour inspecter les cookies, les requêtes http générées, et reproduire le fonctionnement avec un script bash utilisant curl. Et comme cela, cela tourne comme une horloge :-)
Dans ton cas, il faudrait peut-être un sniffeur pour voir passer les requêtes générées par l'applet Java, voire utiliser un outil Java dédié à l'inspection de ce type d'applications. Peut-être quelque chose comme http://www.swingexplorer.com/ (mais je ne suis pas expert en Java) pourrait aussi t'aider, ou un décompilateur Java. Tu devrais poser la question à un spécialiste Java.
Dal
26 mars 2014 à 11:09
Pour décompiler le Java c'est déjà testé avec eclipse mais je n'ai quasiment que des .class
bien compilé donc je n'ai pas réussi à voir grand chose...
Pour le sniffer je pensais me faire un petit poste de TP et prendre le temps de tester tout ca mais... on doit bosser comme des chinois donc pas le temps de me poser dessus :/