PHP Header Location - Prevent Chrome Prompting Save Password - php

Please note the code snippet is just there as an example, there is nothing wrong with the way it works - my question is relating to Chrome's default behaviour of prompting the user to remember their sign-in details, which I want to happen when the password is correct, but not to happen when the password is wrong.
I have been looking around, and come across other articles, but they aren't specifically for my issue and cannot be related to it.
The backend code handling a form submission essentially goes like this (cut down because the code is not actually the problem here)
if(password_verify($password,$dbpassword)){
//Task: Please DO prompt me here chrome, this is correct
header('Location: /account');
exit();
}
setcookie('error','Your password is incorrect',time()+5,'/','',true);
//Task: Please DON'T prompt me here chrome, this is the wrong password!
header('Location: /log-in');
exit();
The log in page then reads the set cookie and displays the error, prompting the user to make another attempt.
The problem is not related to my code. The code is fine.
Chrome takes the header('Location:') to mean that login was successful, thus prompting the user to save these details (annoying). I was wondering if anyone knows how to basically tell the browser it was a failed attempt?
Untested, but I imagine the same prompt would occur on other browsers that offer the same user/password storage... So an all-browser solution would be amazing if anyone has... I'm sure it is a simple one liner to fix this, but I've been researching for over an hour with no success
My code so far performs fine like this:
Cookie set with error message ✓
Header redirect back to login page ✓
Cookie read & error message displayed ✓
Cookie removed ✓
Google shouldn't ask to remember because it was wrong ❌

You could try telling the browser that the user is not authenticated yet, by setting the status code 401 (Unauthorized):
http_response_code(401)
However, you should be aware that the Location header should only be used with redirect status codes (3xx). Therefore, to prevent unexpected behavior consider either directly rendering the login page, or use a different method of redirection. See also this answer.

Related

Why after posting from Curl does the page only display correctly in Incognito mode?

This is a really interesting problem related to cookies, I believe.
My index.php has a form, and it posts to post.php. post.php then manipulates the data and uses curl to then post it to webinarjam.net, a 3rd-party service not controlled by me.
webinarjam.net then displays a short success message that basically just contains a unique URL. The unique URL is to a thank-you page (hosted by webinarjam.net).
This all works beautifully. But here is the problem:
Clicking the URL only works in Incognito mode (?!) (i.e. clearing browser cookies first). Otherwise, webinarjam.net simply displays "Internal Server Error".
I have no idea why the presence of cookies would PREVENT a page from displaying.
How could I change my post.php such that the unique thank-you page URL will display correctly even without using Incognito mode of the browser?
Figuring this out would enable me to simply automatically redirect the user to that thank-you page URL upon form submission. (Currently, redirecting would just bring her to a page that says "Internal Server Error".)
P.S. In case this helps, I've also used the Advanced Rest Client extension within Chrome to try to post the same query data to webinarjam.net; the resulting unique thank-you page URL is then able to be displayed without using Incognito mode. So... what I need help figuring out is: what difference exists between the way my post.php and the Advanced Rest Client extension are posting to webinarjam.net?
I finally noticed that it wasn't just Incognito mode that worked; it was any browser OTHER than my main one.
And I eventually figured out that it was because my main browser was logged into the EverWebinar site.
I guess EverWebinar barfs (fails) whenever a logged-in admin of a webinar submits a form to sign up for that webinar (even using a different email address).
It seems like upon form submission, the system notices the session/cookies of the logged-in admin, and it says "no matter what, someone who owns this webinar shouldn't be signing up for it."

Problems logging into Magento Admin

Occasionally I run into a problem logging into the Magento admin panel. The username and password I enter is correct and the url in the browser window tells me that I have logged in correctly (ie: I see domain.com/index.php/admin/areallylongstring), however the login window is displayed again. No error message telling me that the log in details are incorrect is displayed, I am just routed back to the log in window. Has anyone come across this before and can anyone please suggest a solution?
Thanks!
Try start a private browser session and see if you can login, if so clear your cookies for the website and you should be able to login.
I occasionally get this problem, next time I get it I will dig into the code with my debugger to see what is actually going on.
This problem arises due to multiple reasons and the cheapest solution for this will be comment out the following lines in one of core files of magento.
FILE :- app/code/core/Mage/Core/Model/Session/Abstract/Varien.php.
// set session cookie params
session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()//,
//dependes which versin of mage you are using, you may comment these as well
//$this->getCookie()->getDomain(),
//$this->getCookie()->isSecure(),
//$this->getCookie()->getHttponly()
);
Find out above code in that file and then comment out those three cookies as shown above.
But as I said it is the cheapest and easiest solution that you can go with. For more information, checkout this link

