⏫ 👐🏽 🚜 Reconnexion et authentification HTTP de base 📗 💑 ♐️

Les développeurs Web sont conscients depuis longtemps du problème de la connexion et de la connexion aux sites protégés par HTTP Basic Authorization. Bien qu'il existe d'autres méthodes d'authentification qui ne souffrent pas de ce problème, l'autorisation de base reste souvent le meilleur choix. Le réseau dispose de suffisamment de matériel décrivant diverses solutions générales et particulières. Mais tous, que j'ai trouvé, malheureusement, ne décrivent que des solutions partielles qui fonctionnent dans un navigateur et ne fonctionnent pas dans un autre. Sous cat je donne un résultat final généralisé de mes recherches sur ce problème

Je ferai une réservation tout de suite que je ne suis pas un développeur front-end, et je ne suis pas allé dans toute la variété des "marques" et des versions de navigateur. Uniquement avec des versions pertinentes au moment de la rédaction. Pour la plupart des tâches Web, cela suffit. Pour les développeurs qui ont besoin d'un support pour l'ensemble du "zoo" des navigateurs, l'article peut être un bon point de départ.

L'essence du problème est que la norme d'autorisation de base HTTP ne prévoit pas la journalisation. Généralement. Lorsque vous accédez à une page protégée par une autorisation de base, le navigateur lui-même affiche sa propre fenêtre avec une demande de connexion / mot de passe et, avec une connexion réussie, les enregistre quelque part dans ses profondeurs. Ensuite, toutes les demandes ultérieures vers d'autres pages protégées de ce site utiliseront automatiquement ces valeurs dans l'en-tête Autorisation:

Autorisation: Basic bm9uZTpub25l

