Désactivation de Safari autofill sur les noms d'utilisateur et les mots de passe

j'ai eu le même problème. Et bien que ma solution ne soit pas parfaite, elle semble fonctionner. Fondamentalement, Safari semble chercher un champ d'entrée avec mot de passe et nom d'utilisateur et tente toujours de le remplir. Donc, ma solution était d'ajouter un faux nom d'utilisateur et mot de passe champ avant le courant que Safari pourrait remplir. J'ai essayé d'utiliser style="display: none;" mais cela ne fonctionne pas. Donc, finalement, j'ai juste utilisé style="position:absolute; top:-50px;" et ceci a caché le champ d'entrée hors de vue et a semblé fonctionner très bien. Je ne voulais pas utiliser JavaScript mais je vous pourriez le cacher avec JavaScript.

maintenant Safari n'a jamais autocompleté mes champs Nom d'utilisateur et mot de passe.

La raison navigateurs ignorent autocomplete=off est parce qu'il y a eu des sites Web qui ont essayé de désactiver l'auto-completing des mots de passe.

C'est faux.

et en juillet 2014, Firefox a été le dernier navigateur majeur à finalement mettre en œuvre le changement pour ignorer tout site web qui essaie de désactiver l'autocompleting des mots de passe.

• juin 2009: ieinternals blog où ils discutent de garder le contrôle de l'utilisateur (archive)
• février 2014: Annonce de Chrome quand ils ont commencé à ignorer autocomplete=off (archive)
• janvier 2014: Bugzilla bogue 956906-ignorer autocomplete= "off" en proposant de sauvegarder les mots de passe via le gestionnaire de mots de passe (archive)
• Reddit discussion (archive)

L'une des principales plaintes des utilisateurs à propos de notre fonctionnalité AutoComplete de formulaires HTML est "Elle ne fonctionne pas– je ne vois aucun de mes précédemment saisie de texte." lors du débogage de tels cas, nous constatons habituellement que le site a explicitement désactivé la fonctionnalité en utilisant l'attribut fourni, mais bien sûr, les utilisateurs n'ont aucune idée que le site l'a fait et supposent simplement que IE est bogué. Selon mon expérience, lorsque les fonctionnalités sont cachées ou remplacées, les utilisateurs blâmeront généralement le navigateur, pas le site web.

Tout toute tentative par un site Web de contourner la préférence du navigateur est erronée, c'est pourquoi les navigateurs l'ignorent. Il n'y a aucune raison connue pour qu'un site Web essaie de désactiver la sauvegarde des mots de passe.

• Chrome l'ignore
• Safari l'ignore
• IE ignore it
• Firefox l'ignore

À ce stade, les développeurs web généralement de protestation " mais je ne le ferais pas partout– seulement dans quelques petits bouts où il de bon sens!" Même si c'est vrai, malheureusement, c'est encore un autre cas où il n'y a vraiment aucun moyen pour le navigateur de faire la différence. Rappelez-vous, fenêtres popup ont été une fois une partie heureuse et utile de l'expérience de navigation sur le web, jusqu'à ce que leur abus par les annonceurs ont fait d'eux le fléau des utilisateurs partout. Inévitablement, tous les navigateurs ont commencé à bloquer les popups, cassant même les "bons" sites qui ont utilisé des popups avec bon goût et discrétion.

et si je suis un spécial flocon de neige?

Il y a des gens qui mettent en place un bon cas d'utilisation:

j'ai un espace public partagé, un ordinateur de style kiosque. Nous ne voulons pas de quelqu'un (accidentellement ou intentionnellement) enregistrer leur mot de passe pour l'utilisateur suivant.

ne pas enfreindre la déclaration:

toute tentative par un site web de contourner la préférence du navigateur est fausse

c'est parce Que dans le cas d'un kiosque:

• ce n'est pas le serveur web qui a l'excentrique de la politique
• c'est le client user-agent qui a l'excentrique de la politique

