Jak mogę sprawić, by przeglądarka poprosiła o zapisanie hasła?

149

Hej, pracuję nad aplikacją internetową, która ma okno dialogowe logowania, które działa tak:

  1. Użytkownik klika „zaloguj”
  2. Formularz logowania HTML jest ładowany za pomocą AJAX i wyświetlany na stronie w DIV
  3. Użytkownik wpisuje użytkownika / przepustkę w pola i klika „Prześlij”. To NIE jest <form>- użytkownik / przepustka są przesyłane przez AJAX
  4. Jeśli użytkownik / hasło są w porządku, strona ładuje się ponownie, gdy użytkownik jest zalogowany.
  5. Jeśli użytkownik / hasło są złe, strona NIE ładuje się ponownie, ale w DIV pojawia się komunikat o błędzie i użytkownik może spróbować ponownie.

Oto problem: przeglądarka nigdy nie wyświetla zwykłego monitu „Zapisać to hasło? Tak / Nigdy / Nie teraz”, jak w przypadku innych witryn.

Próbowałem opakować tagi <div>in <form>z „autocomplete = 'on'”, ale to nie miało znaczenia.

Czy można sprawić, by przeglądarka zaoferowała przechowywanie hasła bez poważniejszej przeróbki mojego przepływu logowania?

dzięki Eric

ps aby dodać do mojego pytania, zdecydowanie pracuję z przeglądarkami przechowującymi hasła i nigdy nie kliknąłem „nigdy dla tej witryny” ... jest to problem techniczny polegający na tym, że przeglądarka nie wykrywa, że ​​jest to formularz logowania, a nie błąd operatora :-)

Eric
źródło
Nie zapominaj, że nie wszystkie przeglądarki mogą przechowywać hasła.
Buhake Sindi
1
Sprawdź, czy przeglądarka zaproponowała zapisanie Twojego użytkownika / hasła i kliknąłeś „Nigdy więcej nie pytaj!” ?
clyfe
1
Związane z: stackoverflow.com/questions/6142725/ ...
user123444555621

Odpowiedzi:

72

Znalazłem kompletne rozwiązanie tego pytania. (Przetestowałem to w Chrome 27 i Firefox 21).

Należy wiedzieć dwie rzeczy:

  1. Wyzwalacz „Zapisz hasło” i
  2. Przywróć zapisaną nazwę użytkownika / hasło

1. Uruchom „Zapisz hasło”:

W przypadku przeglądarki Firefox 21 funkcja „Zapisz hasło” jest uruchamiana, gdy wykryje, że istnieje formularz zawierający pole wejściowe i pole hasła. Więc po prostu musimy użyć

$('#loginButton').click(someFunctionForLogin);
$('#loginForm').submit(function(event){event.preventDefault();});

someFunctionForLogin() wykonuje logowanie AJAX i przeładowuje / przekierowuje do zalogowanej strony podczas event.preventDefault() blokując oryginalne przekierowanie z powodu przesłania formularza.

Jeśli masz do czynienia tylko z Firefoksem, powyższe rozwiązanie jest wystarczające, ale nie działa w Chrome 27. Następnie zapytasz, jak uruchomić opcję „Zapisz hasło” w Chrome 27.

W przeglądarce Chrome 27 „Zapisz hasło” jest uruchamiane po przekierowaniu na stronę przez przesłanie formularza zawierającego pole tekstowe z nazwą atrybutu = „nazwa użytkownika” i pole hasła z nazwą atrybutu = „hasło” . Dlatego nie możemy zablokować przekierowania z powodu przesłania formularza, ale możemy wykonać przekierowanie po zalogowaniu się w AJAX. (Jeśli chcesz, aby login ajax nie przeładowywał strony lub nie przekierowywał do strony, niestety moje rozwiązanie nie działa.) Następnie możemy użyć

<form id='loginForm' action='signedIn.xxx' method='post'>
    <input type='text' name='username'>
    <input type='password' name='password'>
    <button id='loginButton' type='button'>Login</button>
