2

In the scenario of a regular email/password form, where submitted form makes a POST request to the server to validate client credentials.

How to tell the browser if the authentication was successful or not? ie, how to tell the browser whether to remember the email/password combination or not.

This is the form layout:

<form action="" method="post">
    <fieldset>
        <legend>Sign in</legend>

        <label>
            <span>Email</span>
            <input type="text" name="ay[email]">
        </label>

        <label>
            <span>Password</span>
            <input type="password" name="ay[password]">
        </label>
        <input type="submit" value="Sign in">
    </fieldset>
</form>

There is no JavaScript involved in the process.

Gajus
  • 69,002
  • 70
  • 275
  • 438

3 Answers3

0

If you are doing a form submit action to authenticate the session, the browser will ask the user whether they want to remember the username/password combination. Also the browser will check for any exception cases added to the browser by the user like never remember, never remember for the site etc.

Arun P Johny
  • 384,651
  • 66
  • 527
  • 531
  • I don't ask how to establish session. I am asking how to trigger browser mechanism that asks user whether to remember/ overwrite the existing email/ password combination. – Gajus Feb 07 '13 at 17:34
  • Sorry, Are you doing an form submit? Looks like there are quite few questions regarding this. http://stackoverflow.com/questions/5430129/how-to-make-chrome-remember-password-for-an-ajax-form http://stackoverflow.com/questions/4119385/why-doesnt-chrome-recognize-this-login-form http://stackoverflow.com/questions/2620927/how-to-trigger-saved-password-autofill-in-browsers – Arun P Johny Feb 07 '13 at 17:37
  • All of the questions that you've referred to discuss the case where form is submitted using JavaScript request. – Gajus Feb 07 '13 at 17:44
  • In your case how are you sending request to the server – Arun P Johny Feb 07 '13 at 17:50
  • It should work, Can you check whether the site is added to the do not remember list – Arun P Johny Feb 07 '13 at 18:00
  • It doesn't and no, the browser is not added to the "do not remember" list. The thing is, that if user is redirected to another page that does not contain the form, then the browser triggers the request thing. However, the page that user is redirected to has exactly the same form. I am guessing it is therefore that the user is not asked for credentials. I am only wondering if there is anything that I can do without messing with the DOM. – Gajus Feb 07 '13 at 18:10
0

Q:authentication was successful or not A: set cookies. and second you cant force browser to remember combination you can just set cookies in which you can use time how much need like Google use many years :)

Gurjinder Singh
  • 120
  • 5
  • I don't want to force the browser to remember user credentials, I am barely trying to trigger the toolbar asking user if he wants the browser to remember his credentials. – Gajus Feb 07 '13 at 18:07
  • its not possible because its depends on user setting if it will open to us then it will be a security risk there – Gurjinder Singh Feb 07 '13 at 18:12
0

Most attempts to fix this problem involve hacking around browser heuristics for logins, which is error-prone and easily becomes outdated. So, we should see what browsers themselves recommend for working with their authentication features.

Sadly there’s no cross-browser standard yet (the upcoming isLoggedIn API looks like it’ll be that), but in the meantime we have some advice from the Chromium Wiki’s Create Amazing Password Forms:

Make sure form submission is clear

Password managers need some indication that a form has been submitted. Try to make sure your web page does one of the following on form submission:

  • Performs a navigation to another page.
  • Emulates a navigation with History.pushState or History.replaceState, and removes the password form completely.

In addition, if you perform an asynchronous request with XMLHttpRequest or fetch, make sure that the success status is correctly set in the response headers.

Follow existing conventions

Being different just for the sake of it is not worth it. This will lead to a poor user experience all round. This means, for example, not navigating to a separate web page if a login failed: this is unexpected, and disorienting to both the user and the password manager.

From this, we can infer the following signals to at least one browser that a login failed:

  • The HTTP response’s status code is an error.

  • The form submission does not navigate to another page (login pages may reload if you failed to log in successfully, but crucially they stay at the same URL).

  • The form does not submit at all when the user tries — either because of HTML form validation blocking the submission, or JS checking if the server accepted the login and calling .preventDefault on the form submission event. (The former is unsuitable for wrong credentials; only basic checks such as required and minlength.)

Sadly, I can confirm that some of these techniques don’t work cross-browser: for example, Firefox optimistically shows its Save Credentials menu before the HTTP response to the form submission even arrives. Mozilla has a bug open about this exact problem, but it appears doing the right thing to keep compatibility with existing sites is just as tricky for them.

More distressingly, from a duplicate of that bug:

Matthew N. [:MattN] • 2 years ago

We should double-check how other browsers handle this nowadays. I think others started copying us on this now.

Tigt
  • 1,330
  • 2
  • 19
  • 40