navigateur (l'ordinateur partagé) est celui qui a l'obligation qu' n'essayez pas de sauvegarder les mots de passe.

la bonne façon d'empêcher le navigateur de l'épargne les mots de passe

est de configurer le navigateur de ne pas sauvegarder les mots de passe.

depuis que vous avez verrouillé et contrôlé cet ordinateur de kiosque: vous contrôlez les paramètres. Cela inclut la possibilité de sauvegarder les mots de passe.

dans Chrome et Internet Explorer, vous configurez ces options en utilisant des politiques de groupe (par exemple des clés de registre).

Chrome Politique De La Liste:

AutoFillEnabled

Activer La Saisie Automatique

Type de données: Boolean (REG_DWORD)

registre Windows emplacement: Software\Policies\Chromium\AutoFillEnabled

Description: active la fonction de remplissage automatique de Chromium et permet aux utilisateurs de remplir automatiquement des formulaires Web en utilisant des informations stockées précédemment telles que l'adresse ou les informations de carte de crédit. Si vous désactivez ce paramètre, AutoFill être inaccessible aux utilisateurs. Si vous activez ce paramètre ou ne définissez pas la valeur, la fonction remplissage automatique restera sous le contrôle de l'utilisateur. Cela leur permettra de configurer les profils de remplissage automatique et d'activer ou de désactiver le remplissage automatique à leur propre discrétion.

s'il vous plaît passer le mot jusqu'à des gestionnaires d'entreprise que d'essayer de désactiver autocompleting de mot de passe est erroné. Il est tellement mauvais que les navigateurs sont délibérément d'ignorer quelqu'un qui essaie de le faire. Ces gens devraient arrêter de faire le mal chose.™

correction: remplissage automatique du navigateur en mode Lecture seule et mise en écriture sur focus

 <input type="password" readonly onfocus="this.removeAttribute('readonly');"/>

(focus = au clic de la souris et de la tabulation à travers les champs)

mise à Jour: Le Safari Mobile place le curseur sur le terrain, mais n'affiche pas le clavier virtuel. New Fix fonctionne comme avant mais gère le clavier virtuel:

<input id="email" readonly type="email" onfocus="if (this.hasAttribute('readonly')) {
    this.removeAttribute('readonly');
    // fix for mobile safari to show virtual keyboard
    this.blur();    this.focus();  }" />

Démonstration https://jsfiddle.net/danielsuess/n0scguv6/

/ / UpdateEnd

Explication: Le navigateur remplit automatiquement les justificatifs d'identité au mauvais champ de texte?

Ok, vous venez de remarquer que:

Safari remplissage automatique des coups de pied dans. Peu importe [ce que les champs sont nommés] @Jari

et il y a une supposition que:

Safari semble chercher un champ d'entrée avec mot de passe et nom d'utilisateur et tente toujours de le remplir @user3172174

Parfois je remarque cette étrange comportement sur Chrome et Safari, quand il y a des champs de mot de passe dans sur le même formulaire. je suppose que le navigateur cherche un champ de mot de passe pour insérer vos identifiants enregistrés. Puis il autofills nom d'utilisateur dans le champ textlike-input le plus proche, qui apparaît avant le champ password dans les DOM (juste deviner en raison de l'observation). Tant que le navigateur est la dernière instance et vous ne pouvez pas le contrôler,

parfois même autocomplete=off ne serait pas empêcher de remplir les justificatifs d'identité dans les mauvais champs, mais pas le champ user ou surnom.

Cette simple correction ci-dessus a fonctionné pour moi.

::-webkit-contacts-auto-fill-button, ::-webkit-credentials-auto-fill-button {
    visibility: hidden;
    pointer-events: none;
    position: absolute;
    right: 0;
}

Après la numérisation à l'aide de Apple Safari HTML pages et de ne pas trouver sur auto complete, j'ai fait un peu de recherche et de réflexion.

Après la lecture de a (modérément) question connexe sur les discussions Apple, je me suis rappelé que la valeur par défaut est de ne pas autoriser les mots de passe mémorisés, etc (qui peuvent être activés dans les paramètres du système iDevice, ou à l'invite). Depuis Apple a déplacé cette fonctionnalité hors du navigateur et dans leur (propriétaire, I)OS (captures d'écran sur cet article), je crois qu'ils ignorent complètement la propriété HTML form/field.

à moins qu'ils ne changent leur mentalité quant à cette fonctionnalité, car je suis sûr que c'est leurs comportement attendu, sur leurs appareils verrouillés, je suppose que cela ne va pas disparaître. C'est probablement différent pour les applications natives iOS. Gardez définitivement la forme autocomplete= " off " et espérons qu'ils reviendront un jour au HTML5 standard pour la fonction.

je sais que cela ne comprend pas les contourner, mais je pense que si vous venez de composer avec un navigateur en option sur les iDevices, elle a un sens (dans un Apple sorte de moyen).

cette question a déjà été répondue avec succès, mais à la date d'aujourd'hui, la solution ne fonctionnait pas pour moi sans faire quelques changements curieusement particuliers - donc je le note ici autant pour ma propre référence si je décide d'y revenir que pour tout le monde.

• La fausse entrée doit être après la véritable entrée de courrier électronique dans le dom.
• le faux input nécessite une fausse étiquette.
• La fausse étiquette ne peut pas être absolument positionner.
• ne peut pas utiliser l'affichage, la visibilité ou l'opacité pour cacher les faux éléments.

la seule solution que j'ai trouvée était de couper la visibilité des faux éléments avec overflow: hidden.

<label for="user_email">Email</label>
<input autocomplete="off" type="text" value="user@email.com" name="user[email]" id="user_email">
<!-- Safari looks for email inputs and overwrites the existing value with the user's personal email. This hack catches the autofill in a hidden input. -->
<label for="fake_email" aria-hidden="true" style="height: 1px; width: 1px; overflow: hidden; clip: rect(1px, 1px, 1px, 1px)">Email</label>
<input type="text" name="fake[email]" id="fake_email" style="height: 1px; width: 1px; overflow: hidden; clip: rect(1px, 1px, 1px, 1px)" tab-index="-1" aria-hidden="true">

pour mémoire, le cas particulier pour lequel ce hack est venu utile était celui où un administrateur éditait le profil des autres utilisateurs et où Safari remplaçait le courriel de l'utilisateur par le courriel de l'administrateur. Nous avons décidé que pour la petite (mais frustrant) quantité parmi les requêtes de support que cette "fonctionnalité" Safari crée, il n'est pas utile de maintenir un hack qui semble devoir évoluer au fur et à mesure que le Safari se resserre sur lui, et au lieu de cela fournir un support à ces utilisateurs sur la façon de désactiver autofill.

Je ne peux pas croire que ce soit encore un problème si longtemps après qu'il ait été signalé. Les solutions ci-dessus ne fonctionnaient pas pour moi, comme safari semblait savoir quand l'élément n'était pas affiché ou hors-écran, cependant les suivantes ont fonctionné pour moi:

<div style="position:absolute;height:0px; overflow:hidden; ">
  Username <input type="text" name="fake_safari_username" >
  Password <input type="password" name="fake_safari_password">
</div>

j'Espère que c'est utile pour quelqu'un!

J'ai également été mordu par le comportement bizarre de Safari par défaut autocomplete, mais plutôt que de le désactiver complètement, j'ai réussi à le faire fonctionner pour moi en suivant les directives à https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands.

spécifiquement, je mets autocomplete="username" dans le champ nom d'utilisateur et autocomplete="password-current" sur le champ password. Cela indique au navigateur les champs à auto-remplir, plutôt que de le faire deviner, et il corrigé la saisie semi-automatique pour mon cas d'utilisation.

