Journal Le problème du jour (perlcgi&links).

Posté par  .
Étiquettes : aucune
0
4
mai
2004
Comme dit dans le titre, le problème que j'ai vient d'une page que je suis en train de m'amuser à faire en Perl::CGI. Disons que comme y'a des gens qui utilisent le site sous dillo et links, c'est bien que ça marche avec. J'ai aussi un malheureux utilisateur d'IE -quipeupafairautrement-, moi. M'enfin, les problèmes que j'ai viennent des CSS mal foutus (genre un margin-left négatif dans une liste, bah IE, il aime pas apparemment). Et puis je me fiche que ça marche pas sous IE, au pire, je me fous un links sur ssh et basta.

Bon enfin, revenons à nos moutons. Le site en question comporte une partie administration. Rien de bien folichon. C'est un site de blog, et je suis parti de dotclear (enfin, la bdd a été améliorée et le code a été entièrement refait parce que ça m'amuse).

Bon donc j'ai un index.pl qui va permettre d'aller modifier, ajouter ..., les articles du site. Bon. Cette partie est privée, donc soumise à identification.
J'ai donc un authentif.pl qui se charge de ça. Il balance un petit formulaire avec log//pass classique, et si tout ça correspond, il écrit un cookie comportant login et nu md5 de session (pour l'instant comme c'est en phase de test, c'est le mdp sous md5, histoire de pas me faire chier). Puis il redirige vers index.pl

index.pl, lui, il vérifie (toujours) si y'a un cookie. Si oui, il lit les données dedans.
Si non, il regarde si le client ne serait pas un Dillo-Links user. Si c'est le cas, authentif.pl aura pris le soin de donner login et md5 dans l'url, histoire de pouvoir les récupérer. Donc il les récupère et c'est la fête. Si tout ça n'arrive pas, à priori le client a rien à faire ici, il est redirigé vers authentif.pl


Bon, jusque là, ça marche. Dans le cas normal (mozilla, konqui, notamment), tout fonctionne à merveille.
Le cas de Dillo et de Links me pose toujours problème. En gros, j'ai propagé dans toutes les URLs de la partie privative l'id et le md5 pour ce cas-là. Donc j'ai des URLs de type (avec des paramètres en plus):
./index.pl?id=.....&md5=.....
et dans le cas normal (qui fonctionne super !)
./index.pl?&

