In Firefox (and Microsoft Edge) I'm seeing something that I assume is impossible.
I log into my website and get a PHPSESSID of 6a47272fa6d7b4de2292966bf77ddb51
I close Firefox
I reopen Firefox and I can see in the options that my website has no cookies set (as I expect)
I visit website again without Logging in and my session is still active (I'm still logged in) but my PHPSESSID is now 7d4117307c86faa7ea9dc7afe6b4b720
I'm not looking for a fix. I just want to know how this behavior is possible. How could PHP know which Session to resume if Firefox is not sending a PHPSESSID after the browser closes?
I don't see this happen in Chrome (the user needs to log in again as you would expect), but I do see it happen in Microsoft Edge.
After paying very close attention to my network tab in Firefox. I discovered that neither PHP nor Firefox remembered that I was logged in.
Rather my website was redirecting me to Google Sign In and Google Sign In has non session cookies that remembered I was logged in. So it quickly redirected me back to my website creating a new logged in session for the same user.
It was happening so fast it I could not tell that I was being redirected to Google until I watched the network tab.
Thanks Axalix for the suggestion.
Related
Chrome is not adhering to my Laravel Session setting 'expire_on_close' => false. When I close down Chrome, reopen the browser and navigate back to my url I am still logged in.
I'm aware that this post describes that Chrome will not fix/address this. BUT has anoyone come up with a solution or workaround that will force cookies to expire when the Chrome browser closes? Maybe a php.ini setting?
The only solution I can think of having my Laravel web app send ajax 'keep alive' pings every 5 minutes back to the server and record those in a mysql table against a cookie's uid. So when someone closes down Chrome and reopens it (after > 5mins) I will know their session has expired. But even this will fail for the usecase 'someone is working on a public computer, closes Chrome, another person opens chrome within < 5 mins and navigates to our website and is logged in as that first user'.
I know that websites store cookies to validate users on different websites of the same domain , but when I tried to replicate it on my gmail account it didn't work.
I am using editthiscookie to export and then import cookies in the incognito browser .
Theoretically the browser should log me into my gmail account but it doesn't happen.
I had read it somewhere that the servers on the backend check the ip , but that shouldn't be the problem as it's my own PC both the time.
So what's wrong going on ??
Note:
1. EditThisCookie shows all the cookies including 'HttpOnly' and 'Secure'
2. I haven't logged off from my account on the other browser session i.e. the normal session (in case anyone might think of cookie expiration ).
Incognito mode operates as a clean slate, it does not have access to cookies from normal mode.
On Firefox and Internet Explorer, when you close the browser while being logged into a website (e.g. Yahoo mail) it automatically logs you out.
However on Google Chrome (with Sync enabled), the $_SESSION seems to be stored even when the browser is closed. Its easy to reproduce,
a) Log into yahoo mail, on Chrome (with sync enabled)
b) Close your browser without logging out of yahoo mail
c) Open a new browser
d) Got mail.yahoo.com. This will allow you into yahoo mail without requiring you to log in.
I am using yahoo mail as a example because it'll be easier to relate to. I have same exact issue with my website login system. I am worried about my users logging into their accounts from a public account and closing their Chrome browsers not realizing that the next person that comes along and open the browser window might be able to log into their account.
Has anybody come across this. Does anybody know how to fix this i.e. ensure that the session is closed and user logged out when a Chrome Browser is closed?
We have about 100 users accessing our website daily. A majority of them have no issues logging in. However, once a month we get a call or email ticket with complaints that users just see the login page refresh, with no error messages or anything.
All error messages are sent through the PHP Session cookie, and of course everything after logging in is based off of that session. The only reason I could think that the page just refreshes HAS to be because they are blocking that session cookie on their local machine...
Now most often the user is on internet explorer, but occationally it even happens with Chrome or Firefox. I've even had a user (on OSX) who tried Safari, Chrome, FF - and it would NEVER let them log in, the page would just basically refresh. I had the user add the website as trusted, and still no luck.
It's the worst because I cannot reproduce it from any network or from any browser/computer, ever.
Does anyone know what could be causing something like this? The site IS forcing SSL (the HTACCESS file redirects to HTTPS). The site IS forcing the session cookie as HTTP-Only and the Secure flag is also set to TRUE (and these 2 are somewhat recent changes).
I'm unsure what other settings on the server or the PHP instance would be causing something like this, or if it's soley a client-side issue (which it appears to be). And if it's client side, I'd like to learn the issue and possible solutions to it.
To preempt everyone, no - I cannot share the website URL for debugging because the client would not appreciate that, unfortunately. Thanks for any help, I'll be happy to answer any question that I can!
Do you have more than one web server behind a load balancer? And are the PHP sessions stored locally on each web server? If so it is the load balancer's job to make sure a user keeps going back to the same server on repeated accesses. If something goes wrong, they could get sent to a server where they do not have a session. It could be some intermittent glitch sending users to the wrong server.
Just guessing, because as others noted, we don't really have enough info.
Does your session cookie have a valid name? I've run into this problem in the past where some browsers don't accept a session cookie if it has an invalid name, but other browsers do accept them;
http://php.net/manual/en/function.session-name.php
Let a user using Mozilla browser , On three tabs he login to his yahoo account ,gmail and hotmail.
Now if we Clear Recent History , all three session will be cleared.
But at the same time if there is another session in any another browser it will not be cleared.
So What i am trying to ask here is , the cookies and session related details ,browser cache will be in the local computer and it will be cleared on clearing history.
But is it browser specific?
The cookie and all will have any browser specific id , how it will differentiate that now clear the IE history or clear chrome history.
You can in fact use two different accounts on two different browsers at the same time. The browser history/cookies etc are specific to the browser in question.
There isn't a "standard" where browser save their settings, each do it as they file. MSIE might use the Windows Registry while Firefox might use a local database file.
For the server to keep track of a client session a session id is sent to the client. Which the client uses in each request to the server.
On the local computer each browser has it's own way of saving the cookie files. So when you clear the cookies in Firefox, then the cookies saved by Firefox will be deleted. Same thing with Chrome, IE, Safari etc.
They could even be using a own way of serializing the cookies for all that I know.