cette approche fonctionne à la fois pour les formulaires de connexion "email first" (le champ Mot de passe n'est pas immédiatement visible, par exemple Google login) et pour les formulaires de connexion traditionnels avec les champs Nom d'utilisateur et mot de passe visibles.

Vous pouvez essayer cette variante. Il fonctionne pour moi. Si vous changez la valeur du champ une fois, Safari la changera à nouveau. Si l'utilisateur clique sur ce champ, après cela la valeur ne sera pas modifiée automatiquement par Safari.

  $.browser.chrome = /chrome/.test(navigator.userAgent.toLowerCase());
        if($.browser.chrome){
            $.browser.safari = false;
        }

        var isChanged=false;

        $('#Email').change(function () {
            if ($.browser.safari && !isChanged) {
                $('#Email').val('@Model.Email');
            }
        });

        $('#Email').click(function () {
            if ( $.browser.safari && !isChanged) {
                isChanged = true;
            }
        }); var isChangePassword = false;
    $('#OldPassword').change(function () {
        if ($.browser.safari && !isChangePassword) {
            $('#OldPassword').val('');
        }
    });

    $('#OldPassword').click(function () {
        if ($.browser.safari && !isChangePassword) {
            isChangePassword= true;
        }
    });

il semble que les programmeurs du navigateur pensent en savoir plus que les rédacteurs du site. Bien qu'il soit parfois pratique de permettre à l'utilisateur de sauvegarder les mots de passe, il y a d'autres moments où c'est un risque de sécurité. Pour l'époque, cette solution de contournement peut aider:

commencez par utiliser une entrée de texte conventionnelle, au lieu du type 'password'.

Password: &nbsp <input type="text" id="fkpass" name="bxpass" class="tinp" size="20" />

puis - si vous le souhaitez-mettez le focus sur le champ input.

<BODY onLoad="fitform()">

mettez le JS à la fin de la page.

<script type="text/javascript">
document.entry.fkpass.focus();
function fitform() {
document.getElementById('fkpass').autocomplete = 'off';
}
</script>

Maintenant vous avez un champ de forme conventionnel. A quoi bon le faire?

Changer le style CSS pour cette entrée de sorte qu'il utilise une police qui est tout "bullets" au lieu de caractères.

<style type="text/css">
@font-face { font-family: fdot; src: url('images/dot5.ttf'); }
@font-face { font-family: idot; src: url('images/dot5.eot'); }
@font-face { font-family: wdot; src: url('images/dot5.woff'); }
@font-face { font-family: w2dot; src: url('images/dot5.woff2'); }
.tinp { font-family: fdot, idot, wdot, w2dot; color: #000; font-size:18px; }
</style>

Oui, on le peut "nettoyer" le code, et ajouter .svg.

D'une façon ou d'une autre, le résultat final est indiscernable de la saisie 'réelle' du mot de passe, et le navigateur ne proposera pas de le sauvegarder.

si vous voulez la police, c'est ici. Il a été créé avec CorelDraw et converti avec un utilitaire de conversion webfont en ligne. (dot_webfont_kit.zip 19.3 k)

j'espère que cette aide.

Supprimer <form> élément. Pour garder la forme comportement que vous pouvez écouter keypress événement pour les champs de saisie pour gérer enter enfoncée. Juste au cas où, je l'ai enlevé input type="submit" trop. Vous pouvez utiliser button type="button".

mieux que d'utiliser JS pour effacer le contenu-champ faux mot de passe:

<input type="text" name="user" />
<input fake_pass type="password" style="display:none"/>
<input type="password" name="pass" />

password type doublé mettre le navigateur dans l'incertitude de sorte qu'il autocompletes que le nom de l'utilisateur

fake_pass input ne devrait pas avoir d' name attribut à conserver $_POST nettoyer!

Mon problème: j'ai un article dans une zone d'administration qui permet aux utilisateurs de définir toutes les langues des valeurs, qui contiennent les mots "mot de passe", "email", "adresse électronique", etc. Je ne veux pas que ces valeurs soient remplies avec les détails de l'utilisateur, elles sont pour créer des traductions dans une autre langue. Il s'agit alors d'une exception valide à la "contourner la préférence du navigateur" mentionnée.

ma solution: j'ai simplement créé suppléant noms:

$name = str_replace('email','em___l',$name);
$name = str_replace('password','pa___d',$name);

<input type="text" name="<?=$name?>" id="<?=$name?>" />

puis quand le formulaire est affiché:

foreach($_POST as $name=>$value) {
    $name=str_replace('em___l','email',$name);
    $name=str_replace('pa___d','password',$name);
    $_POST[$name]=$value;
}

C'est la seule méthode qui a fonctionné pour moi.

Le CSS display: none les solutions mentionnées ici n'ont pas fonctionné pour moi (octobre 2016). J'ai corrigé ce problème avec JavaScript.

cela ne me dérange pas que le navigateur se souvienne des mots de passe, mais je voulais éviter une mauvaise auto-remplir. Dans mon cas, un formulaire avec un champ de mot de passe et aucun champ nom d'utilisateur. (Le formulaire d'édition d'utilisateur dans le site Drupal 7, où le champ de mot de passe est requis seulement pour certaines opérations.) Quoi que j'ai essayé, Safari a trouvé un champ victime pour le nom d'utilisateur du mot de passe auto rempli (le champ visuellement avant, par exemple).

je vais restaurer la valeur originale dès que Safari aura fait l'autofill. J'essaie ça seulement les 2 premières secondes après le chargement de la page. Probablement même valeur inférieure est OK. Mes tests ont montré que l'auto-remplissage se produit environ 250 ms après le chargement de la page (bien que j'imagine que ce nombre dépend beaucoup de la façon dont la page est construite et chargée).

// Workaround for Safari autofill of the e-mail field with the username.
// Try every 50ms during 2s to reset the e-mail to its original value.
// Prevent this reset if user might have changed the e-mail himself, by
// detecting focus on the field.
if ($('#edit-mail').length) {
  var element = $('#edit-mail');
  var original = element.attr('value');
  var interval = setInterval(function() {
    if ($(document.activeElement).is(element)) {
      stop();
    } else if (element.val() != original) {
      element.val(original);
      stop();
    }
  }, 50);
  var stop = function() {
    clearTimeout(timeout);
    clearInterval(interval);
  }
  var timeout = setTimeout(function() {
    clearInterval(interval);
  }, 2000);
}

j'ai eu le même problème soudainement dans un SPA avec React dans Mobile Safari 10.3.1

Je n'ai pas besoin de solutions de rechange délicates avant dans tous les navigateurs testés, même les Safari mobiles iOS 10.2

mais puisque 10.3.1 nom d'utilisateur ou mot de passe sera rempli dans les champs mentionnant les mots "password", "email", "username" dans tous les formulaires après l'ouverture de session avec l'option active remember. Il semble que le DOM-Tree rendu soit 'analysé' en utilisant une recherche plein texte puis l'agent utilisateur remplir les données sans respecter aucun paramètre autocomplete="off". Arrive funnyli aussi sur le texte placeholder pour un champ. Ainsi, vous devez être très soigneux avec le nom, quand vous ne voulez pas avoir pré-rempli le nom d'utilisateur ou le mot de passe dans les endroits où ces données ne sont pas utiles.

la seule solution après des heures d'enquête a été la solution ici posté aussi. Fournir un champ d'entrée nommé "email" et cacher la div contenant avec hauteur: 0px, overflow: hidden.