Comment le navigateur sait-il quand demander à l'utilisateur de sauvegarder le mot de passe?

j'ai eu le même problème et trouvé une solution:

1. pour que le navigateur demande à stocker le mot de passe, les cases nom d'utilisateur et mot de passe doivent être dans un formulaire et ce formulaire doit être effectivement soumis. Le bouton Soumettre pourrait renvoyer false à partir du gestionnaire onclick (de sorte que le soumettre ne se produit pas réellement).

2. pour que le navigateur restitue le mot de passe précédemment stocké, les boîtes de saisie doivent exister dans le formulaire HTML principal et ne pas être créé par javascript de façon dynamique. Le formulaire peut être créé avec display:none.

il est nécessaire de noter, que le mot de passe est rempli immédiatement sur la page est chargé et est présent pendant toute la session, de sorte qu'il peut être lu par JavaScript injecté: il rend ces attaques bien pire. Pour éviter cela, le renvoi à une page séparée juste pour se connecter est raisonnable, et il résout tous les problèmes pour lesquels vous commencé à lire ce sujet :). Comme solution partielle, j'efface les champs en soumettant le formulaire - si l'utilisateur se déconnecte et veut se connecter à nouveau, le mot de passe n'est pas rempli par le navigateur, mais c'est mineur pour moi.

Viliam

vous devriez regarder la page Mozilla Password Manager Debugging et la page nsILoginManager docs pour les rédacteurs d'extension (juste pour les détails techniques sur la façon dont Firefox gère la gestion des mots de passe). Vous pouvez creuser dans les réponses là - bas et d'autres pages liées là-bas pour en savoir plus que vous avez probablement jamais voulu savoir comment le gestionnaire de mot de passe interagit avec les sites et les extensions.