où bm9uZTpub25l est le lien de connexion / mot de passe encodé en base64 aucun: aucun (votre nom d'utilisateur et votre mot de passe peuvent être différents)

Pour vous connecter, il vous suffit de réinitialiser l'ancien nom d'utilisateur / mot de passe dans les profondeurs du navigateur et sur eux endroit pour en enregistrer de nouveaux. C'est là qu'une surprise nous attend. Puisqu'aucune norme ne régit cette action, chaque navigateur le fait à sa guise.

Pire encore, puisque la fenêtre de demande de login / mot de passe est sa propre fenêtre de navigateur, qui ne répond déjà qu'aux en-têtes de page HTTP, cette fenêtre apparaît avant tout traitement du corps de la page. Autrement dit, exécuter du javascript lors de la réception d'une réponse du serveur avec un état de 401 ne fonctionne pas. Avant l'utilisateur, cette fenêtre apparaîtra encore et encore avec une demande répétée de connexion / mot de passe.

En fait, ce point est critique, car pour presque tous les navigateurs, la seule façon de se déconnecter est d'envoyer une demande au serveur avec un login / mot de passe manifestement incorrect, de recevoir une réponse du serveur avec le statut 401, puis de réinitialiser le cache de login / mot de passe du navigateur. Mais si en même temps le navigateur ne vous permet pas de traiter la réponse 401 et de poursuivre le processus de connexion déjà pour le nouvel utilisateur, en prenant le contrôle même au stade de la lecture des en-têtes HTTP et en lançant la forme même d'autorisation dans laquelle vous le saisissez ne fonctionnera pas en face, alors ceci déjà un problème. Peu importe qu'il s'agisse d'une demande normale par référence ou XMLHttpRequest ou fetch. Le navigateur prend toujours le contrôle au stade de l'analyse des en-têtes.

Donc…

Donnée initiale:

Il existe une page logout.html distincte sur laquelle toute la logique se trouve dans le script javascript, dont certaines parties sont données au cours de la présentation
URL spécifiée - adresse de la page à rediriger après une connexion réussie
Url401 est spécifié - l'adresse de la page qui renvoie toujours l'erreur HTTP 401 (non autorisée)

// file logout.html
const url = new URL("http://mysite.com/");
const url401 = new URL("http://mysite.com/401");

Internet Explorer

Notre produit ne nécessite pas de support pour ce navigateur, donc la solution que je n'ai pas personnellement testée. Néanmoins, selon Google, il existe une solution, et c'est peut-être la plus simple et la plus élégante de toutes. De plus, je n'ai jamais rencontré d'informations indiquant que cette solution pour les navigateurs Microsoft a perdu de sa pertinence:

if (document.execCommand("ClearAuthenticationCache")) {
    window.location.assign(url);
}

Dans IE, il existe une méthode ClearAuthenticationCache qui élimine «ces entrailles très profondes». Simple et élégant. Et pas de danse avec la page auxiliaire 401. Je ne sais pas si cette méthode fonctionne dans Edge. Probablement oui.

La construction document.execCommand renvoie true si la méthode existe et "a fonctionné". Ensuite, window.location.assign (url) redirige l'utilisateur pour entrer un nouveau nom d'utilisateur et mot de passe

Firefox (72.0.1)

Dans le cadre de notre tâche, c'est le navigateur le plus problématique. Pour lui, une solution complète n'existe toujours pas. Depuis 15-20 ans, une demande pour le problème indiqué est suspendue dans le tracker de bug de l'équipe de ses développeurs. Mais «les choses sont toujours là». Le maximum qui peut être atteint est la courbe razlogin.

Entrée:
Firefox ne réinitialise pas le cache de mot de passe après avoir reçu une réponse 401 via XMLHttpRequest ou une demande de récupération. Uniquement via une demande régulière avec le login / mot de passe dans l'URL elle-même. Autrement dit, quelque chose comme

http: // aucun: aucun@mysite.com/

Le code:

else if (/firefox|iceweasel|fxios/i.test(window.navigator.userAgent)) {
    url.username = 'none';
    url.password = 'none';
    window.location.assign(url);
}

Après quoi l'utilisateur reçoit un formulaire de saisie de login / mot de passe, dans lequel tout ce que vous entrez, il apparaîtra encore et encore. Le fait est que les valeurs saisies ne remplaceront pas les valeurs de login / mot de passe spécifiées dans l'URL. Autrement dit, au lieu des valeurs saisies, un tas de rien: aucun n'ira au serveur à chaque fois. Et pour vous connecter sous un autre nom, l'utilisateur doit cliquer sur Annuler, aller sur la page de démarrage (http: //mysite.com/) et y entrer un nouveau login / mot de passe.

Courbé? Mais hélas, il n'y a pas d'autre solution

Google Chrome (79.0.3945.88)

Pour Chrome, la méthode de récupération fonctionne très bien. Mais XMLHttpRequest ne fonctionne pas ((((Le cache n'est pas réinitialisé et la journalisation ne se produit pas. De plus, j'ai essayé de définir le login / mot de passe à la fois comme paramètres pour la méthode ouverte et pour définir l'en-tête.

else if (/chrome/i.test(window.navigator.userAgent)) {
    fetch(url401, {
      credentials: 'include',
      headers: {
        'Authorization': 'Basic ' + btoa('none:none'),
        'X-Requested-With': 'XMLHttpRequest'
      }
    }).then(() => {
      window.location.assign(url);
    }).catch(err => console.error(err));
}

Nous faisons une demande de récupération à la page 401 avec un nom d'utilisateur / mot de passe manifestement incorrect, nous obtenons une réponse 401 du serveur, le navigateur vide son cache.

IMPORTANT! Le serveur ne doit PAS renvoyer un en - tête WWW-Authenticate . Sinon, le navigateur prendra le contrôle et les redirections à partir de la page 401 ne se produiront jamais. Par convention, le serveur ne doit pas retourner cet en-tête si X-Requested-With: XMLHttpRequest est spécifié dans la demande . Par conséquent, l'en - tête X-Requested-With a été ajouté à la demande .

Safari (12)

Pour Safari, la situation est exactement le contraire: XMLHttpRequest fonctionne, mais la récupération ne fonctionne pas

else {
    const xhr = new XMLHttpRequest();
    xhr.open("GET", url401, true, 'none', 'none');
    xhr.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
    xhr.onerror = function(err) {
      console.error(err);
    };
    xhr.onload = function () {
      window.location.assign(url);
    };
    xhr.send()
}

Les actions sont les mêmes que dans Chrome, uniquement via XMLHttpRequest

Devrait fonctionner pour les versions de Safari 6+. Les versions antérieures avaient leurs propres bogues. En particulier, par exemple, dans les versions à partir de 5.1, à chaque redirection, le navigateur a de nouveau demandé l'autorisation, ce qui explique pourquoi l'autorisation avec redirection vers la page finale ne fonctionnait pas en principe. Et dans les versions antérieures à 5.0, la journalisation ne fonctionnait pas.

Reconnexion et authentification HTTP de base

Donnée initiale:

Internet Explorer

Firefox (72.0.1)

Google Chrome (79.0.3945.88)

Safari (12)

More articles: