Pour la réparation d'appareils, typiquement, la notice officielle ne mentionne que des cas débiles, genre "la lumière ne fonctionne plus -> remplacer l'ampoule", "l'appareil ne s'allume pas -> vérifier qu'il est bien branché", "l'appareil est branché et ne s'allume pas -> contacter le service après-vente". C'est ça, l'information qu'on a toujours eu, de la m***. Pour obtenir les données techniques, il fallait contacter le fabriquant et espérer sa bonne volonté, ou bien payer pour accéder aux protocoles de réparation destinés aux professionnels. Bref, je ne crois pas du tout au monde idyllique d'avant les LLM où il était facile de trouver des informations de qualité sur n'importe quel sujet, je crois que c'est un monde fantasmé.
Soit ton LLM a "trouvé" la réponse quelque part dans ses données d'entraînement, et donc elle existait bien quelque part, très probablement sur internet ; soit il l'a inventée, et donc c'est une réponse bidon qui ne sera vraie que sur un coup de chance.
Donc je ne vois pas quel problème ça résout. Au lieu de passer du temps à chercher une réponse, tu vas avoir une réponse tout de suite, et puis ensuite tu vas passer autant de temps qu'avant à vérifier si cette réponse est vraie. Tu as peut-être l'impression de ne pas avoir galéré et d'avoir été mis tout de suite sur une piste.
Pour reprendre l'exemple de la recherche d'itinéraire, c'est équivalent à partir dans une direction à l'instinct sans regarder un plan, se rendre compte que c'était pas la bonne direction, et dire "oui, mais au moins j'ai bougé". La direction est plus important que la vitesse, et les LLM te donne de la vitesse.
Je parlais de rétractation parce que j'ai un autre problème: j'ai un client sur mon téléhhone, un sur mon pc pro et un sur mon pc perso par exemple. Toutes les requêtes arrivent sur tous les clients. Une fois que j'ai accepté la requête, je n'ai pas besoin que des fenêtres de demande persistent sur les 2 autres clients qui étaient en ligne à ce moment là. Donc ce serait bien que le serveur puisse invalider ces requêtes.
Et même avec un seul client, si la requête http fait un timeout avant d'avoir reçu une réponse, invalider la demande de confirmation serait raisonable aussi.
Plusieurs différents hrojets, j'ai par exemple travaillé sur des réseaux de talkie walkie avec des antennes relais qui sont déployées en fonction des endroits où il y a une bonne réception radio et pas en fonction de l'accessibilité routière; ça peut être également des projets déployés sur des sites industriels, où il y a plein de monde autour, mais qui ne sont pas des personnes à qui on veut donner accès à l'équipement en question (je rentre pas dans les détails, j'ai signé un NDA).
En fait, même si c'était une bête machine à laver, une fois que tu l'as vendue à un client, c'est difficile d'envoyer quelqu'un chez lui pour installer une mise à jour de firmware. Surtout si tu en as vendu plusieurs millions.
Dans mon cas,si on a pas trop foiré les choses, on peut faire des mises à jour à distance. Mais tout le code et la configuration permettant de se connecter à Internet et recevoir des mises à jour est assez critique.
Et de façon générale dans les systèmes embarqués, si tu fais un contrôleur de moteur (de voiture, d'avion, de train, de process industriel, peu importe) et qu'il fonctionne bien 99% du temps, si tu utilises la voiture (avion, train, etc) tous les jours, statistiquement, au bout de 3 mois (100 jours) tu as une panne. Si tu as vendu 100 voitures (avions, trains, bref t'as compris) tu en a une en panne par jour. Si tu en as vendu 100000 ou plus, je te laisse faire le calcul.
Et les LLM,actuellement, ils ne sont pas bons dans 99% des cas, loin de là.
Comme tous les raccourcisseurs et redirecteurs d'URL, celui-ci permet de logger qui accède à la page, et pourrait un jour se mettre à modifier les pages à la volée ou à distribuer du (vrai) malware sous son apparence humoristique.
Je trouve que ce serait particulièrement amusant si ça se produisait un jour.
Je n'ai pas précisé que je travaille sur des systèmes embarqués peu connectés, et donc un bug ça peut vouloir dire envoyer des gens dans des endroits à des centaines de kilomètres de la ville la plus proche, sur plusieurs continents, parfois à plusieurs heures ou jours de marche ou en hélicoptère parce qu'il n'y a pas d'autre accès possible, pour aller remettre le truc en route.
(Quand ce n'est pas du code embarqué dans un satellite, ou là, le satellite pourrait tout simplement devenir inutilisable).
J'imagine que tout le monde ne travaille pas avec de telles contraintes. Mais dans mon cas, le code qui marche à peu près, ça n'est pas suffisant. Et on laisse déjà passer suffisament de bugs comre ça sans avoir à passer par des LLM. En général on les intercepte avant que les versions ne soient trop deployées…
Je ne pense pas pouvoir contrôler l'usage de MAM lors de l'envoi du message.
En revanche il est possible de rentrer une adresse "full", c'est à dire avec une ressource: user@example.org/ressource. Dans ce cas, le message devrait être envoyé seulement à ce client là.
Je peux aussi essayer de remplacer le message par un iq, mais dans ce cas je crois que la ressource sera obligatoire.
La spec pourrait en revanche encourager l'envoi d'une rétractation qui permettrait d'"annuler" une demande dwautorisation une fois que un client y a répondu?
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Débugger du code est deux fois plus difficile que d'écrire ce même code. Donc, si vous écrivez du code aussi astucieux que possible, par définition, vous ne serez pas assez malin pour le débugger.
Bon courage avec du code généré que vous n'avez même pas écrit et qui reprend toute l'intelligence collective d'Internet sans discernement, donc.
En fait dans mon travail je dirai même que c'est complètement à côté de la plaque. Écrire du code c'est peut-être 1 à 10% du travail. Ce qui prend du temps, c'est d'écrire une spécification, de se mettre d'accord avec les clients sur ce qu'on doit faire, de vérifier que le code fait bien ce qu'on a dit, etc. Dans ce travail, la rédaction sous forme de code est un exercice pour s'assurer que on a pas oublié un cas tordu, que tout est bien formalisé. La structure des langages de programmation est là pour ça. Ça me semble donc incompréhensible de passer par un LLM pour se dispenser de cette formalisation et rester dans le flou du langage naturel. Je ne vois pas comment on peut aller au-delà d'un code qui marche "à peu près" ou "presque comme il faut". Et quand on en est là, il reste encore 90% du travail à faire.
Il n'y a pas d'ambiguité pour le 301, le POST est converti en GET par tous les navigateurs, et changer ça casserait plein de trucs. Ce n'est pas une spécification au départ, mais si Internet Explorer le fait, alors tout le monde doit le faire (à l'époque; je suppose que aujourd'hui ce sont les bêtists de Chrome qu'il faut reproduire au plus près).
Le code 308 permet donc d'avoir une redirection sans ce bug, et le 301 reste spécifié de façon floue et il faut deviner ou découvrir par soi-même qu'il faut convertir les POST en GET pour que certains sites fonctionnent (source: c'est un des trucs qui m'a convaincu d'arrêter d'essayer d'implémenter le protocole http from scratch pour Haiku, et d'utiliser curl comme tout le monde).
Avec 3Ko de RAM et sans périphérique d'affichage, ça va être compliqué.
Les gens se sont tellement habitués à avoir des machines surpuissantes qu'ils sont loin d'imaginer tout ce qu'on peut faire avec une machine pourtant bien incapable oe faire tourner Doom.
En terme de capacité mémoire on est plutôt proche du Commodore Vic-20, le précurseur du C64.
Le mien est l'un des nombreux "noname saleae clone", 8 canaux 24MHz. Je n'ai pas testé les autres options car les prix montent très vite si on a besoin de beaucoup de canaux à une fréquence acceptable (certains font du multiplexage, donc beaucoup de canaux, mais plus on en active, plus la fréquence d'échantillonnage diminue).
J'ai ajouté un diagramme de séquence expliquant ce qui est implémenté (j'ai laissé l'autre qui explique ce qui est dit dans la XEP 0070).
J'ai modifié le code pour utiliser le code statut 449, j'ai corrigé le problème de login quand javascript est désactivé, et j'ai mis à jour la documentation avec tout ça.
Je crois que c'était la dernière tâche à faire! Je vais pouvoir retourner à l'un de mes autres projets maintenant.
J'ai plus ou moins réussi à faire ce que je voulais.
La page tes-tlogin.html ci-dessus a disparu, elle n'est plus nécessaire.
Maintenant quand on accède à la page de login, on reçoit une réponse contenant:
Un code d'erreur 402 (payment required). J'ai pris ce code un peu au hasard, sachant que on ne peut pas utiliser le code 401 (cela déclencherait l'affichage du dialogue de login du navigateur web) ni 200 (dans le cas d'un authorizer fastcgi, cela signifie que l'identification est valide et qu'on peut afficher la "vraie" page protégée par authentification). N'importe quel autre code devrait fonctionner, je suis ouvert à une meilleure proposition
Un challenge WWW-Authenticate. En théorie ce challenge devrait être pris en compte même si ce n'est pas une page 401, pour indiquer qu'un autre contenu est disponible si on se connecte. Ça ne semble pas être utilisé en pratique
Une page web avec un formulaire HTML de login et un peu de javascript. Si Javascript est désactivé, on devrait pouvoir avoir un lien vers le formulaire HTTP basique (et une page d'explication). Il faut que je finalise cette partie.
Le formulaire demande d'entrer seulement le JID. Il se charge ensuite de générer un token (en javascript) et de l'utiliser pour s'authentifier via XmlHttpRequest. Il refait donc une requête à la même URL, mais il faut répondre avec une erreur 401 et le challenge WWW-Authenticate, pour qu'il envoie ensuite le JID et le token. Pour distinguer cette requête de la première qui envoie un 402, je me suis basé sur le header HTTP X-Requested-With (la présence de ce header suffit à obtenir une réponse 401). À la réflexion, je ferais probablement mieux d'utiliser une query string (genre .../login?auth=basic) pour détecter ce cas.
Le XmlHttpRequest reçoit la réponse 401 avec challenge, répond au challenge avec une nouvelle requête. Celle-ci contient le JID et déclenche l'envoi vers le serveur XMPP. Enfin une fois la réponse XMPP reçue, la requête est autorisée par le serveur web, qui renvoie la réponse de la page située "en-dessous" de l'authorizer (dans mon cas, c'est le bugtracker Trac qui reprend la main, et initialise un cookie de session et une session avec le nom de l'utilisateur). Le XmlHttpRequest remplace le contenu de la page avec la réponse HTTP ainsi reçue.
Si on veut contourner le formulaire, il faut donc, soit utiliser l'en-tête X-Requested-With, soit l'option --auth-no-challenge de wget, par exemple. Mais comme indiqué plus haut, je vais sûrement remplacer ça par un paramètre dans l'URL, ça sera ainsi plus simple de l'utiliser également pour la versions sans Javascript.
J'ai mis à jour le README avec les explications de ce nouveau système.
Et il faut également que je regarde pour faire fonctionner le mode "fallback" pour les clients XMPP qui n'implémentent pas encore cette spécification…
Tout ce que je peux dire c'est que ça fonctionne chez moi. Le serveur et mon compte utilisateur sont tous les deux chez jabber.fr. Est-ce que tu peux recevoir des messages des utilisateurs de jabber.fr sans les avoir dans ton roster? (Je sais que certains serveurs n'autorisent pas de recevoir des messages d'inconnus, pour limiter le spam).
À une époque l'interface web était assez légère et fonctionnait même sans javascript. Ce n'est plus du tout le cas, maintenant il y a des websockets de partout et plein d'autres trucs compliqués qui ne semblent pas utiles vu le service rendu.
Comme je navigue sur internet pas toujours avec les navigateurs les plus à jour, ou avec le webkitt pas fini pour Haiku, Github fait partie des sites qui sont source de problèmes.
Ces derniers temps il fait en plus une poussée de boutons "AI copilot" qui sont de moins en moins discrets.
En plus de ça, je trouve le modèle "fork et pull request" inutilement compliqué, et le bugtracker trop limité par rapport à la modularité de Trac. Et puis de toutes façons, Github, c'est pas libre.
En bref, j'ai déjà fait 2 fois la bêtise de migrer vers une plateforme fermée (de sourceforge et berlios vers google code hroject hosting, puis ensuite vers github). C'était une mauvaise idée la première comme la deuxième fois. Je me remet à l'auto hébergement en m'assurant que mes dépôts de code sont sauvegardés par software heritage (en plus de mes propres sauvegardes)
Mais comme il se refuse à utiliser les caractères prévus à cet effet pour indiquer qu'il n'est pas sérieux (points d'ironie, marqueurs de sarcasme, emojis divers, etc.), personne ne le comprend.
Le token sert surtout à limiter les attaques "authentication fatigue" où on envoie plein de demandes d'authentification à un utilisateur en espérant qu'il finisse par cliquer sur la mauvaise en essayant d'accéder à son compte.
Avec ce token, on peut sélectionner la bonne requête dans ce cas là. Dans les autres cas, on va souvent recevoir une seule notification et il n'y a pas forcément d'intérêt à vérifier le token. La confiance repose plutôt sur la sécurisation du réseau XMPP (si on arrive à recevoir et envoyer des messages avec un faux expédieur, on peut se faire passer pour n'importe qui sur le serveur HTTP).
Maintenant il suffit de comparer le token affiché des 2 côtés. Je vais voir si je peux intégrer ça directement dans le code Rust pour simplifier le déploiement. Pour l'instant, si on a pas Javascript, ça redirige vers la méthode "classique", ce que j'aimerais bien conserver, il faut que je voie comment faire. Et ce serait bien aussi que ça fonctionne facilement avec wget ou autrres outils similaires sans trop s'embêter. Dans ce cas, c'est bien que ça reste une page à part pour le formulaire de login, le endpoint de l'authorizer n'a pas besoin d'être modifié.
Je ne crois pas qu'on puisse tout faire avec uniquement les polices de caractères. Ouand on parle d'Unicode on pense en premier aux caractères et aux glyphes, mais il y a aussi les algorithmes pour déterminer les endroits où il est pertinent de placer un retour à la ligne (dans les cas simples, pas forcément pour les césures où des règles différentes s'appliquent pour plusieurs langues même si elles partagent un alphabet), ou même simplement de placer le curseur lorsqu'on édite du texte. Ce qui peut être un peu compliqué si par exemple on a des chiffres "arabes" (écrits de gauche à droite, au milieu d'un texte dans une langue écrite de droite à gauche.
Heureusement, cette partie d'Unicode évolue moins que le reste, et les nouveaux caractères se trouvent simplement étiquettés avec les informations nécessaires à l'algorithme. Tout au plus il y a de temps en temps quelques caractères qui étaient mal caractérisés et donc des corrections sur ces métadonnées.
Mais finalement, oui, tout ce travail peut être fait une bonne fois pour toutes, ce qui est très bien.
Je me suis mal exprimé alors. J'essayais de dire justement que sans Unicode, on se retrouve avec tout un tas d'encodages locaux (iso 8859, codepage 850, macroman, et ça c'est juste pour les utilisations européennes de l'alphabet latin, pour le reste il y en a encore plein d'autres) et de problèmes de conversion. Penser que l'ASCII rend les choses plus simple que Unicode et permetrait de faire de l'éco-conception est donc une bêtise.
Les centaines d'extensions (standardisées ou non) de l'ASCII pour traiter différentes langues, et les heures perdues à rédiger des standards, définir des algorithmes de conversion entre les encodages, investiguer des problèmes d'interopérabilité, ce n'est pas ce qu'on peut appeler de l'éco-conception, mais plutôt une fausse bonne idée que l'on continue de payer pendant une cinquantaine d'années par la suite.
Je crois que cette idée est encore pire - en termes d'économies réalisées - que de supprimer les vieux e-mail?
Une chose à savoir et qui m'a fait perdre du temps: dans le packaging Debian de lighttpd, l'écriture dans les sous-dossiers de /home est interdite par une configuration au niveau du service systemd. Ce qui peut se défendre d'un point de vue sécurité, sauf si on a envie d'héberger des services web stockés dans des dossiers utilisateur et qui font des écritures dans leur propre dossier.
J'ai mis du temps à trouver d'où pouvait bien venir l'erreur "permission denied" causée par cette configuration. C'est documenté assez clairement mais… sous forme d'un commentaire dans le fichier de définition de la unit systemd. Donc c'est très clair, mais seulement une fois que on a trouvé le problème. Et en plus, comme ce n'est pas un fichier de configuration, toute modification dedans est écrasée sans avertissement lors des mises à jour du paquet lighttpd.
Je ne sais pas si les autres serveurs web ont une configuration similaire, et si c'est un choix spécifique à Debian.
Merci également, cette page m'a bien aidé parce que j'ai du implémenter la XEP-0070 dans mon client XMPP en même temps que j'implémentais la partie serveur. C'était bien utile d'avoir une implémentation "de référence" pour tester la partie client.
Je vais voir comment faire pour afficher une page de login en HTML avec des explications, car effectivement ce n'est pas du tout clair avec le dialogue par défaut des navigateurs web, qui n'est pas du tout personnalisable.
Mais actuellement c'est bien ça, il faut soi-même choisir un "token" qui permet dans le client XMPP de vérifier qu'on accepte bien sa propre demande de connexion (et pas celle de quelqu'un d'autre essayant d'usurper l'identitié).
Avec une page web, un formulaire et un peu de Javascript, ce token pourra être généré par la page web et il faudra simplement vérifier dans le client XMPP que c'est bien le même.
[^] # Re: Je me demande
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal npm et badaboum. Évalué à 10 (+10/-0).
Soit ton LLM a "trouvé" la réponse quelque part dans ses données d'entraînement, et donc elle existait bien quelque part, très probablement sur internet ; soit il l'a inventée, et donc c'est une réponse bidon qui ne sera vraie que sur un coup de chance.
Donc je ne vois pas quel problème ça résout. Au lieu de passer du temps à chercher une réponse, tu vas avoir une réponse tout de suite, et puis ensuite tu vas passer autant de temps qu'avant à vérifier si cette réponse est vraie. Tu as peut-être l'impression de ne pas avoir galéré et d'avoir été mis tout de suite sur une piste.
Pour reprendre l'exemple de la recherche d'itinéraire, c'est équivalent à partir dans une direction à l'instinct sans regarder un plan, se rendre compte que c'était pas la bonne direction, et dire "oui, mais au moins j'ai bougé". La direction est plus important que la vitesse, et les LLM te donne de la vitesse.
[^] # Re: XEP-0070 et MAM ne font pas bon ménage
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 6 (+3/-0).
Je parlais de rétractation parce que j'ai un autre problème: j'ai un client sur mon téléhhone, un sur mon pc pro et un sur mon pc perso par exemple. Toutes les requêtes arrivent sur tous les clients. Une fois que j'ai accepté la requête, je n'ai pas besoin que des fenêtres de demande persistent sur les 2 autres clients qui étaient en ligne à ce moment là. Donc ce serait bien que le serveur puisse invalider ces requêtes.
Et même avec un seul client, si la requête http fait un timeout avant d'avoir reçu une réponse, invalider la demande de confirmation serait raisonable aussi.
[^] # Re: La loi de Kernighan
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'impact du LLM sur l'Open-Source. Évalué à 10 (+8/-0).
Plusieurs différents hrojets, j'ai par exemple travaillé sur des réseaux de talkie walkie avec des antennes relais qui sont déployées en fonction des endroits où il y a une bonne réception radio et pas en fonction de l'accessibilité routière; ça peut être également des projets déployés sur des sites industriels, où il y a plein de monde autour, mais qui ne sont pas des personnes à qui on veut donner accès à l'équipement en question (je rentre pas dans les détails, j'ai signé un NDA).
En fait, même si c'était une bête machine à laver, une fois que tu l'as vendue à un client, c'est difficile d'envoyer quelqu'un chez lui pour installer une mise à jour de firmware. Surtout si tu en as vendu plusieurs millions.
Dans mon cas,si on a pas trop foiré les choses, on peut faire des mises à jour à distance. Mais tout le code et la configuration permettant de se connecter à Internet et recevoir des mises à jour est assez critique.
Et de façon générale dans les systèmes embarqués, si tu fais un contrôleur de moteur (de voiture, d'avion, de train, de process industriel, peu importe) et qu'il fonctionne bien 99% du temps, si tu utilises la voiture (avion, train, etc) tous les jours, statistiquement, au bout de 3 mois (100 jours) tu as une panne. Si tu as vendu 100 voitures (avions, trains, bref t'as compris) tu en a une en panne par jour. Si tu en as vendu 100000 ou plus, je te laisse faire le calcul.
Et les LLM,actuellement, ils ne sont pas bons dans 99% des cas, loin de là.
# Risque de sécurité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien A tool that takes any link and makes it look malicious. Évalué à 7 (+4/-0).
Comme tous les raccourcisseurs et redirecteurs d'URL, celui-ci permet de logger qui accède à la page, et pourrait un jour se mettre à modifier les pages à la volée ou à distribuer du (vrai) malware sous son apparence humoristique.
Je trouve que ce serait particulièrement amusant si ça se produisait un jour.
[^] # Re: La loi de Kernighan
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'impact du LLM sur l'Open-Source. Évalué à 4 (+1/-0).
Je n'ai pas précisé que je travaille sur des systèmes embarqués peu connectés, et donc un bug ça peut vouloir dire envoyer des gens dans des endroits à des centaines de kilomètres de la ville la plus proche, sur plusieurs continents, parfois à plusieurs heures ou jours de marche ou en hélicoptère parce qu'il n'y a pas d'autre accès possible, pour aller remettre le truc en route.
(Quand ce n'est pas du code embarqué dans un satellite, ou là, le satellite pourrait tout simplement devenir inutilisable).
J'imagine que tout le monde ne travaille pas avec de telles contraintes. Mais dans mon cas, le code qui marche à peu près, ça n'est pas suffisant. Et on laisse déjà passer suffisament de bugs comre ça sans avoir à passer par des LLM. En général on les intercepte avant que les versions ne soient trop deployées…
[^] # Re: XEP-0070 et MAM ne font pas bon ménage
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 5 (+2/-0). Dernière modification le 20 septembre 2025 à 08:42.
Je ne pense pas pouvoir contrôler l'usage de MAM lors de l'envoi du message.
En revanche il est possible de rentrer une adresse "full", c'est à dire avec une ressource:
user@example.org/ressource. Dans ce cas, le message devrait être envoyé seulement à ce client là.Je peux aussi essayer de remplacer le message par un iq, mais dans ce cas je crois que la ressource sera obligatoire.
La spec pourrait en revanche encourager l'envoi d'une rétractation qui permettrait d'"annuler" une demande dwautorisation une fois que un client y a répondu?
# La loi de Kernighan
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'impact du LLM sur l'Open-Source. Évalué à 10 (+15/-0).
La loi de Kernighan:
Bon courage avec du code généré que vous n'avez même pas écrit et qui reprend toute l'intelligence collective d'Internet sans discernement, donc.
En fait dans mon travail je dirai même que c'est complètement à côté de la plaque. Écrire du code c'est peut-être 1 à 10% du travail. Ce qui prend du temps, c'est d'écrire une spécification, de se mettre d'accord avec les clients sur ce qu'on doit faire, de vérifier que le code fait bien ce qu'on a dit, etc. Dans ce travail, la rédaction sous forme de code est un exercice pour s'assurer que on a pas oublié un cas tordu, que tout est bien formalisé. La structure des langages de programmation est là pour ça. Ça me semble donc incompréhensible de passer par un LLM pour se dispenser de cette formalisation et rester dans le flou du langage naturel. Je ne vois pas comment on peut aller au-delà d'un code qui marche "à peu près" ou "presque comme il faut". Et quand on en est là, il reste encore 90% du travail à faire.
[^] # Re: HTTP 308 – et quelles traces sur les serveurs de la blague ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien A tool that takes any link and makes it look malicious. Évalué à 7 (+4/-0).
Il n'y a pas d'ambiguité pour le 301, le POST est converti en GET par tous les navigateurs, et changer ça casserait plein de trucs. Ce n'est pas une spécification au départ, mais si Internet Explorer le fait, alors tout le monde doit le faire (à l'époque; je suppose que aujourd'hui ce sont les bêtists de Chrome qu'il faut reproduire au plus près).
Le code 308 permet donc d'avoir une redirection sans ce bug, et le 301 reste spécifié de façon floue et il faut deviner ou découvrir par soi-même qu'il faut convertir les POST en GET pour que certains sites fonctionnent (source: c'est un des trucs qui m'a convaincu d'arrêter d'essayer d'implémenter le protocole http from scratch pour Haiku, et d'utiliser curl comme tout le monde).
[^] # Re: C'est pas un ordinateur…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Hébergez votre site web sur une cigarette électronique jetable. Évalué à 3 (+0/-0).
Avec 3Ko de RAM et sans périphérique d'affichage, ça va être compliqué.
Les gens se sont tellement habitués à avoir des machines surpuissantes qu'ils sont loin d'imaginer tout ce qu'on peut faire avec une machine pourtant bien incapable oe faire tourner Doom.
En terme de capacité mémoire on est plutôt proche du Commodore Vic-20, le précurseur du C64.
[^] # Re: Compatibles Salae
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Remise en route d'un analyseur logique Philips PM3580. Évalué à 3 (+0/-0). Dernière modification le 16 septembre 2025 à 14:27.
Le logiciel PulseView fait ça plutôt bien. Ils ont un wiki avec une liste de matériel compatible.
Le mien est l'un des nombreux "noname saleae clone", 8 canaux 24MHz. Je n'ai pas testé les autres options car les prix montent très vite si on a besoin de beaucoup de canaux à une fréquence acceptable (certains font du multiplexage, donc beaucoup de canaux, mais plus on en active, plus la fréquence d'échantillonnage diminue).
[^] # Re: A propos du token
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 8 (+5/-0).
J'ai ajouté un diagramme de séquence expliquant ce qui est implémenté (j'ai laissé l'autre qui explique ce qui est dit dans la XEP 0070).
J'ai modifié le code pour utiliser le code statut 449, j'ai corrigé le problème de login quand javascript est désactivé, et j'ai mis à jour la documentation avec tout ça.
Je crois que c'était la dernière tâche à faire! Je vais pouvoir retourner à l'un de mes autres projets maintenant.
[^] # Re: A propos du token
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 5 (+2/-0).
417 a l'air liée au header "Expect:", en gros ça permet de valider les en-têtes de la requête avant d'envoyer de grosses données.
Par exemple: pas la peine d'envoyer un fichier de 5Go sur un serveur via une requête POST pour recevoir finalement une réponse "non c'est trop gros".
On ajoute donc une réponse intermédiaire dès que le serveur a reçu les en-têtes et on permet à l'upload de se poursuivre.
412 quant à elle a l'air d'être lié à l'utilisation des requêtes conditionelles (If-Modified-Since par exemple).
Par contre le code 449 de Microsoft semble à peu près correspondre, je vais donc essayer ça:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wdv/d5f72692-036d-435f-8037-fbc7024ecc50
[^] # Re: Intéressant.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Hébergez votre site web sur une cigarette électronique jetable. Évalué à 10 (+10/-0).
En France, ça n'est plus autorisé depuis février 2025.
[^] # Re: A propos du token
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 7 (+4/-0).
J'ai plus ou moins réussi à faire ce que je voulais.
La page tes-tlogin.html ci-dessus a disparu, elle n'est plus nécessaire.
Maintenant quand on accède à la page de login, on reçoit une réponse contenant:
Le formulaire demande d'entrer seulement le JID. Il se charge ensuite de générer un token (en javascript) et de l'utiliser pour s'authentifier via XmlHttpRequest. Il refait donc une requête à la même URL, mais il faut répondre avec une erreur 401 et le challenge WWW-Authenticate, pour qu'il envoie ensuite le JID et le token. Pour distinguer cette requête de la première qui envoie un 402, je me suis basé sur le header HTTP X-Requested-With (la présence de ce header suffit à obtenir une réponse 401). À la réflexion, je ferais probablement mieux d'utiliser une query string (genre
.../login?auth=basic) pour détecter ce cas.Le XmlHttpRequest reçoit la réponse 401 avec challenge, répond au challenge avec une nouvelle requête. Celle-ci contient le JID et déclenche l'envoi vers le serveur XMPP. Enfin une fois la réponse XMPP reçue, la requête est autorisée par le serveur web, qui renvoie la réponse de la page située "en-dessous" de l'authorizer (dans mon cas, c'est le bugtracker Trac qui reprend la main, et initialise un cookie de session et une session avec le nom de l'utilisateur). Le XmlHttpRequest remplace le contenu de la page avec la réponse HTTP ainsi reçue.
Si on veut contourner le formulaire, il faut donc, soit utiliser l'en-tête X-Requested-With, soit l'option --auth-no-challenge de wget, par exemple. Mais comme indiqué plus haut, je vais sûrement remplacer ça par un paramètre dans l'URL, ça sera ainsi plus simple de l'utiliser également pour la versions sans Javascript.
J'ai mis à jour le README avec les explications de ce nouveau système.
Et il faut également que je regarde pour faire fonctionner le mode "fallback" pour les clients XMPP qui n'implémentent pas encore cette spécification…
[^] # Re: Un soucis ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 6 (+3/-0).
Tout ce que je peux dire c'est que ça fonctionne chez moi. Le serveur et mon compte utilisateur sont tous les deux chez jabber.fr. Est-ce que tu peux recevoir des messages des utilisateurs de jabber.fr sans les avoir dans ton roster? (Je sais que certains serveurs n'autorisent pas de recevoir des messages d'inconnus, pour limiter le spam).
Les messages devraient venir de auth.pulkomandy.tk@jabber.fr
# Debian aussi
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Pour son démarrage, Ubuntu 25.10 utilisera Dracut par défaut. Évalué à 5 (+2/-0).
Chez Debian aussi, de ce que je comprend c'est poussé par les développeurs du noyau qui souhaitent mettre initramfs-tools à la retraite?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1114857
[^] # Re: GitHub
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 10 (+12/-0).
À une époque l'interface web était assez légère et fonctionnait même sans javascript. Ce n'est plus du tout le cas, maintenant il y a des websockets de partout et plein d'autres trucs compliqués qui ne semblent pas utiles vu le service rendu.
Comme je navigue sur internet pas toujours avec les navigateurs les plus à jour, ou avec le webkitt pas fini pour Haiku, Github fait partie des sites qui sont source de problèmes.
Ces derniers temps il fait en plus une poussée de boutons "AI copilot" qui sont de moins en moins discrets.
En plus de ça, je trouve le modèle "fork et pull request" inutilement compliqué, et le bugtracker trop limité par rapport à la modularité de Trac. Et puis de toutes façons, Github, c'est pas libre.
En bref, j'ai déjà fait 2 fois la bêtise de migrer vers une plateforme fermée (de sourceforge et berlios vers google code hroject hosting, puis ensuite vers github). C'était une mauvaise idée la première comme la deuxième fois. Je me remet à l'auto hébergement en m'assurant que mes dépôts de code sont sauvegardés par software heritage (en plus de mes propres sauvegardes)
[^] # Re: Ascii vaincu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Dans le coffre aux trésors d’Unicode 17 : des chameaux et un trombone. Évalué à 10 (+9/-0).
Mais comme il se refuse à utiliser les caractères prévus à cet effet pour indiquer qu'il n'est pas sérieux (points d'ironie, marqueurs de sarcasme, emojis divers, etc.), personne ne le comprend.
[^] # Re: A propos du token
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 5 (+2/-0).
Le token sert surtout à limiter les attaques "authentication fatigue" où on envoie plein de demandes d'authentification à un utilisateur en espérant qu'il finisse par cliquer sur la mauvaise en essayant d'accéder à son compte.
Avec ce token, on peut sélectionner la bonne requête dans ce cas là. Dans les autres cas, on va souvent recevoir une seule notification et il n'y a pas forcément d'intérêt à vérifier le token. La confiance repose plutôt sur la sécurisation du réseau XMPP (si on arrive à recevoir et envoyer des messages avec un faux expédieur, on peut se faire passer pour n'importe qui sur le serveur HTTP).
J'ai mis en place une page frontale qui se place avant l'authentification. Pour l'instant c'est en test ici: http://pulkomandy.tk/drop/test-login.html
Maintenant il suffit de comparer le token affiché des 2 côtés. Je vais voir si je peux intégrer ça directement dans le code Rust pour simplifier le déploiement. Pour l'instant, si on a pas Javascript, ça redirige vers la méthode "classique", ce que j'aimerais bien conserver, il faut que je voie comment faire. Et ce serait bien aussi que ça fonctionne facilement avec wget ou autrres outils similaires sans trop s'embêter. Dans ce cas, c'est bien que ça reste une page à part pour le formulaire de login, le endpoint de l'authorizer n'a pas besoin d'être modifié.
[^] # Re: Ascii vaincu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Dans le coffre aux trésors d’Unicode 17 : des chameaux et un trombone. Évalué à 5 (+2/-0).
Je ne crois pas qu'on puisse tout faire avec uniquement les polices de caractères. Ouand on parle d'Unicode on pense en premier aux caractères et aux glyphes, mais il y a aussi les algorithmes pour déterminer les endroits où il est pertinent de placer un retour à la ligne (dans les cas simples, pas forcément pour les césures où des règles différentes s'appliquent pour plusieurs langues même si elles partagent un alphabet), ou même simplement de placer le curseur lorsqu'on édite du texte. Ce qui peut être un peu compliqué si par exemple on a des chiffres "arabes" (écrits de gauche à droite, au milieu d'un texte dans une langue écrite de droite à gauche.
Heureusement, cette partie d'Unicode évolue moins que le reste, et les nouveaux caractères se trouvent simplement étiquettés avec les informations nécessaires à l'algorithme. Tout au plus il y a de temps en temps quelques caractères qui étaient mal caractérisés et donc des corrections sur ces métadonnées.
Mais finalement, oui, tout ce travail peut être fait une bonne fois pour toutes, ce qui est très bien.
[^] # Re: Ascii vaincu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Dans le coffre aux trésors d’Unicode 17 : des chameaux et un trombone. Évalué à 5 (+3/-1).
Je me suis mal exprimé alors. J'essayais de dire justement que sans Unicode, on se retrouve avec tout un tas d'encodages locaux (iso 8859, codepage 850, macroman, et ça c'est juste pour les utilisations européennes de l'alphabet latin, pour le reste il y en a encore plein d'autres) et de problèmes de conversion. Penser que l'ASCII rend les choses plus simple que Unicode et permetrait de faire de l'éco-conception est donc une bêtise.
[^] # Re: Ascii vaincu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Dans le coffre aux trésors d’Unicode 17 : des chameaux et un trombone. Évalué à 5 (+2/-0).
Les centaines d'extensions (standardisées ou non) de l'ASCII pour traiter différentes langues, et les heures perdues à rédiger des standards, définir des algorithmes de conversion entre les encodages, investiguer des problèmes d'interopérabilité, ce n'est pas ce qu'on peut appeler de l'éco-conception, mais plutôt une fausse bonne idée que l'on continue de payer pendant une cinquantaine d'années par la suite.
Je crois que cette idée est encore pire - en termes d'économies réalisées - que de supprimer les vieux e-mail?
# lighttpd
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Dossier de developpement web sous linux. Évalué à 3 (+0/-0). Dernière modification le 12 septembre 2025 à 15:26.
Bonjour,
Une chose à savoir et qui m'a fait perdre du temps: dans le packaging Debian de lighttpd, l'écriture dans les sous-dossiers de /home est interdite par une configuration au niveau du service systemd. Ce qui peut se défendre d'un point de vue sécurité, sauf si on a envie d'héberger des services web stockés dans des dossiers utilisateur et qui font des écritures dans leur propre dossier.
J'ai mis du temps à trouver d'où pouvait bien venir l'erreur "permission denied" causée par cette configuration. C'est documenté assez clairement mais… sous forme d'un commentaire dans le fichier de définition de la unit systemd. Donc c'est très clair, mais seulement une fois que on a trouvé le problème. Et en plus, comme ce n'est pas un fichier de configuration, toute modification dedans est écrasée sans avertissement lors des mises à jour du paquet lighttpd.
Je ne sais pas si les autres serveurs web ont une configuration similaire, et si c'est un choix spécifique à Debian.
[^] # Re: Merci !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 6 (+3/-0).
Merci également, cette page m'a bien aidé parce que j'ai du implémenter la XEP-0070 dans mon client XMPP en même temps que j'implémentais la partie serveur. C'était bien utile d'avoir une implémentation "de référence" pour tester la partie client.
[^] # Re: Bravo pour XMPP
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Authentifiez-vous sans mot de passe grâce à XMPP, 10 ans plus tard. Évalué à 5 (+2/-0).
Je vais voir comment faire pour afficher une page de login en HTML avec des explications, car effectivement ce n'est pas du tout clair avec le dialogue par défaut des navigateurs web, qui n'est pas du tout personnalisable.
Mais actuellement c'est bien ça, il faut soi-même choisir un "token" qui permet dans le client XMPP de vérifier qu'on accepte bien sa propre demande de connexion (et pas celle de quelqu'un d'autre essayant d'usurper l'identitié).
Avec une page web, un formulaire et un peu de Javascript, ce token pourra être généré par la page web et il faudra simplement vérifier dans le client XMPP que c'est bien le même.