</form>
<script>
    $('#loginButton').click(someFunctionForLogin);
    function someFunctionForLogin(){
        if(/*ajax login success*/) {
            $('#loginForm').submit();
        }
        else {
            //do something to show login fail(e.g. display fail messages)
        }
    }
</script>

Przycisk z type = 'button' spowoduje, że formularz nie zostanie wysłany po kliknięciu przycisku. Następnie przypisujemy funkcję do przycisku logowania Ajax. Wreszcie wywołanie $('#loginForm').submit();przekierowuje do strony zalogowanej. Jeśli stroną, na której się zalogowano, jest bieżąca strona, możesz zastąpić „signedIn.xxx” bieżącą stroną, aby „odświeżyć”.

Teraz przekonasz się, że metoda dla przeglądarki Chrome 27 działa również w przeglądarce Firefox 21. Dlatego lepiej jej używać.

2. Przywróć zapisaną nazwę użytkownika / hasło:

Jeśli masz już loginForm zakodowany na stałe w formacie HTML, nie będzie problemu z przywróceniem zapisanego hasła w loginForm.
Jednak zapisana nazwa użytkownika / hasło nie zostanie powiązana z loginForm, jeśli użyjesz js / jquery do dynamicznego utworzenia formularza loginForm, ponieważ zapisana nazwa użytkownika / hasło jest wiążąca tylko podczas ładowania dokumentu.
Dlatego trzeba było na stałe zakodować loginForm jako HTML i użyć js / jquery, aby dynamicznie przenosić / pokazywać / ukrywać loginForm.


Uwaga: Jeśli logujesz się do AJAX, nie dodawaj autocomplete='off'tagów w postaci

<form id='loginForm' action='signedIn.xxx' autocomplete='off'>

autocomplete='off' spowoduje, że przywrócenie nazwy użytkownika / hasła do formularza loginForm nie powiedzie się, ponieważ nie zezwalasz na to, że „automatycznie uzupełnia” nazwę użytkownika / hasło.

Przestrzeń czasowa7
źródło
2
W przeglądarce Chrome funkcja „event.preventDefault ()” zapobiega wyświetlaniu monitu „Zapisz hasło”, zobacz ten błąd: code.google.com/p/chromium/issues/detail?id=282488
mkurz
Dla każdego, kto się na to natknie, myślę, że wydaje poprawkę: code.google.com/p/chromium/issues/detail?id=357696
2
Wielu użytkowników używa ENTERklucza do przesłania formularza, ponieważ prevented defaultkiedy użytkownik przesłał formularz, nic się nie stanie, czyli zły UX. Możesz sprawdzić klucz enter keycodepodczas przesyłania, jednak wrócisz do żebrania ...
David Reinberger
2
Chrome 46 naprawił swoje niewłaściwe zachowanie - żadne obejścia nie są już potrzebne. Zobacz stackoverflow.com/a/33113374/810109
mkurz
1
Nie działa niezawodnie, niektóre przeglądarki nie uruchamiają funkcji „zapamiętaj”, jeśli przesyłasz z Javascript.
JustAMartin
44

Używanie przycisku do logowania:

Jeśli używasz programu type="button"z programem onclickobsługi do logowania się ajax, przeglądarka nie zaproponuje zapisania hasła.

<form id="loginform">
 <input name="username" type="text" />
 <input name="password" type="password" />
 <input name="doLogin"  type="button" value="Login" onclick="login(this.form);" />
</form>

Ponieważ ten formularz nie ma przycisku przesyłania i nie ma pola akcji, przeglądarka nie zaproponuje zapisania hasła.


Korzystanie z przycisku przesyłania do logowania:

Jeśli jednak zmienisz przycisk na type="submit"i obsłużysz przesyłanie, przeglądarka zaproponuje zapisanie hasła.

<form id="loginform" action="login.php" onSubmit="return login(this);">
 <input name="username" type="text" />
 <input name="password" type="password" />
 <input name="doLogin"  type="submit" value="Login" />
</form>