(plus précisément comme souligné dans le gestionnaire de mot de passe débugging doc, assurez-vous que vous n'avez pas autocomplete réglé à off dans votre html, car cela supprimera l'invite à enregistrer le nom d'utilisateur et le mot de passe)

cela semble fonctionner pour Firefox, Chrome et Safari sur Mac. Pas testé sur Windows.

<form id="bridgeForm" action="#" target="loginframe" autocomplete="on">
    <input type="text" name="username" id="username" />
    <input type="password" name="password" id="password"/>
</form>

<iframe id="loginframe" name="loginframe" src="anyblankpage.html"></iframe>

ceci doit être ajouté à la page. On ne peut pas l'ajouter dynamiquement. La forme et iframe peuvent être configurées pour afficher:none. Si vous ne définissez pas le src de l'iframe, l'invite ne s'affichera pas tant que vous n'aurez pas soumis le formulaire au moins une fois.

appelez Ensuite soumettre le formulaire():

bridgeForm.submit();

l'action peut être facultative et la la saisie semi-automatique peut être facultatif. Ne l'ai pas testé.

Note : sur certains navigateurs, le formulaire doit être exécuté sur un serveur (pas localhost et pas le système de fichiers) avant que le navigateur ne réponde.

donc ceci:

http://www.mysite.com/myPage.html

pas ceci:

http://126.0.0.1/myPage.html

http://localhost/myPage.html

file://directory/myPage.html

fonctionne pour moi avec angular, chrome, firefox: (j'ai cherché et testé pendant des heures - pour le chrome le paramètre d'action de forme ( # ) était la réponse. @1.21 gigawatts , merci!!! Votre réponse était inestimable.)

formulaire

firefox 30.0 - n'a pas besoin d'une iframe cachée et le bouton Soumettre (comme montré ci-dessous), mais a besoin de la directive" login-form-autofill-fix " pour reconnaître l'auto-rempli crédits, comme suit:

<form name="loginForm" login-form-autofill-fix action="#" target="emptyPageForLogin" method="post" ng-submit="login({loginName:grpEmail,password:grpPassword})">
<input type="text" name=username" id="username" ng-model="grpEmail"/>
<input type="password" name="password" id="password" ng-model="grpPassword"/>
<button type="submit">Login</button>
</form>

chrome 35.0 - n'a pas besoin de la directive ci-dessus, mais a besoin d'une iframe cachée et d'un bouton Soumettre sur la forme réelle. L'iframe cachée ressemble à

<iframe src="emptyPageForLogin.html" id="emptyPageForLogin" name="emptyPageForLogin" style="display:none"></iframe>

directive angulaire (utilisant jqLite)

cela fonctionne avec l'angle 1.2.18

module.directive('loginFormAutofillFix', function() { 
            return function(scope, elem, attrs) {
        if(!attrs.ngSubmit) {
            return;
        }
        setTimeout(function() {
            elem.unbind("submit").bind("submit", function(e) {
                //DO NOT PREVENT!  e.preventDefault(); 
                elem.find("input").triggerHandler("input");
                scope.$apply(attrs.ngSubmit);
            });
        }, 0);
});

amendement

• après quelques testing, je me suis rendu compte, que chrome a besoin d'un peu de temps d'arrêt par la méthode de connexion angulaire (200ms) - il semble, la redirection est parfois tout simplement trop rapide pour le gestionnaire de mot de passe.
• mieux nettoyer brownsercache... avec chaque changement

bien, sur notre site , un champ de formulaire avec nom" nom d'utilisateur "type" texte "immédiatement suivi d'un champ avec nom" Mot de passe "et type" mot de passe " semble faire l'affaire.

si vous utilisez AJAX login, jetez un oeil à ce code source: https://gist.github.com/968927

il consiste à soumettre un formulaire de connexion à une iframe cachée, de sorte QU'IE et Chrome peuvent détecter la connexion réelle, sans avoir à recharger la page.

J'ai également remarqué que Chrome ne proposera pas de mémoriser un mot de passe si le formulaire d'ouverture de session est toujours présent après la demande d'ouverture de session, même s'il est caché sur la page.

je suppose qu'il pense que l'action de connexion a échoué et refuse donc de stocker des justificatifs d'identité invalides.

vu sur Chrome 34.0.

les heuristiques sont assez simples ici: détecter des champs avec certains noms dans un certain ordre. Lesquels, je ne peux pas dire, mais cela a bien fonctionné pour moi dans Chrome et IE:

Username field: name "login", type "text";
Password field: name "password", type "password"
Submit button: element "input", type "submit". 
Element "button" type "submit" did not work.

je recommande de regarder le code source de Firefox . C'est en fait un code assez simple.

les méthodes que vous voulez examiner sont _onFormSubmit , _getFormFields et _getPasswordFields .

vous pourriez même trouver le problème que vous avez est infact un bug non découvert dans Firefox ;) https://bugzilla.mozilla.org/show_bug.cgi?id=1211780

si vous avez par exemple deux types = texte dans votre formulaire avant d'entrer le type=mot de passe, Navigateur détecter le type d'entrée le plus proche=texte pour votre nom d'utilisateur.

ce n'est pas une question une autre entrée A est=username et name=username

pour résoudre ce problème, vous devez mettre votre nom d'utilisateur entrée que vous voulez enregistrer exactement avant votre mot de passe d'entrée

Bonne Chance: -)

en plus de tout ce qui a déjà été dit, je me suis rendu compte que les champs d'entrée ne doivent pas être"désactivés". Nous avions un login en plusieurs étapes qui demande d'abord le nom d'utilisateur et ensuite, sur l'écran suivant, le mot de passe. Sur ce second écran nous avons répété l'email mais l'avons désactivé et cela a empêché Chrome et. Al. de reconnaître un champ valide pour le nom d'utilisateur.

comme nous voulions vraiment garder ce champ input désactivé, nous avons fini avec cette solution de contournement:

<input type="text" name="display-username" id="display-username" value="ENTERED_USERNAME" placeholder="Username" disabled="disabled">
<input type="text" name="username" id="username" value="ENTERED_USERNAME" placeholder="Username" style="display: none;">
<input type="password" name="password" id="password" value="" autofocus="autofocus" autocomplete="on" placeholder="Password" required="required">

Je n'irais pas si loin pour recommander ceci, mais peut-être qu'il pointe quelqu'un vers quelque chose dans son propre code:

1. le premier élément affiche le nom d'utilisateur dans un champ d'entrée désactivé. Disabled ne soumet pas dans le formulaire et disabled n'est pas reconnu par le navigateur.
2. le deuxième élément est un champ d'entrée approprié, avec type =" text "et nom/id = "username". C'est d'être reconnu par le navigateur. Dans afin d'empêcher l'utilisateur de l'éditer, nous le masquons avec CSS (display:none).

le mot clé principal est ici,

   <input type="password">