Ask for HTTP authentication only when user is trying to authenticate

What I think of is detecting authentication attempt and logging user in using PHP and standart HTTP credentials without bugging him with popup, when he does not try to login. That may sound easy, but we must keep in mind, that browsers check whether site is requesting authentication, and when it does not, they are bugging user with warning and they also send no data.
Is there any bypass? Any trick?
QUESTION SUMMARY:
I want url http://example.com/site to work wihout any promts and popups. User will see the site as anonymous.
I want url http://user:password#example.com/site to work without any popups too. User will see the site as user
To answer your question: no there is no way around it. The browser will not send the authentication information if it has not been requested by the website, and as you have discovered, it will also show an annoying security warning to the user. You should bite the bullet and use a GET param.

How to logout when using .htaccess (and .htpasswd) authentication? [duplicate]

This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
HTTP authentication logout via PHP
Hi
I have a some functionality on my website protected using .htaccess and .htpasswd.
When users attempt to access this, they get prompt to enter details. They enter their details and get in and can see stuff etc. All works fine.
My question is how do I create a logout functionality for this type of authentication. I know that they can close the browser window to "Logout". But this is not ideal. What would you suggest to me?
Thanks.
Tested on firefox and chrome. What you can do is send the user to http://logout:logout#example.com. This will replace their current username/password with logout/logout (it could be any invalid user/pass combination) and since they now have the wrong username/password, they will have to login again to access the site.
On opera this does not work, because you can have several usernames/passwords at the same time. It didn't work on IE either, because IE does not appear to support http://username:password#example.com URLs.
Browsers usually don't support this, see How do I log out?
Since browsers first started
implementing basic authentication,
website administrators have wanted to
know how to let the user log out.
Since the browser caches the username
and password with the authentication
realm, as described earlier in this
tutorial, this is not a function of
the server configuration, but is a
question of getting the browser to
forget the credential information, so
that the next time the resource is
requested, the username and password
must be supplied again. There are
numerous situations in which this is
desirable, such as when using a
browser in a public location, and not
wishing to leave the browser logged
in, so that the next person can get
into your bank account.
However, although this is perhaps the
most frequently asked question about
basic authentication, thus far none of
the major browser manufacturers have
seen this as being a desirable feature
to put into their products.
Consequently, the answer to this
question is, you can't. Sorry.
There are browser extensions that allow you to clear the HTTP authentication for a site.
For Firefox the WebDeveloper extension (which is one of my favourtie extensions anyway) offers this feature.
The menu for this is Miscellaneous/Clear Private Data/HTTP Authentication.
I ran into this issue several years ago. It is incredibly frustrating to discover there is a problem everyone is having and no one seems to want to solve in a general way.
As noted in Inadequate Logout functionality in HTTP Authentication I think the answer is to change the RFC to allow timeouts and support a log out button. The author's additional suggestion that the server be able to send a "log out" header would actually eliminate the need for any client user agent support since websites could simply include a link on a web page to a URL that returns the necessary response code and/or header to invalidate the current session.
It IS kind of possible to log out. You should implement logout page, which will return HTTP 401, until the user enter BAD login information, and then redirect somewhere else. Browser remembers the latest login information accepted, and therefore overrides correct login.
But this is kinda unusable, cos it needs user's cooperation.

Disabling Browser's "save password" feature on auth failure

I'm looking for a server-side implementation to disable a browser from saving invalid login credentials.
For example, user "foo" logs in with password "bar". Browser asks foo if he wants to save the password. However, foo's password is actually "baz" and therefor would be saving the incorrect password.
I've tried manipulating the HTTP codes, such as sending HTTP/1.1 401, but without success.
This is NOT solved by adding "autocomplete" to the form, as this prevents any saving (even valid).
Server backend is PHP.
I don't think you can - that's a browser behaviour.
Closest you could come, is write a Firefox plugin that maybe could intercept the request. But I'm not even sure about that, and it only applies to Firefox. You'd need to look at Chrome, IE, Safari and any other browser you're interested in.
It seems that you are attempting to fix something that is not your job and which you have no control over. As Joel Mueller has stated, Firefox addressed this issue by changing their modal save password dialog to a status bar which allows you to confirm that the password was correct before you save it. If you are experiencing this issue in other browsers then you should submit it as a feature request to the developers of that browser so that the issue can be fixed at their end, which is the only place it needs to be addressed.
You can't have it dismiss that box if the authentication fails. However, you could have it prevent subsequent fillings of that field on the "Password Failed" page after the initial attempt. Once the page has loaded, manipulate the DOM to remove the text value from the password field if the last login attempt was invalid. It would still display the password on subsequent "fresh" visits to the site, but hopefully the correct password will have been saved by then.

Categories