Korzystając z tej metody, przeglądarka powinna zaproponować zapisanie hasła.


Oto JavaScript używany w obu metodach:

function login(f){
    var username = f.username.value;
    var password = f.password.value;

    /* Make your validation and ajax magic here. */

    return false; //or the form will post your data to login.php
}
spetson
źródło
1
@Bigood Ponieważ to działa, podczas gdy zaakceptowana odpowiedź nie (przynajmniej dla mnie). Dzięki, spetson!
Double M
1
U mnie działa również w IE. Mógłbym cię teraz pocałować!
Renra
1
U mnie też pracowało ... :)
Nabeel,
1
To jest właściwe i zarazem najbardziej eleganckie rozwiązanie problemu.
Arash Kazemi
Działa, ponieważ po prostu kopiuję drugi kod i wklejam go na stronę logowania za pomocą elementu inspect, wprowadź nazwę użytkownika / hasło w nowo dodanym polu na tej stronie i naciśnij przycisk logowania, a następnie monit o zapisanie użytkownika / hasła. Następnie odświeżam stronę i voila,
pojawia się
15

Sam się z tym zmagałem i w końcu udało mi się wyśledzić problem i przyczynę jego niepowodzenia.

Wszystko to wynikało z faktu, że mój formularz logowania był dynamicznie wprowadzany do strony (przy użyciu backbone.js). Gdy tylko umieściłem formularz logowania bezpośrednio w pliku index.html, wszystko działało jak urok.

Myślę, że dzieje się tak, ponieważ przeglądarka musi być świadoma, że ​​istnieje formularz logowania, ale ponieważ mój był dynamicznie wprowadzany do strony, nie wiedziała, że ​​kiedykolwiek istniał „prawdziwy” formularz logowania.

TK421
źródło
Począwszy od wersji Chrome 46 można teraz dynamicznie wstrzykiwać formularze i będą one rozpoznawane jako „prawdziwy” formularz logowania, którego dane uwierzytelniające można zapisać. Zobacz stackoverflow.com/a/33113374/810109
mkurz
12

To rozwiązanie zadziałało dla mnie opublikowane przez Erica na forach kodowania


Powodem, dla którego nie wyświetla monitu, jest to, że przeglądarka potrzebuje strony do fizycznego odświeżenia z powrotem na serwer. Mała sztuczka, którą możesz zrobić, to wykonać dwie czynności na formularzu. Pierwsza akcja to po przesłaniu wywołania kodu Ajax. Formularz powinien również wskazywać na ukrytą ramkę iframe.

Kod:

<iframe src="ablankpage.htm" id="temp" name="temp" style="display:none"></iframe>
<form target="temp" onsubmit="yourAjaxCall();">

Sprawdź, czy to powoduje wyświetlenie monitu.

Eric


Opublikowano http://www.codingforums.com/showthread.php?t=123007

Vincent
źródło
5
Uwaga: odkryłem, że Chrome 11 nie oferuje zapisywania danych logowania, jeśli formularz jest przesyłany do siebie . Musisz więc ustawić actionjakąś fikcyjną stronę.
user123444555621
Spowoduje to wysłanie hasła w postaci zwykłego tekstu w adresie URL jako żądanie pobrania. Jeśli metoda zostanie zmieniona na POST, Firefox (16) otworzy poprzednio ukrytą ramkę w nowej karcie. To samo dotyczy Chrome na
Androidzie
Chrome 46 naprawił swoje niewłaściwe zachowanie - żadne iframeobejścia nie są już potrzebne. Zobacz stackoverflow.com/a/33113374/810109
mkurz
10

Istnieje ostateczne rozwiązanie, które zmusza wszystkie przeglądarki (przetestowane: chrome 25, safari 5.1, IE10, Firefox 16) do poproszenia o zapisanie hasła przy użyciu jQuery i żądania ajax :

JS:

$(document).ready(function() {
    $('form').bind('submit', $('form'), function(event) {
        var form = this;

        event.preventDefault();
        event.stopPropagation();

        if (form.submitted) {
            return;
        }

        form.submitted = true;

        $.ajax({
            url: '/login/api/jsonrpc/',
            data: {
                username: $('input[name=username]').val(),
                password: $('input[name=password]').val()
            },
            success: function(response) {
                form.submitted = false;
                form.submit(); //invoke the save password in browser
            }
        });
    });
});

HTML:

<form id="loginform" action="login.php" autocomplete="on">
    <label for="username">Username</label>
    <input name="username" type="text" value="" autocomplete="on" />
    <label for="password">Password</label>
    <input name="password" type="password" value="" autocomplete="on" />
   <input type="submit" name="doLogin" value="Login" />
</form>

Sztuczka polega na zatrzymaniu formularza w celu przesłania go na swój własny sposób (event.stopPropagation ()), zamiast tego wysłać własny kod ($ .ajax ()) iw wywołaniu zwrotnym Ajaxa wyślij formularz ponownie, aby przeglądarka go przechwyciła i wyświetliła prośba o zapisanie hasła. Możesz także dodać obsługę błędów itp.

Mam nadzieję, że komuś pomogło.

Michał Roharik
źródło
7
To faktycznie spowoduje dostęp HTTP do tego, login.php?username=username&password=passwordco eliminuje cały cel zapisywania hasła w pierwszej kolejności
Adaptabi
Wooooooooooooooooooooooooooooooooooooooooooooh! U mnie to zadziałało;) wielkie dzięki!
Hardik Thaker
1
Tak, dodaj event listenerdo formularza i dodaj event.preventDefault()plusevent.stopPropagation()
Densi Tensy
7

Wypróbowałem odpowiedź spetsona, ale to nie zadziałało w przypadku Chrome 18. Udało mi się dodać moduł obsługi obciążenia do iframe i nie przerywać przesyłania (jQuery 1.7):

function getSessions() {
    $.getJSON("sessions", function (data, textStatus) {
        // Do stuff
    }).error(function () { $('#loginForm').fadeIn(); });
}
$('form', '#loginForm').submit(function (e) {
    $('#loginForm').fadeOut();
}); 
$('#loginframe').on('load', getSessions);
getSessions();

HTML:

<div id="loginForm">
    <h3>Please log in</h3>
    <form action="/login" method="post" target="loginframe">
            <label>Username :</label>
            <input type="text" name="login" id="username" />
            <label>Password :</label>
            <input type="password" name="password" id="password"/>
            <br/>
            <button type="submit" id="loginB" name="loginB">Login!</button>
    </form>
</div>
<iframe id="loginframe" name="loginframe"></iframe>

getSessions () wykonuje wywołanie AJAX i wyświetla div loginForm, jeśli się nie powiedzie. (Usługa internetowa zwróci 403, jeśli użytkownik nie jest uwierzytelniony).

Przetestowano również do pracy w FF i IE8.

w00t
źródło
Wypróbowałem tę metodę w Chrome i nie zadziała, chyba że strona akcji ( /loginw twoim przykładzie) zwróci jakiś tekst lub inną widoczną zawartość.
Stephen Bunch
1
Chrome 46 naprawił swoje niewłaściwe zachowanie - żadne iframeobejścia nie są już potrzebne. Zobacz stackoverflow.com/a/33113374/810109
mkurz
4

Przeglądarka może nie być w stanie wykryć, że Twój formularz jest formularzem logowania. Zgodnie z częścią dyskusji w tym poprzednim pytaniu przeglądarka szuka pól formularzy, które wyglądają jak <input type="password">. Czy pole formularza Twojego hasła jest podobne do tego?

Edycja: Myślę, że aby odpowiedzieć na poniższe pytania, Firefox wykrywa hasła form.elements[n].type == "password"(iterując po wszystkich elementach formularza), a następnie wykrywa pole nazwy użytkownika, przeszukując elementy formularza wstecz w poszukiwaniu pola tekstowego bezpośrednio przed polem hasła (więcej informacji tutaj ). Z tego, co wiem, Twój formularz logowania musi być częścią pliku <form>lub Firefox go nie wykryje.

bta
źródło
1
Jest podobnie, tak, dziękuję, przyjmuję to jako oficjalną odpowiedź, ponieważ jest tak blisko, jak to możliwe. Oto coś frustrującego: nie mogę znaleźć (nigdzie w sieci) prostego posta na blogu o treści „Oto reguły, których przeglądarki używają do wykrywania, czy wypełniany formularz jest formularzem logowania, więc mogą zaoferować aby zapisać hasło użytkownika ”. Biorąc pod uwagę, że jest to trochę czarnej magii (i biorąc pod uwagę, że Mozilla jest przynajmniej open source), można by pomyśleć, że ktoś po prostu opublikowałby heurystykę.
Eric
(I podobnie, wydaje się, że nie ma sposobu, abym „wskazał” mój formularz logowania, aby przeglądarka wiedziała, że ​​to formularz logowania. Ponownie, zaskoczony, że nie jest to lepiej udokumentowane w sieci. Myślę, że moje zmiany będzie dotyczyło nazw pól formularza i ogólnej struktury HTML, i mam nadzieję, że [!] to rozwiąże problem.)
Eric
Dobra, nie ma szczęścia. Zadałem nowe pytanie, podchodząc do tego z nieco innej perspektywy: stackoverflow.com/questions/2398763/ ...
Eric
3

Proste podejście na rok 2020

Spowoduje to automatyczne włączenie autouzupełniania i zapisywanie hasła w przeglądarkach.

  • autocomplete="on" (Formularz)
  • autocomplete="username" (dane wejściowe, e-mail / nazwa użytkownika)
  • autocomplete="current-password" (Wprowadź hasło)
<form autocomplete="on">
  <input id="user-text-field" type="email" autocomplete="username"/>
  <input id="password-text-field" type="password" autocomplete="current-password"/>
</form>

Więcej informacji znajdziesz w dokumentacji Apple: Włączanie autouzupełniania hasła w elemencie wejściowym HTML

Danny Wave
źródło
4
FYI wydaje się, że wymaga to przesłania formularza (nie można używać XHR i preventDefault) i nie zadziała, jeśli jest tylko jedno pole hasła (aplikacje typu cyfrowego). Udostępnianie tych wyników każdemu, kto może uznać je za przydatne.
Tomáš Hübelbauer
2

Spędziłem dużo czasu na czytaniu różnych odpowiedzi w tym wątku i dla mnie było to coś nieco innego (związanego, ale innego). W przeglądarce Mobile Safari (urządzenia z systemem iOS), jeśli formularz logowania jest UKRYTY podczas ładowania strony, monit nie pojawi się (po wyświetleniu formularza i przesłaniu go). Możesz przetestować za pomocą następującego kodu, który wyświetla formularz 5 sekund po załadowaniu strony. Usuń JS i wyświetlacz: brak i działa. Nie znalazłem jeszcze rozwiązania tego problemu, właśnie opublikowałem na wypadek, gdyby ktoś inny miał ten sam problem i nie może ustalić przyczyny.

JS:

$(function() {
  setTimeout(function() {
    $('form').fadeIn();
  }, 5000);
});

HTML:

<form method="POST" style="display: none;">
  <input name='email' id='email' type='email' placeholder='email' />
  <input name='password' id='password' type='password' placeholder='password' />
  <button type="submit">LOGIN</button>
</form>
captainclam
źródło
2

Żadna z odpowiedzi nie wyjaśnia już, że możesz użyć interfejsu API historii HTML5, aby poprosić o zapisanie hasła.

Najpierw musisz upewnić się, że masz przynajmniej <form>element z hasłem i adresem e-mail lub polem nazwy użytkownika. Większość przeglądarek obsługuje to automatycznie, o ile używasz właściwych typów danych wejściowych (hasło, adres e-mail lub nazwa użytkownika). Ale dla pewności ustaw poprawnie wartości autouzupełniania dla każdego elementu wejściowego.

