l'authentification http de base "log out"

Question

L'authentification HTTP de base les informations d'identification sont stockées jusqu'à ce que le navigateur est fermé, mais est-il un moyen de supprimer les informations d'identification avant que le navigateur est fermé?

J'ai lu sur un truc avec le code d'état HTTP 401, mais il semble que ce travail n'est pas correctement (voir le commentaire de répondre). Peut-être que le mécanisme de trac utilise est la solution.

Peut les pouvoirs doivent être supprimés à l'aide de JavaScript? Ou avec une combinaison de JavaScript et de l'état 401 truc?

Answer 1

Mise à jour: Cette solution ne semble pas fonctionner dans la plupart des navigateurs. Kaitsu commentaire:

Cette solution d'envoi de fausses informations d'identification pour effectuer navigateur oublier le bon authentifié informations d'identification ne fonctionne pas sous Chrome (16) et IE (9). Fonctionne dans Firefox (9).

---

En fait, vous pouvez mettre en œuvre une solution de contournement en envoyant de fausses informations d'identification pour le service. Cela fonctionne dans les Navigateurs par l'envoi d'un autre (inexistante?) Nom d'utilisateur sans mot de passe. Le Navigateur perd les informations sur les authentifié informations d'identification.

Exemple:

https://www.example.com/ => ouverture de session avec l'authentification basique comme "user1"

Ouvrez maintenant

https://foobar@www.example.com/

Vous êtes Connecté. ;)

Ce qui concerne

P. s.: Mais s'il vous plaît tester avec tous les nécessaires Navigateurs avant de s'appuyer sur l'information donnée.

Answer 2

Vous pouvez essayer un hack qui fonctionne pour le moment avec le dernier Chrome et Firefox. Créer un "/déconnexion", page sur votre serveur qui n'accepte que certaines informations d'identification, telles que nom d'utilisateur: false, mot de passe: c'est faux. Ensuite, à l'aide de cette requête AJAX ci-dessous, vous pouvez envoyer l'utilisateur vers la page.

  $("#logout").click(function(e){                                              
    e.preventDefault();                                                        
    var request = new XMLHttpRequest();                                        
    request.open("get", "/logout", false, "false", "false");                                                                                                                               
    request.send();                                                            
    window.location.replace("WHEREVER YOU WANT YOUR LOGGED OUT USER TO GO");                                              
  });

Ce qui se passe est que le faux nom d'utilisateur et le mot de passe est mis en cache à partir de la validité de la XMLHttpRequest au lieu de l'utilisateur, et lorsqu'un utilisateur tente de se connecter sur n'importe quelle page, il va utiliser la mise en cache de fausses informations d'identification, à défaut de s'authentifier, il va demander à l'utilisateur d'entrer un autre. Espérons que cette aide!

Answer 3

vient de terminer une mise en œuvre qui a bien fonctionné pour moi: Sur le serveur je évaluer Session, le Nom d'Utilisateur et le mot de passe, j'ai donc garder une trace de ces informations, la connexion algorithme est comme suit:

1.Vérifier si l'utilisateur et le mot de passe n'est pas vide, sinon retour 401.

2.Vérifier si nous avons bien enregistré la session dans notre connecté dans la liste des utilisateurs, si ce n'est de vérifier ensuite si l'utilisateur et le mot de passe est valide, et si donc enregistrer l'id de session dans notre liste, puis retour 401. Je vais vous expliquer cette étape: si l'id de session est différente l'une des trois choses qui s'est passé: a) L'utilisateur est l'ouverture d'une autre fenêtre. b) La session de l'utilisateur a terminé, c'est à dire que l'utilisateur est connecté. c) La session a expiré en raison de l'inactivité. Mais nous voulons sauver la session de l'utilisateur informations d'identification sont valides, mais de retour 401 de demander une fois de mot de passe, si nous n'avons pas d'enregistrer la session de l'utilisateur pourrait ne jamais se connecter car nous n'avons pas le nouvel id de session dans notre liste.

3.Vérifiez si les informations d'identification utilisateur sont droit, le cas échéant, enregistrer les informations de la session et de continuer à servir des pages, sinon retour 401.

Alors, la seule chose que j'ai à la déconnexion d'un utilisateur est de fermer la session sur le serveur lorsque l'utilisateur demande la page de déconnexion et le navigateur web affiche de nouveau la boîte de dialogue de connexion.

Je pense que je vous écris ce qu'il y a une étape où le programme vérifie si l'utilisateur est déjà connecté à éviter l'usurpation d'identité, peut-être que je peux sauver plus d'un id de session par l'utilisateur pour permettre à plusieurs session, eh bien, j'aimerais vos commentaires à ce sujet.

J'espère que vous obtenez l'idée, et de commenter si vous voyez une faille de sécurité ;)

Answer 4

Vous pouvez supprimer les informations d'identification avec le JavaScript:

    $("#logout").click(function(){
        try {
            document.execCommand("ClearAuthenticationCache");
            window.location.href('/logout.html'); // page with logout message somewhere in not protected directory
        } catch (exception) {}
    });

Ce code ne fonctionne que sous IE. C'est la raison pour laquelle bloc try/catch y est ajoutée. Aussi, pour la même raison, le lien de déconnexion vous devez vous présenter pour les utilisateurs de IE uniquement:

    <!--[if IE]>
        <div id="logout">[Logout]</div>
    <![endif]-->

Et pour les autres utilisateurs, ma suggestion est quelque chose comme:

    <div id="logout2" onclick="alert('Please close your browser window to logout')">[Logout]</div>

Answer 5

Si vous avez le contrôle sur le code du serveur, vous pouvez créer une "déconnexion" de la fonction que les réponses "401 Unauthorized", indépendamment de l'identification donnée. Cet échec les forces de navigateurs pour supprimer les informations d'identification enregistrées.

Je viens de testé avec Chrome 34, IE 11, Firefox 25 - à l'aide de Express.js serveur et l'authentification HTTP de base.