Bon. Première page, tout va bien, on se retrouve sur un formulaire (qui a comme url de post : ./index.pl?id=...&md5=... sinon ca serait trop facile de trouver l'erreur)
On le remplit, on valide, et ...

C'est là qu'est le problème : il me perd les données de id et md5. Alors non, je veux pas les mettre en input_hidden. Mais l'erreur est plus marrante. Si je n'utilise pas ce petit truc de passage de paramètres entre authentif et index, Dillo se vautre lamentablement dans une redirection (sans erreur dans les logs d'apache).
Log type de Dillo :

Nav_open_url: Url=>http://localhost/~kim/cgi-bin/ecrire/index.pl<(...)
Dns_server [0]: localhost is 0x80ffb68
Connecting to 127.0.0.1
HTTP warning: Unhandled MIME type: <application/x-perl>

** CRITICAL **: file web.c: line 57 (a_Web_dispatch_by_type): assertion `dw != NULL' failed.

** CRITICAL **: file nav.c: line 119 (Nav_stack_remove): assertion `bw != NULL && idx >=0 && idx < sz' failed.
Nav_open_url: Url=>http://localhost/~kim/cgi-bin/ecrire/authentif.pl?<(...)


Maintenant, on est fort, on connait login et pass :
Nav_open_url: Url=>http://localhost/~kim/cgi-bin/ecrire/index.pl?art=0&id=****&(...)
Connecting to 127.0.0.1

Et tout va bien. On joue avec le formulaire :

HTTP warning: Unhandled MIME type: <application/x-perl>

** CRITICAL **: file web.c: line 57 (a_Web_dispatch_by_type): assertion `dw != NULL' failed.
Nav_open_url: Url=>http://localhost/~kim/cgi-bin/ecrire/authentif.pl?<(...)
WARNING: Cache_stop_client, inexistent client

Et hop, il a perdu les id et md5 ... (enfin on dirait).
Alors j'ai sorti mon gdb, mais comme je suis une merde en C, j'ai cherché un peu ce qui se passait à cette ligne 57 (et avant et après). Il semble que cela provienne de l'absence de quelque chose ... Hmmmmmm cookie sûrement ?
Ha oui mais je vérifie le navigateur avant (if ($client_navig =~ m/^Dillo/) ) et dans ce cas (il arrive bien dans ce cas), il va pas chercher de cookie, et attrape tout seul login et md5. Oui mais il me redirige vers authentif. Donc c'est qu'il ne le fait pas. Grrrr.
NB : même chose avec links (enfin je suppose, il bloque au même endroit, et agit pareil, mais j'ai pas de logs d'erreur)



Donc si y'a une âme charitable qui serait prête à se pencher sur le code et l'erreur en particulier, ça serait hyper cool.

Ha oui ... le code ...
http://www.enseirb.fr/~varaldi/coin/(...)
y'a tout ce que j'ai fait pour le moment, avec notamment ecrire/index.pl et ecrire/authentif.pl, un exemple de fichier de conf, et les classes utiles au bon fonctionnement.
Et je rajoute en prime de quoi générer la base de donnée. Si c'est pas du luxe ... :)
Tout est à mettre dans /cgi-bin sauf les style.css qui vont dans www/ (et qu'il faudra que je remanie un jour).
A priori, je me suis débrouillé pour épurer un peu le code, il est relativement lisible (si on a l'habitude du perl), mais il est pas encore commenté suffisamment.
Logiquement, avec ce que y'a ici, on devrait pouvoir réussir à installer tout ce bordel.


NB : pour ceux qui ont dotclear, depuis que j'ai bidouillé les redacteurs, cette partie est devenue peu compatible avec dotclear (même si ça marche quand même)
NB2 : il me reste encore quelques bugs connus, pas mal de trucs manquent encore pour que ce soit fonctionnel, et OUI, y'a pas d'images, mais c'est fait pour.


D'ailleurs, j'en profite, si vous trouvez des bugs, et tout ... dites-le moi :)
Pour une version en cours d'utilisation, il reste un bug majeur sur l'ajout de commentaire et la gestion des urls et img du format wiki utilisé n'est pas encore testé, donc ne pas m'en tenir rigueur, mais la bêta est ici si vous voulez vous faire une idée : http://www.varaldi.org/cgi-bin/index.pl(...) (attention, le contenu du texte peut choquer, et merci de pas y poster de commentaires de suggestions/rapport de bugs/conneries en tout genre, merci :)).

Autre chose : certains me diront pourquoi en cgi ... simplement parce que j'aime pas le php, l'asp c'est hors de question, le javascript c'est pas mon truc, et j'aime bien le perl. Et puis au moins ... ça change.
Et encore un point : si y'en a que ça intéresse, je pourrai leur fournir les prochaines MàJ :).


Merci, et désolé d'avoir été aussi long.


PS : pour le prochain truc que je ferai, ça sera complètement différent, mais je pense que je vais opter pour une idée que j'ai eu y'a quelques temps, un espèce de gestionnaire de bibliothèque de documents OOo avec gestion des auteurs (et tout ce qui va avec ces META là), en C++/Gtk. Histoire de m'occuper :)
PPS : si des fois que vous ayez une envie pressante de communiquer avec moi, les mails c'est mieux que les commentaires dans certains cas, donc j'ai activé la redirection de dlfp sur mon compte mail habituel, que je lis maintenant presque tous les soirs de la semaine.
  • # rectificatif

    Posté par  . Évalué à 1.

    Et comme je suis magnanime, ou plutôt tête en l'air, j'avais oublié de mettre les sources à dispo, maintenant, c'est fait.
  • # quelques solutions

    Posté par  (site web personnel) . Évalué à 2.

    une solution simple est facile à mettre en oeuvre:
    utiliser un .htaccess
    on récupère ensuite le login dans la variable REMOTE_USER
    le login est le mot de passe peuvent se trouver dans un fichier, dans ldap, une base, ....
    Le problème, c'est pour la déconnection : il faut fermer tous les navigateurs.

    La solution avec cookie est session est ici mal utilisée. En réalité lorsqu'on se logue, un fichier de session doit être créée sur le serveur dans /tmp par exemple avec un nom très aléatoire. On envoie ensuite le cookie avec le numéro de session sur le client puis on fait toutes les authentications avec ce numéro de session, le fichier peut contenir le login et éventuellement d'autres informations comme le mot de passe s'il doit être réutilisé. Lorsqu'on se délogue, on efface le fichier de session.
    Avantage, une fenètre de login en html, un déloguage (!) propre, une gestion possible du temps de connection.
    Problème, supprimer les fichiers de sessions qui restent après crache, fermeture brutale du client, ou oublie de se déloguer.

    Dans les 2 cas ont n'a aucun passage de paramètre dans l'url, qui peuvent être visible ou mémoriser par le navigateur. Le cookie ne contient pas de mot de passe/login. Après il ne reste plus qu'à passer l'authentification en https ....
    • [^] # Re: quelques solutions

      Posté par  . Évalué à 1.

      Ben, si je passe des infos dans l'URL, c'est simplement parce que ... sinon Dillo ou Links ne passent pas.
      Pour les fichiers de sessions, je fais presque pareil, sauf que je met le tout dans une table de ma base. Après tout c'est à peu près pareil.

      Le réel problème que j'ai est que Dillo se moque de mon cookie, il le voit pas, ni rien ...
      Le cookie que j'ai ici ne contient pour l'instant pas le mot de passe, mais son md5, chose que je compte changer ultérieurement d'ailleurs, par un md5 plus "aléatoire"

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.