Listę wartości autouzupełniania można znaleźć tutaj: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete

Te, potrzebne są: username, emailorazcurrent-password

Masz wtedy dwie możliwości:

  • Jeśli po przesłaniu przejdziesz do innego adresu URL, większość przeglądarek poprosi o zapisanie hasła.
  • Jeśli nie chcesz przekierowywać do innego adresu URL lub nawet ponownie ładować stronę (np. Aplikacja pojedynczej strony). Po prostu zapobiegaj domyślnym zdarzeniom (używając e.preventDefault) w module obsługi przesyłania formularza. Możesz użyć interfejsu API historii HTML5, aby wypchnąć coś z historii, aby wskazać, że „nawigowałeś” w aplikacji jednostronicowej. Przeglądarka wyświetli teraz monit o zapisanie hasła i nazwy użytkownika.
history.pushState({}, "Your new page title");

Możesz także zmienić adres URL strony, ale nie jest to wymagane do wyświetlenia monitu o zapisanie hasła:

history.pushState({}, "Your new page title", "new-url");

Dokumentacja: https://developer.mozilla.org/en-US/docs/Web/API/History/pushState

Ma to dodatkową zaletę polegającą na tym, że możesz uniemożliwić przeglądarce pytanie o zapisanie hasła, jeśli użytkownik wprowadził je niepoprawnie. Pamiętaj, że w niektórych przeglądarkach przeglądarka zawsze zapyta o zapisanie poświadczeń, nawet jeśli wywołasz .preventDefault i nie użyjesz interfejsu API historii.

Jeśli nie chcesz opuszczać i / lub modyfikować historii przeglądarki, możesz zamiast tego użyć replaceState (to również działa).

Simon Backx
źródło
to jest odpowiedź roku 2020! Musiałem użyć, history.pushState({}, null "Your new page title");aby zmienić adres URL bez nawigacji
Delcon
1

Poniższy kod jest testowany na

  • Chrome 39.0.2171.99m: DZIAŁA
  • Android Chrome 39.0.2171.93: DZIAŁA
  • Przeglądarka zapasów Androida (Android 4.4): NIE DZIAŁA
  • Internet Explorer 5+ (emulowany): DZIAŁA
  • Internet Explorer 11.0.9600.17498 / Aktualizacja-Wersja: 11.0.15: DZIAŁA
  • Firefox 35.0: DZIAŁA

JS-Fiddle:
http://jsfiddle.net/ocozggqu/

Kod pocztowy:

// modified post-code from /programming/133925/javascript-post-request-like-a-form-submit
function post(path, params, method)
{
    method = method || "post"; // Set method to post by default if not specified.

    // The rest of this code assumes you are not using a library.
    // It can be made less wordy if you use one.

    var form = document.createElement("form");
    form.id = "dynamicform" + Math.random();
    form.setAttribute("method", method);
    form.setAttribute("action", path);
    form.setAttribute("style", "display: none");
    // Internet Explorer needs this
    form.setAttribute("onsubmit", "window.external.AutoCompleteSaveForm(document.getElementById('" + form.id + "'))");

    for (var key in params)
    {
        if (params.hasOwnProperty(key))
        {
            var hiddenField = document.createElement("input");
            // Internet Explorer needs a "password"-field to show the store-password-dialog
            hiddenField.setAttribute("type", key == "password" ? "password" : "text");
            hiddenField.setAttribute("name", key);
            hiddenField.setAttribute("value", params[key]);

            form.appendChild(hiddenField);
        }
    }

    var submitButton = document.createElement("input");
    submitButton.setAttribute("type", "submit");

    form.appendChild(submitButton);

    document.body.appendChild(form);

    //form.submit(); does not work on Internet Explorer
    submitButton.click(); // "click" on submit-button needed for Internet Explorer
}

