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?
Related
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.
When user enter my site they receive a dialogue box proposing to install my wonderful app. When the user presses the accept button, the play market page with my app pops up.
This dialog box appears only if user browses from phone.
However, this dialog will popup even if user has my app already. Thus, I am interested in a way to inform site about presence/absence of an app on the phone. If app already installed on a phone, dialog should not appear.
phone w/o app -> browse site -> get dialoge box
phone with app -> browse site -> normal browsing
Simple and useless solution which comes in mind:
If link is opened from my app, it is extended with some action to identify that app is installed.
It is useless, because app is all-sufficient, so opening site will not give any benefit.
A bit more advanced idea was proposed by msh: Give user an option which app will open a link. If link is opened with my app as above.
Is there a better way to do this ?
Yes, Mobile Browsers (on their own) cannot communicate the application installed status to web. But still if you are desperate to implement this behavior, I have got a "WILD" solution for you.
This Solution is divided in two parts: Client Side (Android Device) / Server Side (Web)
Client Side (on Android Device):
In your application you'll need to implement a BroadcastReciever that will be continuously listening to the Network State changes. Whenever a broadcast is received for new network connection available (e.g. when the user turns on the Mobile Data), your app should read the acquired IP address and communicate it to your web-server (using HttpURLConnection).
Communicating the IP address will inform your web-server that the device browsing your website from this IP address has got your application installed.
Server Side (on Web Server):
Your web-server will keep a track of all the IP addresses reported by all the devices on which your application is installed(off-course in a database). To avoid redundant entries you can decide a expiry/validation time for each IP address record received.
Now when your server receives a web request, it will match the IP of the requesting client with all the IP's that were saved in its database. If it finds a matching IP, it means that the web request has come from a device on which your application is already installed. Otherwise you can direct the user to your app's play store link.
Limitation of proposed Solution: This solution will work with 100% accuracy only in the case when the user is using Mobile Data (2g / 3g / etc) to connect to internet. Since using Mobile Data, everytime the device will be issued a unique IP address by the service provider.
This wont work perfectly for wi-fi connections. While browsing using a wi-fi, all the devices that are connected to same wi-fi spot are allocated the same IP address. So there may be a situation where two mobile phones are using internet from same wi-fi spot, out of which one phone has your application installed and the other phone does not. This will confuse the server.
** This solution may not be highly recommended, but could be used with some minor fixes if you don't get any other solutions ;)
It is not possible of course, browser doesn't leak phone configuration and installed apps to random websites (I hope, or somebody has to fix it ASAP)
You can probably make your app react to the VIEW Intent with certain URL then redirect to that URL on your site, but that will make Android ask the user whether they want to open this URL with your app or the browser, so it is not transparent
You could have two seperate urls like: www.yousite.com and www.app.yoursite.com. This way at least the users are free of the popup from the app.
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
I use Htdigest authentication with lighttpd. When the user first logs in to the website, a standard username/password dialogue box is presented. If correct username and password is entered, user can login, otherwise lighttpd shows an Authentication failure page.
So far so good!
The problem is when the user wants to logout, the browser doesn't forget the username and password. In other words as long as the browser is open, user can return to the same site without being asked to authenticate. One solution can be to close the browser so that it forgets the authentications But I don't want to force the user to close their browser everytime they want to log out.
Is there a way using JavaScript or server side code (ie. PHP, Python or Lua) to let the browser forget the htdigest authentication?
PS. We use Lua 5.1 on the server side which is not as powerful as PHP but it runs as FASTCGI in Lighttpd 1.4 on Linux 2.6.
It can be done, but is tricky. There is no default way to do this. Conclusion drawn from various sources:
You have to trick the browser in forgetting the user/password combo. This can be achieved by letting the logout page send a 401 Not Authorized response header. Unfortunately the details vary per browser.
I'm trying to continue building up an email tracker - successfully done GMail Yahoo and several web clients. Now I'm stuck with AOL webmail.
Trying the usual methods of using HTTP_REFERER, HTTP_USER_AGENT and REMOTE_ADDR have all yeilded in showing my details and nothing for the referer.
Upon further inspection, it seems that AOL's Webmail somehow is loading the messages into an iFrame where the content is local.
Is there anyway to get the referer and still show the image - I did think of using javascript's parent method, though this would stop the tracker pixel/web bug from appearing. Besides, it wouldn't load in web clients.
I would appreciate any help. I also would like to know if AOL's Desktop Email had a User Agent string - I haven't looked on Google just yet (though finding User Agent's for email clients is difficult - still hunting for Outlook versions prior to 2007).