Bonjour,
J'avais un problème avec mon outil de suivi de bugs.
J'auto-héberge mes projets personnels (ou en tout cas j'essaie, plein de choses se sont retrouvées sur Githib par facilité, et Github est de moins en moins bien, donc je les migre petit à petit vers mon infrastructure personelle, qui est pourtant en place depuis bien avant l'apparition de Github).
Bref, j'avais un problème. Pour cet outil de rapports de bugs auto-hébergé, les utilisateurs doivent se connecter avec un compte. Ça permet de savoir qui est qui, ça limite pas mal le spam, et ça permet de donner des droits d'accès supplémentaires à certains utilisateurs. Au début j'ai géré ça de façon très simple avec une authentification HTTP basique. Ça veut dire que je dois créer à la main un compte pour les utilisateurs qui le demandent, en ajoutant un login et un mot de passe dans un fichier de config du serveur web. Le tout stocké en clair. Ça allait bien quand je n'hébergeais que quelques projets d'étude partagés avec mes camarades de classe. Mais impossible d'utiliser ce système pour des utilisateurs extérieurs qui souhaitent simplement ouvrir un ticket de bug.
Je pourrais utiliser le plugin AccountManager de Trac. Celui-ci permet aux utilisateurs d'enregistrer leur propre compte et de choisir eux-même un mot de passe. Cela suppose que le serveur soit bien configuré, que ces mots de passes soient chiffrés, etc. Mais ça crée aussi un frein qui va dissuader les gens de remonter des problèmes: il faut se créer un compte, probablement résoudre un captcha antispam, etc. Bref, pas moyen de convaincre les gens de quitter Github avec un tel système.
La solution est donc de déléguer l'authentification à quelqu'un d'autre. Il y a quelques années, cela avait été développé de façon intelligente avec le protocole OpenID (c'était la grande époque du Web 2.0). Dans ce protocole, les utilisateurs entrent leur identifiant OpenID qui contient l'URL du fournisseur d'identité de leur choix. Et avec quelques requêtes, on peut valider avec ce fournisseur que l'utilisateur est bien qui il prétend. Malheureusement, OpenID a par la suite été remplacé par OAuth2. Ce dernier fait la même chose, sauf que il n'est plus possible d'accepter n'importe quel fourniseur d'identitité automatiquement. À la place, le site doit obtenir une clé d'API et s'enregistrer avec chaque fournisseur qu'il souhaite utiliser. La conséquence est qu'il ne reste que quelques rare fournisseurs d'identité en utilisation. En gros, on doit avoir le choix entre Google, Github, et Facebook. Que des gens pas très recommandables.
Je me suis donc penché vers XMPP pour voir ce qu'il était possible de faire. Comme vous suivez Linuxfr depuis très longtemps, vous vous souvenez sans doute d'avoir lu cette dépêche de 2016 (ou sinon, c'est seulement maintenant que vous comprenez le titre de ce journal).
Or donc, XMPP propose une extension permettant de faire exactement ce dont j'ai besoin: prouver qu'un utilisateur est bien qui il dit être, en utilisant son adresse XMPP (JID) comme identifiant. Le protocole consiste à envoyer par XMPP une demande de confirmation. Si l'utilisateur l'accepte, le serveur HTTP valide l'authentification. Pas besoin de créer de nouveau compte, de stocker de mot de passe, rien de tout ça.
J'ai constaté que depuis 10 ans, les choses ne semblent pas avoir trop bougé. Il y a toujours deux implémentations de la partie serveur: une sous forme d'un composant XMPP, et l'autre sous forme d'un plugin Wordpress. Et là j'ai encore un problème: je n'utilise pas Wordpress, et je ne dispose pas d'un serveur XMPP sur lequel déployer ce composant. De plus, la méthode avec un composant semble aboutir à une centralisation de l'authorité de confiance vers un seul serveur XMPP ou une petite poignée de serveurs qui déploieraient le composant. Ça me semble pas la meilleure approche.
J'ai donc implémenté ma propre version. Dans mon cas, elle fonctionne plutôt comme une extension du serveur web. Cela est possible grâce à FastCGI utilisé ici en mode "Authorizer". FastCGI (une technologie sortie tout droit des années 90) est un protocole qui permet à un serveur web de déléguer le traitement de certaines requêtes à une application externe. La communication entre les 2 se fait par des sockets UNIX locaux. Le mode "authorizer" permet d'intercepter uniquement la partie "authentification" d'une URL. L'authorizer va envoyer une réponse HTTP 401 avec un challenge WWW-Authenticate, puis, une fois la réponse au challenge reçue, si elle est valide, il va laisser le serveur web renvoyer la page de destination de la requête. Ce composant peut donc facilement se déployer là où habituellement on met une authentification "basic" ou "digest" configurée directement dans le serveur HTTP.
Pour l'implémentation, j'ai choisi d'utiliser Rust. Un petit peu parce que j'avais envie de tester ce langage, mais surtout parce qu'il fournit des bibliothèques faciles à utiliser aussi bien pour l'interfaçage fastcgi (tokio-fastcgi) que pour la partie XMPP (tokio-xmpp). J'ai eu besoin de faire quelques ajouts dans la bibliothèque XMPP pour Rust, mais cela a été assez facile. Et le module d'authentification lui-même ne fait que 330 lignes de code.
Ce composant fastcgi se comporte en même temps comme un client XMPP. Il peut donc envoyer des requête de confirmation sur le réseau XMPP et recevoir les réponses, et ce, sans aucune configuration particulière du serveur XMPP choisi (il faudra simplement y créer un compte que le client utilisera).
D'un point de vue utilisation, on reçoit un dialogue d'authentification classique (généré par le navigateur web). C'est pas idéal, parce que ce dialogue demande un login et un mot de passe, alors qu'il faut entrer un JID et un token unique (et certainement pas son mot de passe XMPP). Je réfléchis à comment faire pour remplacer ce dialogue par une page web plus sympathique avec des explications claires (je pense que c'est faisable).
Il ne reste plus qu'à configurer le serveur web pour utiliser cet authorizer. Et donc maintenant, si vous voulez remonter des bugs pour mon client XMPP, c'est possible sans avoir besoin de créer un compte!
Et si vous voulez déployer ça sur votre propre serveur, le code source et la documentation sont également disponibles.
Notez aussi que si vous aimez les mots de passe, il est tout à fait possible d'utiliser cette méthode d'authentification comme second facteur en combinaison avec un login et mot de passe classique. Le tout sans passer par un service centralisé d'un GAFAM.
J'espère que plein de gens vont déployer ce système et que je pourrai me logger un peu partout avec mon JID un jour!
# Bravo pour XMPP
Posté par Tarnyko (site web personnel) . Évalué à 6 (+4/-0).
Bonne solution pour inciter les gens à s'inscrire à XMPP 😋 (de toute façon ils auraient dû s'inscrire chez toi avec la solution auto-hébergée habituelle…)
Quelle procédure donnes-tu à tes utilisateurs non-initiés pour s'inscrire, et ensuite récupérer le fameux couple JID/token ?
[^] # Re: Bravo pour XMPP
Posté par BAud (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 12 septembre 2025 à 09:30.
installer un client XMPP :
lancer l'application et se créer un compte jabber (choisir au besoin un serveur, sinon prendre celui par défaut), c'est un peu plus simple que What'sApp et pas besoin de n° de téléphone
voilà c'est fait, à vous les conversations textes / audio / vidéo et salons sur le medium de votre choix !
note : plus de 15 ans après, j'ai récupéré mon JID sur jabber.fr là où celui de gmail est aux oubliettes…
[^] # Re: Bravo pour XMPP
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 6 (+4/-0). Dernière modification le 12 septembre 2025 à 10:04.
La question n'était pas de comment créer un compte XMPP, mais plutôt comment se connecter au bug tracker de pulkomandy:
Firefox demande un nom d'utilisateur et un mot de passe: le nom est ton jid, mais le mot de passe doit être un token.
Concrètement, comment l'utilisateur peut retrouver ce token ?
…
Ok, je viens de tester, tu peux mettre n'importe quoi, ça sera retransmis dans le message XMPP. Ça permet d'être sûr que c'est bien toi qui a initié la connexion et non pas un bot au même moment.
Je crois que c'était expliqué déjà dans la dépêche d'il y a 10 ans, mais c'est un vieux souvenir.
Note: Dino m'a bien transmis la demande de connexion, mais il ne me permet pas de répondre, dommage :/ Gajim m'a permis de le faire :)
[^] # Re: Bravo pour XMPP
Posté par jnanar (site web personnel) . Évalué à 2 (+0/-0).
Le composant en go permets de fonctionner avec des clients qui ne permettent pas de répondre avec un popup. En répondant au composant en renvoyant le token, la requête est acceptée. Ça permets de s'authentifier avec Dino ou Conversation sur Android. Ça serait cool que ce composant puisse le supporter aussi. :-).
[^] # Re: Bravo pour XMPP
Posté par pulkomandy (site web personnel, Mastodon) . É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: Bravo pour XMPP
Posté par Glandos . Évalué à 5 (+3/-0).
Avec poezio, ça a marché. Il m'a juste fallu le temps de retrouver comment changer d'onglet :)
[^] # Re: Bravo pour XMPP
Posté par anubis . Évalué à 8 (+6/-0).
Pour info la liste des clients XMPP supportant la XEP-0070 peut être obtenu ici :
https://xmpp.org/software/?platform=all-platforms
Pour Dino le ticket est ouvert, "il n'y a plus qu'à" proposer une PR.
Merci pulkomandy pour le journal (et le composant bien sûr !), j'ai documenté celle nouvelle méthode sur le wiki JabberFR.
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
# Merci !
Posté par jnanar (site web personnel) . Évalué à 7 (+5/-0).
Je me suis intéressé à ce système il y a quelques années. Je l'ai utilisé sur un site Django pour un projet de jeu d'énigmes. Le site n'a jamais été publié officiellement mais j'ai appris plein de trucs au passage.
Entre temps, j'avais forké le projet de la dépêche de 2016 ici:
https://gitlab.com/jnanar/HTTPAuthentificationOverXMPP/-/tree/update_FluuxIO
J'avais créé un site web démo avec ce système:
https://demo.agayon.be/
Tout est expliqué ici: https://blog.agayon.be/xmpp_auth_django_demo.html
Malheureusement la partie "déconnexion" est cassé, il faudra que j'investigue.
J'avais aussi fait un plugin converse.js pour intercepter les requêtes XMPP et faire un joli dialogue:
https://blog.agayon.be/converse_xep_0070.html
Je vais m'intéresser à ton système, c'est assez ingénieux. Merci !
[^] # Re: Merci !
Posté par pulkomandy (site web personnel, Mastodon) . É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.
# linuxfr idp
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+9/-0). Dernière modification le 12 septembre 2025 à 20:41.
Linuxfr gère l'oauth2, tu pourrais t'en servir vu qu'il n'y a que des moules de confiance!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# A propos du token
Posté par lcld . Évalué à 1 (+1/-0).
Ca me fait penser à https://linuxfr.org/users/glandos/journaux/bpce-et-les-paiements-avec-authentification-a-deux-facteurs ; peu importe que ce soit sûr techniquement, l'éducation à la sécurité compte également. Ne pas oublier de toute façon que trop de gens ne savent pas vraiment lire.
Et si j'ai bien compris, ça demande à l'utilisateur de vérifier lui-même (en général visuellement) que les tokens correspondent.
Je ne sais pas trop dans quelle mesure ce token est utile en terme de sécurité. En supposant que ce soit le cas, ne peut-on pas faire l'inverse :
1. un dialogue qui demande d'entrer uniquement un JID ;
2. l'utilisation reçoit l'évènement XMPP avec le contexte (URL du site) et un token généré par le site (ça peut être 6 chiffres comme partout ailleurs) ;
3. le site demande d'enter le token reçu pour terminer l'authentification.
[^] # Re: A propos du token
Posté par pulkomandy (site web personnel, Mastodon) . É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: A propos du token
Posté par pulkomandy (site web personnel, Mastodon) . É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: A propos du token
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 14 septembre 2025 à 23:55.
hmmm c'est du détournement (de fonds) ;-) il y a d'autres codes HTTP existants qui pourraient convenir
Autant peut-être utiliser le code HTTP 409 Conflict qui re-demande une action à l'utilisateur (bon c'est plutôt pour du PUT) sinon il y a 412 Precondition Failed voire 417 Expectation failed qui sont apparemment plus génériques. Reste à voir comment c'est traité côté navigateur…
Sinon j'aime bien la RFC 2324 qui rajoute un code d'erreur indispensable.
Il y a peut-être des codes disponibles ou dans des RFC en cours d'écriture couvrant ton besoin (je ne pense pas que tu veuilles te lancer dans l'écriture d'une RFC ni d'une XEP :D).
compléter le diagramme de séquence de la XEP-070 serait bien.
[^] # Re: A propos du token
Posté par pulkomandy (site web personnel, Mastodon) . É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: A propos du token
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
ah oui 449 Retry with est pas mal, comme ce n'était pas associé à une RFC je n'avais pas regardé plus loin… comme quoi Microsoft a du mal à réussir à écrire des RFC :/
une autre doc' documentant l'utilisation possible (c'est en français)
https://http-statuscode.com/fr/code/4XX/449-unofficial
il y a une liste plus exhaustive (dont des codes proposés par NGINX) sur https://oksecu.com/tableau-des-codes-http/ qui fait référence à des RFC 7231 et RFC 7232 et de proche en proche on peut tomber sur https://www.rfc-editor.org/rfc/rfc9110 qui ne définit toujours pas le 449 :/
Il y a https://httpwg.org/specs/rfc9110.html avec plein de références et des annexes précisant les changements pris en compte.
[^] # Re: A propos du token
Posté par pulkomandy (site web personnel, Mastodon) . É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.
# Coquille
Posté par Jona . Évalué à 2 (+0/-0).
s/poitn/point
[^] # Re: Coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Corrigé, merci.
# XMPP est une énorme boîte à outils.
Posté par Goffi (site web personnel, Mastodon) . Évalué à 9 (+7/-0).
Salut,
cool de revoir des gens s'intéresser à ce chouette mécanisme.
C'est super intéressant ta technique pour l'implémenter avec FastCGI !
Note que depuis, OAuth2 a aussi été intégré dans XMPP avec la XEP-0493 (mais là le but c'est plus de se connecter à ton compte XMPP avec un accès potentiellement restreint sans utiliser de mot de passe, ce n'est pas la même chose que la XEP-0070 qui valide l'origine d'une requête HTTP).
Pour Libervia, l'outil de gestion de tickets est basé directement sur XMPP/Pubsub, ce qui permet de publier/retrouver les tickets par XMPP. Est-ce que ça ne t'intéresserait pas de passer à un système similaire ?
Bonne continuation et au plaisir de se re-croiser à un événement futur.
# GitHub
Posté par Julien Jorge (site web personnel) . Évalué à 3 (+1/-0).
C'est à dire ? Sur le plan technique je trouve le service plutôt bon, et je n'ai pas remarqué de dégradations depuis que je l'utilise.
[^] # Re: GitHub
Posté par pulkomandy (site web personnel, Mastodon) . É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: GitHub
Posté par Psychofox (Mastodon) . Évalué à 3 (+1/-1). Dernière modification le 15 septembre 2025 à 10:56.
Je n'utilise github qu'au travail mais je passe essentiellement par les plugins de mon IDE pour la gestion des pull requests et du statut des pipelines.
Il y en a pour nvim, les ide de jetbrains, ceux basés sur vscode, etc sans compter qu'il existe des cli et tui pour github.
# Open Web Auth
Posté par pas_pey . Évalué à 3 (+2/-0).
Sûrement la spec la plus simple, la plus standard, et la plus ouverte pour faire de l'authentification décentralisée à l'échelle du web.
Malheureusement peu connue / utilisée en dehors des créations de Mike Macgirvin (Hubzilla, Streams…).
https://zotlabs.org/page/zot/specs+openwebauth
Couplée à la "magic auth" on obtient du SSO décentralisé.
https://zotlabs.org/help/fr/developer/zot_protocol#Magic_Auth
(il faut scroller en milieu de page).
# Un soucis ?
Posté par Keuronde (site web personnel) . Évalué à 2 (+1/-0).
Bonjour,
Je trouve cette mécanique d'identification très intéressante, mais j'ai l'impression qu'elle n'est pas totalement fonctionnelle.
Avec https://demo.agayon.be/, j'arrive à obtenir une notification dans Movim alors qu'avec ton site je ne reçois rien, ni dans Movim, ni dans Gajim. Alors je ne sais pas trop si c'est un problème de serveur (je suis sur ejabber 23.01), un problème de client ou de ton site…
En tout cas, bravo ! C'est vraiment chouette comme principe !
[^] # Re: Un soucis ?
Posté par pulkomandy (site web personnel, Mastodon) . É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
# XEP-0070 et MAM ne font pas bon ménage
Posté par seveso . Évalué à 2 (+1/-0).
J'ai testé ce mécanisme d'auth XMPP il y a quelques jours. Ça fonctionne, c'est cool, ça m'ouvre plein de perspectives, mais…
J'utilise plusieurs clients XMPP (essentiellement Gajim) selon les situations où je me trouve, et ils sont synchronisés entre eux grâce à MAM.
Du coup, quand je lance un de ces Gajim plusieurs jours après, je re-reçois la demande d'authentification à nouveau (plusieurs demandes en fait, car j'avais fait plusieurs tests).
C'est pas trop user-friendly, c'est même plutôt pénible.
Peut-être que la XEP devrait décourager l'usage de MAM, voire l'interdire explicitement, non ?
Le seul cas où MAM pourrait être utile j'imagine, c'est le cas où on ferait une demande d'authentification avant d'avoir lancé Gajim. Mais même dans ce cas, il me semble que MAM n'est pas nécessaire.
[^] # Re: XEP-0070 et MAM ne font pas bon ménage
Posté par pulkomandy (site web personnel, Mastodon) . É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?
[^] # Re: XEP-0070 et MAM ne font pas bon ménage
Posté par seveso . Évalué à 2 (+1/-0).
Non, effectivement. Je pense que c'est plutôt le serveur XMPP qui devrait exclure du mécanisme MAM ce type de messages.
Je pense que la XEP 0070 devrait préciser cela.
C'est bon à savoir, mais ça ne rend pas le mécanisme plus human-friendly malheureusement :)
Je pense que la spéc devrait d'abord décourager voire interdire l'usage du mécanisme MAM.
La solution de la rétractation me parait plus complexe à implémenter et probablement sources d'autres nouveaux problèmes.
[^] # Re: XEP-0070 et MAM ne font pas bon ménage
Posté par pulkomandy (site web personnel, Mastodon) . É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.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.