Uwagi

  • W przypadku dynamicznych formularzy logowania window.external.AutoCompleteSaveFormwymagane jest wywołanie
  • Internet Explorer potrzebuje pola „hasło”, aby wyświetlić okno dialogowe hasła sklepu
  • Wydaje się, że Internet Explorer wymaga kliknięcia przycisku przesyłania (nawet jeśli jest to fałszywe kliknięcie)

Oto przykładowy kod logowania AJAX:

function login(username, password, remember, redirectUrl)
{
    // "account/login" sets a cookie if successful
    return $.postJSON("account/login", {
        username: username,
        password: password,
        remember: remember,
        returnUrl: redirectUrl
    })
    .done(function ()
    {
        // login succeeded, issue a manual page-redirect to show the store-password-dialog
        post(
            redirectUrl,
            {
                username: username,
                password: password,
                remember: remember,
                returnUrl: redirectUrl
            },
            "post");
    })
    .fail(function ()
    {
        // show error
    });
};

Uwagi

  • „konto / login” ustawia plik cookie, jeśli się powiedzie
  • Wydaje się, że wymagane jest przekierowanie strony („ręcznie” zainicjowane przez kod js). Przetestowałem również post iframe, ale mi się to nie udało.
David Rettenbacher
źródło
1

Znalazłem dość eleganckie rozwiązanie (lub hack, cokolwiek pasuje) dla użytkowników Prototype.JS, będąc jednym z ostatnich, którzy używają Prototype. Proste zastąpienie odpowiednich metod jQuery powinno załatwić sprawę.

Najpierw upewnij się, że istnieje <form>tag i przycisk przesyłania z nazwą klasy, do której można się później odwołać (w tym przypadku faux-submit), który jest zagnieżdżony w elemencie ze stylem ustawionym na display:none, jak pokazano poniżej:

<form id="login_form" action="somewhere.php" method="post">
    <input type="text" name="login" />
    <input type="password" name="password" />
    <div style="display:none">
        <input class="faux-submit" type="submit" value="Submit" />
    </div>
    <button id="submit_button">Login</button>
</form>

Następnie utwórz obserwatora kliknięć dla button, który „prześle” formularz, jak pokazano na ilustracji:

$('submit_button').observe('click', function(event) {
    $('login_form').submit();
});

Następnie utwórz detektor submitzdarzenia i zatrzymaj go. event.stop()zatrzyma wszystkie wysyłane zdarzenia w DOM, chyba że jest opakowane w Event.findElementklasę ukrytego przycisku wejściowego (jak wyżej faux-submit):

document.observe('submit', function(event) {
    if (event.findElement(".faux-submit")) { 
        event.stop();
    }
});

Zostało to przetestowane pod kątem działania w przeglądarkach Firefox 43 i Chrome 50.

mwieczorek
źródło
0

Twoja witryna prawdopodobnie znajduje się już na liście, na której przeglądarka ma nie pytać o zapisywanie hasła. W przeglądarce Firefox, Opcje -> Bezpieczeństwo -> Zapamiętaj hasło dla witryn [pole wyboru] - wyjątki [przycisk]

Dave.Sol
źródło
0

dodaj trochę więcej informacji do odpowiedzi @Michal Roharik.

jeśli twoje wywołanie ajax zwróci zwrotny adres URL, powinieneś użyć jquery do zmiany atrybutu akcji formularza na ten adres przed wywołaniem form.submit

dawny.

$(form).attr('action', ReturnPath);
form.submitted = false;
form.submit(); 
maxisam
źródło
0

