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...
[^] # 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.
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...