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.
Ce n'est pas forcément idiot d'un point de vue de la stratégie commerciale. Par exemple des fabricants de consoles de jeu vendent la console à perte en sachant qu'ils vont gagner des sous en vendant les jeux qui vont avec.
Ou encore les supermarchés qui ont des produits d'appel vendus à perte ou à prix coûtant, en sachant qu'une fois attirés dans le magasin par une promo incroyable, les gens vont aussi acheter d'autre trucs.
D'un point de vue éthique, c'est beaucoup plus discutable. mais le "bon sens" est là oùon veut le placer.
https://spritesmods.com/?art=hddhack&page=1 (un disque dur avec un processeur ARM à 150MHz et 64MB de RAM, l'auteur ne s'arrête pas à l'identification du matériel et finit par démarrer Linux directement sur ce disque dur sans avoir besoin de le connecter à un ordinateur)
Et les CPU sont tellement pas cher que on en met vraiment partout. Un chargeur de téléphone aujourd'hui a un processeur à 200MHz, bien plus puissant que la plupart des ordinateurs dans les années 90. Même chose pour un disque dur ou un SSD, la plupart des périphéricues USB utilisent un coeur Intel 8051 boosté, …
Donc d'une certaine façon l'architecture est déjà pas mal distribuée. Mais il y a des processeurs classiques partout, et le besoin de réaliser des circuits spécialisés (qui sont plus chers, c'est un peu le sur mesure de l'électronique) est de moins en moins justifié car les performances avec un CPU générique sont bien suffisantes.
Question de béotien : comment arrives-tu à ça ? C'est intéressant comme point de vue, je suis curieux !
En regardant ce qui se fait ailleurs, par exemple, les LISP Machines qui ont (ou avaient) un jeu d'instruction plutôt dédié à manipuler très rapidement des listes chaînées; les données dans la mémoire sont "taggées" par exemple pour indiquer si une adresse contient une valeur entière, une référence vers un autre objet, ou rien du tout, ce qui est très utile au garbage collector pour nettoyer la mémoire.
Ou plein d'autres architectures historiques comme le z80, sur lequel écrire un compilateur C est possible, mais assez pénible, parce que les registres et instructions sont spécialisés pour faire d'autres choses. Par exemple, il n'y a pas vraiment de quoi implémenter un "frame pointer". Sur un processeur 68000, SPARc ou x86, ça se fait en une instruction (link/unlink, save/restore, et un mov bp, sp avec un offset sur le dernier). Ils ont tous les 3 également des modes d'adressages indexés, on peut donc facilement avoir sur la pile un pointeur vers une structure, et en une ou deux instructions, on va:
Récupérer ce pointeur dans la mémoire (adressage par bp + offset)
Ajouter un offset à ce pointeur (soit un offset constant pour accéder à un champ d'une structure, soit un nombre d'éléments multiplié par la taille d'un élément pour accéder à un tableau
lire ou écrire quelque chose à cette addresse
C'est un exemple de ce que je disais par "nombreux niveaux d'indirection de pointeurs". Bien sur on écrit pas int**** truc; dans un programme, mais on écrit facilement ce genre de code:
Deuxième niveau: le pointeur truc avec l'offset champ1
Troisième niveau: l'index dans le tableau champ1
Quatrième niveau, l'index de chose dans l'élément de champ1
Le code passe plus de temps à manipuler des adresses que des données (comme donnée dans cet exemple il y a la constante 3). Si on regarde un processeur comme le 68000, on voit que la moitié des registres sont dédiés aux calculs d'adresses en conséquence. C'est encore plus flagrant sur son petit frère 8 bit le 6809: pour gérer les adresses on a 4 registres 16 bit, alors que pour les données on en a un seul (découpable en 2 moitiés de 8 bits). Et les calculs sur les adresses sont plus rapides car ils disposent d'une unité arithmétique 16 bit dédiée (alors que les calculs sur les données sont fait en 8 bit et donc en 2 fois).
Il y a d'autres processeurs où la pile est limitée à 256 éléments au total. Sur le z80, on peut simuler un registre BP avec l'un des deux registres d'index, mais on ne peut pas adresser plus de 256 octets de mémoire et les index sont forcément constants. Pour tout le reste il faut faire des acrobaties qui consomment une quinzaine d'instructions.
On a des informations historiques des concepteurs de ces langages, aussi. Pour le x86, ce n'est pas exactement le C qui était visé, mais plutôt le Pascal. Mais le modèle d'exécution est assez similaire: fonctions avec passage de paramètres sur la pile, structures, tableaux. Pas de programmation objet, par exemple (ce qui se concentrerait plutôt sur des sauts indirects via des vtables). ça n'a pas vraiment été étudié pour les coroutines non plus.
Pour le SPARC, les choix de jeu d'instruction ont été faits en simulant l'exécution de code existant. Comme c'était en plein dans l'époque de UNIX pour Sun, ça a forcément été fait avec du C.
De mémoire, il y avait eu un essai avec des processeurs Java, et c'était pas la folie. Ça ne veut pas dire que la prochaine fois ce sera aussi un échec, mais l'idée a été testée.
D'ailleurs, dans les processeurs Apple (M1 etc.), il me semble qu'il y a des circuits dédiés à JavaScript, pour accélérer certains comportements.
Pour le Java, je suppose que tu parles des processeurs ARM Jazelle. Qui ont été un échec pour deux raisons: d'une part parce que ce mode d'exécution est incomplètement documenté par ARM, et d'autre part parce qu'il ne correspond pas du tout au fonctionnement interne des machines virtuelles Java de l'époque (qui font beaucoup de transformations sur le bytecode pour l'opptimiser avant de l'exécuter).
Pour le Javascript, effectivement il existe plusieurs opérations dédiées pour des comportements spécifiques sur certaines opérations mathématiques (ce n'esst pas spécifique à Apple, on trouve ça dans plusieurs processeurs ARM et c'est dans le jeu d'instruction officiel).
Dans les choses qui n'ont pas marché on peut aussi citer l'Intel iAPX 432 dont le but était de faire un processeur orienté objet.
Et un autre qui rejoint un peu ce que j'essaie de dire, c'est l'architecture Itanium de Intel. Le but était justement de supprimer des couches de complexité dans les processeurs (réordonnancement des instructions, renommage de registres, exécution spéculative) pour remettre tout ça sous la responsabilité du compilateur. En théorie, ce n'est pas une mauvaise idée pour avoir un langage vraiment "proche du matériel". En pratique, la densité du code est plus basse (et donc il s'exécute moins vite, parce que la mémoire est beaucoup plus lente que le processeur), et surtout, le code compilé est lié à une implémentation spécifique du CPU. Si une nouvelle génération de CPU devient disponible, avec, par exemple, des unités de traitement ou des registres supplémentaires, il faut tout recompiler pour en tirer parti. C'est l'erreur qu'ont fait les générations précédentes de RISC avec le "branch delay slot" par exemple (exécuter une instruction supplémentaire après un jump, avant d'aller à la nouvelle addresse: ça simplifiait beaucoup le design initial avec un pipeline à 4 étages seulement, mais c'est resté ensuite dans le jeu d'instruction alors que ça n'avait plus aucun intérêt).
On semble donc se diriger, aussi bien dans le logiciel que dans le matériel, vers une solution intermédiaire: un code assembleur qui fournit une représentation compacte de ce qu'il faut exécuter, mais tout en étant facile à décoder et optimiser par des phases de pré-traitement avant d'être exécutée. C'est le principe des machines virtuelles (javascript, java, wasm), mais c'est aussi ce qu'il se passe à l'intérieur des processeurs modernes (pré-décodage du jeu d'instruction x86 ou ARM vers des instructions internes microcodées; jeu d'instruction Thumb sur ARM pour gagner en densité et en bande passante mémoire). Une exception notable est le RISC-V, qui part dans la direction opposée avec un jeu d'instruction très minimaliste et donc peu dense, avec dans l'idée que cela pourrait permettre à ce pré-traitement d'être plus complexe et intrusif (c'est un peu plus facile de manipuler ce flot d'instruction si chaque instruction fait très peu de choses), mais par contre avec une densité faible qui risque de poser problème si les mémoires ne font pas de gros progrès en vitesse d'accès.
Au final, il y a en fait un genre de co-évolution: on exécute beaucoup de code basé sur le modèle d'exécution du C, donc on achète (et on fabrique) les processeurs qui sont efficace pour ça, et les autres architectures sont oubliées depuis longtemps. Les compilateurs s'adaptent également à ces processeurs courants. Et si quelqu'un vient proposer un langage avec des idées radicalement différentes, il vient se heurter à des processeurs pas forcément adaptés et donc à une pénalité de performances.
Le C était proche du matériel du PDP-11 sur lequel il a été conçu. Il n'est pas du tout proche du matériel actuel, malgré les efforts des fabricants de processeurs pour adapter leur architecture à l'exécution du C et de langages apparentés (stockage de grosse données sur la pile d'exécution; opérations sur les pointeurs avec plusieurs niveaux d'indirection; …). Ce sont des choses qui n'étaient pas du tout évidentes à l'époque de l'invention du C. En d'autres termes, c'est le hardware actuel qui est proche du C, et non lwinverse.
Les choses seraient certainement plus simples avec un langage plus haut niveau laissant le soin au compilateur et au fabricant de processeur de choisir comment l'implémenter.
Si Rust a autant de succès que C, un jour ou lwautre on verra apparaître dans les processeurs et dans les systèmes d'exploitation de nouvelles primitives (instructions, appels systèmes, …) pour l'implémenter plus efficacement.
Le code ascii définit les 128 premiers caractères, si on encode sur 8 bits on peut faire un peu ce qu'on veut avec les 128 autres.
Le BASIC étant dévelophé sur un PDP-10, une machine avec des mots de 36 bits découpables en 2x18 bits, c'est sûrement un peu différent. Le listing a l'air de ne pas utilise de lettres minuscules par exemple, il est donc loin d'exploiter toutes les possibilités de l'encodage ascii!
La version sncf gares et connexions aussi. Il y a des écrans partout dans les gares. Avant ils affichaient les horaires de départ des trains. Maintenant ils affichent "les horaires de départ des trains sont dans notre application".
La version de 1975 était pour le processeur Intel 8080, et en particulier pour le micro-ordinateur Altaïr.
A priori, les sources ne sont pas disponibles publiquement. Mais une copie est disponible à Harvard. Elle a été découverte lors d'un déménagement, elle était tombée derrière des meubles, "quelques temps avant 1980". Heureusement, un des professeurs présents sur place lors de ces travaux a compris que ça ne devrait pas partir à la poubelle et l'a confié aux archivistes.
Voilà comment fonctionne la préservation des logiciels…
OK j'ai compris ce qu'il s'est passé, il s'agit bêtement d'une erreur de lien vers le side de Michael Steil dans l'annonce de Microsoft.
Ils ont mis un lien vers cette page de 2008 qui contient des sources obtenues par reverse engineering.
Mais Michael Steil ne s'est pas arrêté là, et en 2015 il a retrouvé les sources originales. Pas du tout dans les archives de Microsoft, mais via un site coréen, qui lui-même avait récupéré des fichiers de Apple qui ont fuité via un certain David T. Craig qui avait publié du code source liés aux Apple ][ et au Lisa en 1993. Cette partie est expliquée à la fin de l'article, et le processus de développement sur PDP-10 et les outils utilisés sont également expliqués. Je comprend mieux que Microsoft ne se soit pas vanté des origines de ce code plus en détail, si j'étais mauvaise langue je dirais qu'ils ont fait exprès de se tromper de page dans leur annonce.
La bonne nouvelle, c'est que maintenant j'ai les réponses à mes questions et qu'il y a moins de doutes sur la provenance de ce code. On ne saura pas exactement quelle modifications Apple ou David Craig ou les autres personnes qui ont eu ces fichiers entre leurs mains ont pu y apporter, mais on a une explication précise du reformatage fait par Michael Steil pour tenter de se rapprocher de ce à quoi pouvait ressembler le code original.
[^] # 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é à 6 (+3/-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é à 6 (+3/-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 (+11/-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 (+7/-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é à 4 (+1/-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é à 6 (+3/-0).
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é à 4 (+1/-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.
[^] # Re: Vrai soucis pour définir sa propre rentabilité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La tech au bord du gouffre financier . Évalué à 6 (+3/-0).
Ce n'est pas forcément idiot d'un point de vue de la stratégie commerciale. Par exemple des fabricants de consoles de jeu vendent la console à perte en sachant qu'ils vont gagner des sous en vendant les jeux qui vont avec.
Ou encore les supermarchés qui ont des produits d'appel vendus à perte ou à prix coûtant, en sachant qu'une fois attirés dans le magasin par une promo incroyable, les gens vont aussi acheter d'autre trucs.
D'un point de vue éthique, c'est beaucoup plus discutable. mais le "bon sens" est là oùon veut le placer.
[^] # Re: Aucune légitimité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien B. Kernighan (co-créateur d'Unix) sur Rust : « Je ne pense pas qu'il va remplacer C tout de suite ». Évalué à 5 (+2/-0).
Effectivement ça semble être autour de 50MHz, j'ai un peu exagéré
Sources:
https://forrestheller.com/Apollo-11-Computer-vs-USB-C-chargers.html (un chargeur Anker avec un processeur à 48MHz)
https://www.righto.com/2015/11/macbook-charger-teardown-surprising.html?m=1 (un chargeur Apple, à seulement 16MHz mais tout de menme 4 fois plus rapide que le processeur central du Macintosh original)
https://spritesmods.com/?art=hddhack&page=1 (un disque dur avec un processeur ARM à 150MHz et 64MB de RAM, l'auteur ne s'arrête pas à l'identification du matériel et finit par démarrer Linux directement sur ce disque dur sans avoir besoin de le connecter à un ordinateur)
[^] # Re: Aucune légitimité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien B. Kernighan (co-créateur d'Unix) sur Rust : « Je ne pense pas qu'il va remplacer C tout de suite ». Évalué à 4 (+1/-0).
Et les CPU sont tellement pas cher que on en met vraiment partout. Un chargeur de téléphone aujourd'hui a un processeur à 200MHz, bien plus puissant que la plupart des ordinateurs dans les années 90. Même chose pour un disque dur ou un SSD, la plupart des périphéricues USB utilisent un coeur Intel 8051 boosté, …
Donc d'une certaine façon l'architecture est déjà pas mal distribuée. Mais il y a des processeurs classiques partout, et le besoin de réaliser des circuits spécialisés (qui sont plus chers, c'est un peu le sur mesure de l'électronique) est de moins en moins justifié car les performances avec un CPU générique sont bien suffisantes.
[^] # Re: Aucune légitimité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien B. Kernighan (co-créateur d'Unix) sur Rust : « Je ne pense pas qu'il va remplacer C tout de suite ». Évalué à 10 (+11/-0).
En regardant ce qui se fait ailleurs, par exemple, les LISP Machines qui ont (ou avaient) un jeu d'instruction plutôt dédié à manipuler très rapidement des listes chaînées; les données dans la mémoire sont "taggées" par exemple pour indiquer si une adresse contient une valeur entière, une référence vers un autre objet, ou rien du tout, ce qui est très utile au garbage collector pour nettoyer la mémoire.
Ou plein d'autres architectures historiques comme le z80, sur lequel écrire un compilateur C est possible, mais assez pénible, parce que les registres et instructions sont spécialisés pour faire d'autres choses. Par exemple, il n'y a pas vraiment de quoi implémenter un "frame pointer". Sur un processeur 68000, SPARc ou x86, ça se fait en une instruction (link/unlink, save/restore, et un mov bp, sp avec un offset sur le dernier). Ils ont tous les 3 également des modes d'adressages indexés, on peut donc facilement avoir sur la pile un pointeur vers une structure, et en une ou deux instructions, on va:
C'est un exemple de ce que je disais par "nombreux niveaux d'indirection de pointeurs". Bien sur on écrit pas
int**** truc;dans un programme, mais on écrit facilement ce genre de code:Si on compte on a ici:
Le code passe plus de temps à manipuler des adresses que des données (comme donnée dans cet exemple il y a la constante 3). Si on regarde un processeur comme le 68000, on voit que la moitié des registres sont dédiés aux calculs d'adresses en conséquence. C'est encore plus flagrant sur son petit frère 8 bit le 6809: pour gérer les adresses on a 4 registres 16 bit, alors que pour les données on en a un seul (découpable en 2 moitiés de 8 bits). Et les calculs sur les adresses sont plus rapides car ils disposent d'une unité arithmétique 16 bit dédiée (alors que les calculs sur les données sont fait en 8 bit et donc en 2 fois).
Il y a d'autres processeurs où la pile est limitée à 256 éléments au total. Sur le z80, on peut simuler un registre BP avec l'un des deux registres d'index, mais on ne peut pas adresser plus de 256 octets de mémoire et les index sont forcément constants. Pour tout le reste il faut faire des acrobaties qui consomment une quinzaine d'instructions.
On a des informations historiques des concepteurs de ces langages, aussi. Pour le x86, ce n'est pas exactement le C qui était visé, mais plutôt le Pascal. Mais le modèle d'exécution est assez similaire: fonctions avec passage de paramètres sur la pile, structures, tableaux. Pas de programmation objet, par exemple (ce qui se concentrerait plutôt sur des sauts indirects via des vtables). ça n'a pas vraiment été étudié pour les coroutines non plus.
Pour le SPARC, les choix de jeu d'instruction ont été faits en simulant l'exécution de code existant. Comme c'était en plein dans l'époque de UNIX pour Sun, ça a forcément été fait avec du C.
Pour le Java, je suppose que tu parles des processeurs ARM Jazelle. Qui ont été un échec pour deux raisons: d'une part parce que ce mode d'exécution est incomplètement documenté par ARM, et d'autre part parce qu'il ne correspond pas du tout au fonctionnement interne des machines virtuelles Java de l'époque (qui font beaucoup de transformations sur le bytecode pour l'opptimiser avant de l'exécuter).
Pour le Javascript, effectivement il existe plusieurs opérations dédiées pour des comportements spécifiques sur certaines opérations mathématiques (ce n'esst pas spécifique à Apple, on trouve ça dans plusieurs processeurs ARM et c'est dans le jeu d'instruction officiel).
Dans les choses qui n'ont pas marché on peut aussi citer l'Intel iAPX 432 dont le but était de faire un processeur orienté objet.
Et un autre qui rejoint un peu ce que j'essaie de dire, c'est l'architecture Itanium de Intel. Le but était justement de supprimer des couches de complexité dans les processeurs (réordonnancement des instructions, renommage de registres, exécution spéculative) pour remettre tout ça sous la responsabilité du compilateur. En théorie, ce n'est pas une mauvaise idée pour avoir un langage vraiment "proche du matériel". En pratique, la densité du code est plus basse (et donc il s'exécute moins vite, parce que la mémoire est beaucoup plus lente que le processeur), et surtout, le code compilé est lié à une implémentation spécifique du CPU. Si une nouvelle génération de CPU devient disponible, avec, par exemple, des unités de traitement ou des registres supplémentaires, il faut tout recompiler pour en tirer parti. C'est l'erreur qu'ont fait les générations précédentes de RISC avec le "branch delay slot" par exemple (exécuter une instruction supplémentaire après un jump, avant d'aller à la nouvelle addresse: ça simplifiait beaucoup le design initial avec un pipeline à 4 étages seulement, mais c'est resté ensuite dans le jeu d'instruction alors que ça n'avait plus aucun intérêt).
On semble donc se diriger, aussi bien dans le logiciel que dans le matériel, vers une solution intermédiaire: un code assembleur qui fournit une représentation compacte de ce qu'il faut exécuter, mais tout en étant facile à décoder et optimiser par des phases de pré-traitement avant d'être exécutée. C'est le principe des machines virtuelles (javascript, java, wasm), mais c'est aussi ce qu'il se passe à l'intérieur des processeurs modernes (pré-décodage du jeu d'instruction x86 ou ARM vers des instructions internes microcodées; jeu d'instruction Thumb sur ARM pour gagner en densité et en bande passante mémoire). Une exception notable est le RISC-V, qui part dans la direction opposée avec un jeu d'instruction très minimaliste et donc peu dense, avec dans l'idée que cela pourrait permettre à ce pré-traitement d'être plus complexe et intrusif (c'est un peu plus facile de manipuler ce flot d'instruction si chaque instruction fait très peu de choses), mais par contre avec une densité faible qui risque de poser problème si les mémoires ne font pas de gros progrès en vitesse d'accès.
Au final, il y a en fait un genre de co-évolution: on exécute beaucoup de code basé sur le modèle d'exécution du C, donc on achète (et on fabrique) les processeurs qui sont efficace pour ça, et les autres architectures sont oubliées depuis longtemps. Les compilateurs s'adaptent également à ces processeurs courants. Et si quelqu'un vient proposer un langage avec des idées radicalement différentes, il vient se heurter à des processeurs pas forcément adaptés et donc à une pénalité de performances.
[^] # Re: Aucune légitimité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien B. Kernighan (co-créateur d'Unix) sur Rust : « Je ne pense pas qu'il va remplacer C tout de suite ». Évalué à 6 (+5/-2).
Le C était proche du matériel du PDP-11 sur lequel il a été conçu. Il n'est pas du tout proche du matériel actuel, malgré les efforts des fabricants de processeurs pour adapter leur architecture à l'exécution du C et de langages apparentés (stockage de grosse données sur la pile d'exécution; opérations sur les pointeurs avec plusieurs niveaux d'indirection; …). Ce sont des choses qui n'étaient pas du tout évidentes à l'époque de l'invention du C. En d'autres termes, c'est le hardware actuel qui est proche du C, et non lwinverse.
Les choses seraient certainement plus simples avec un langage plus haut niveau laissant le soin au compilateur et au fabricant de processeur de choisir comment l'implémenter.
Si Rust a autant de succès que C, un jour ou lwautre on verra apparaître dans les processeurs et dans les systèmes d'exploitation de nouvelles primitives (instructions, appels systèmes, …) pour l'implémenter plus efficacement.
[^] # Re: tu oublies que ça se compile
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft libère le code de leur Basic pour le microprocesseur 6502. Évalué à 5 (+2/-0).
Le code ascii définit les 128 premiers caractères, si on encode sur 8 bits on peut faire un peu ce qu'on veut avec les 128 autres.
Le BASIC étant dévelophé sur un PDP-10, une machine avec des mots de 36 bits découpables en 2x18 bits, c'est sûrement un peu différent. Le listing a l'air de ne pas utilise de lettres minuscules par exemple, il est donc loin d'exploiter toutes les possibilités de l'encodage ascii!
[^] # Re: appli privatrice
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Lettre ouverte à Radio France. Évalué à 5 (+2/-0).
La version sncf gares et connexions aussi. Il y a des écrans partout dans les gares. Avant ils affichaient les horaires de départ des trains. Maintenant ils affichent "les horaires de départ des trains sont dans notre application".
[^] # Re: Le cas Commodore
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft libère le code de leur Basic pour le microprocesseur 6502. Évalué à 3 (+0/-0).
Il suffit de compiler le code et de vérifier qu'on obtient une image de ROM identique à l'original, ce sera probablement plus rapide à vérifier
[^] # Re: tu oublies que ça se compile
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft libère le code de leur Basic pour le microprocesseur 6502. Évalué à 8 (+5/-0). Dernière modification le 05 septembre 2025 à 15:03.
La version de 1975 était pour le processeur Intel 8080, et en particulier pour le micro-ordinateur Altaïr.
A priori, les sources ne sont pas disponibles publiquement. Mais une copie est disponible à Harvard. Elle a été découverte lors d'un déménagement, elle était tombée derrière des meubles, "quelques temps avant 1980". Heureusement, un des professeurs présents sur place lors de ces travaux a compris que ça ne devrait pas partir à la poubelle et l'a confié aux archivistes.
Voilà comment fonctionne la préservation des logiciels…
[^] # Re: tu oublies que ça se compile
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft libère le code de leur Basic pour le microprocesseur 6502. Évalué à 10 (+10/-0).
OK j'ai compris ce qu'il s'est passé, il s'agit bêtement d'une erreur de lien vers le side de Michael Steil dans l'annonce de Microsoft.
Ils ont mis un lien vers cette page de 2008 qui contient des sources obtenues par reverse engineering.
Mais Michael Steil ne s'est pas arrêté là, et en 2015 il a retrouvé les sources originales. Pas du tout dans les archives de Microsoft, mais via un site coréen, qui lui-même avait récupéré des fichiers de Apple qui ont fuité via un certain David T. Craig qui avait publié du code source liés aux Apple ][ et au Lisa en 1993. Cette partie est expliquée à la fin de l'article, et le processus de développement sur PDP-10 et les outils utilisés sont également expliqués. Je comprend mieux que Microsoft ne se soit pas vanté des origines de ce code plus en détail, si j'étais mauvaise langue je dirais qu'ils ont fait exprès de se tromper de page dans leur annonce.
La bonne nouvelle, c'est que maintenant j'ai les réponses à mes questions et qu'il y a moins de doutes sur la provenance de ce code. On ne saura pas exactement quelle modifications Apple ou David Craig ou les autres personnes qui ont eu ces fichiers entre leurs mains ont pu y apporter, mais on a une explication précise du reformatage fait par Michael Steil pour tenter de se rapprocher de ce à quoi pouvait ressembler le code original.