Miałem podobny problem, logowanie odbyło się za pomocą Ajax, ale przeglądarki (firefox, chrome, safari i IE 7-10) nie proponowały zapisania hasła, jeśli formularz (#loginForm) został przesłany za pomocą ajax.

Jako ROZWIĄZANIE dodałem ukryte dane wejściowe do przesłania (#loginFormHiddenSubmit) do formularza, który został przesłany przez ajax i po wywołaniu ajax zwróciłoby sukces, wywołałem kliknięcie, aby ukryć wejście przesyłania. Strona wymagała odświeżenia w dowolny sposób. Kliknięcie można wywołać za pomocą:

jQuery('#loginFormHiddenSubmit').click();

Powodem, dla którego dodałem ukryty przycisk przesyłania, jest:

jQuery('#loginForm').submit();

nie zaproponowałby zapisania hasła w IE (chociaż działało w innych przeglądarkach).

Igor
źródło
-1

Nie każda przeglądarka (np. IE 6) ma opcje zapamiętywania danych logowania.

Jedną z rzeczy, które możesz zrobić, to (po pomyślnym zalogowaniu się użytkownika) przechowywać informacje o użytkowniku za pomocą pliku cookie i mieć opcję „Zapamiętaj mnie na tym komputerze”. W ten sposób, gdy użytkownik przyjdzie ponownie (nawet jeśli jest wylogowany), Twoja aplikacja internetowa może pobrać plik cookie i uzyskać informacje o użytkowniku (identyfikator użytkownika + identyfikator sesji) i umożliwić mu kontynuowanie pracy.

Mam nadzieję, że to może być sugestywne. :-)

Buhake Sindi
źródło
Nie przechowywałbym informacji o użytkowniku w pliku cookie, przynajmniej niczego wrażliwego.
Jack Marchetti
Nie chodziło mi o przechowywanie hasła użytkownika. Oczywiście musiałbyś być bardzo kreatywny w tworzeniu, useful garbageaby zidentyfikować informacje o użytkowniku. Nawet SO przechowuje informacje w plikach cookie, aby Cię rozpoznać.
Buhake Sindi
w porządku, ale nadal zaszyfrowałbym tyle, ile możesz.
Jack Marchetti
@JackMarchetti zaszyfrowanie go po stronie klienta byłoby złym (i trochę bezużytecznym) pomysłem. Ponieważ kod potrzebny do zaszyfrowania jest widoczny, każdy może znaleźć plik .js i odszyfrować go. Oznacza to, że nie należy przechowywać danych w pliku cookie
Universal Electricity
-1

Prawda jest taka, że ​​nie możesz zmusić przeglądarki do pytania. Jestem pewien, że przeglądarka ma swój własny algorytm odgadywania, czy wprowadziłeś nazwę użytkownika / hasło, na przykład szukając danych wejściowychtype="password" ale nie możesz ustawić niczego, aby wymusić przeglądarkę.

Możesz, jak sugerują inni, dodać informacje o użytkowniku w pliku cookie. Jeśli to zrobisz, lepiej przynajmniej zaszyfruj je i nie przechowuj ich hasła. Być może przechowuj co najwyżej ich nazwę użytkownika.

Jack Marchetti
źródło
A ty sugerujesz ciasteczka?
Buhake Sindi
mówię jednak, aby zaszyfrować wszystko, co w nich przechowujesz.
Jack Marchetti
1
Ciasteczka? To zły pomysł na czekanie
NightSkyCode
-1

Możesz dołączyć okno dialogowe do formularza, więc wszystkie te dane wejściowe są w formularzu. Inną rzeczą jest utworzenie pola tekstowego hasła zaraz po polu tekstowym nazwy użytkownika.

Kait
źródło
-1

U mnie działa to znacznie lepiej, ponieważ jest w 100% Ajaxowane, a przeglądarka wykrywa logowanie.

<form id="loginform" action="javascript:login(this);" >
 <label for="username">Username</label>
 <input name="username" type="text" value="" required="required" />
 <label for="password">Password</label>
 <input name="password" type="password" value="" required="required" />
 <a href="#" onclick="document.getElementById("loginform").submit();"  >Login</a>
</form>
ShelatoBaboon
źródło
-2

Użycie pliku cookie byłoby prawdopodobnie najlepszym sposobem, aby to zrobić.

Możesz mieć pole wyboru „Pamiętasz mnie?” i niech formularz utworzy plik cookie do przechowywania // danych logowania // użytkownika. EDYCJA: Informacje o sesji użytkownika

Aby utworzyć plik cookie, musisz przetworzyć formularz logowania w PHP.

Mandrig
źródło