In my Zend Application, I am trying to make our authenticated users be automatically logged out when they close their browser.
For that I'd write following code:
ini_set('session.cookie_lifetime', 0);
And its working fine on browsers like Chrome, Safari, IE7 and IE8, but in case of firefox, users still remain logged on when they close their browser.
Does anyone know what is causing problem?
Thanks In advance...
A value of 0 indicates "session cookie" - i.e. one that the browser should destroy when the "session" is over and the browser is closed.
However:
Different browsers have different interpretations of exactly what a "session" is - some will destroy these cookies when your close the tab, some when you close the window, some won't destroy the cookies until all instances of the browser have been closed - all tabs in all windows.
Since cookies are stored and transmitted by the client, they are completely the responsibility of the client. You should not rely on cookies alone to control whether a user has a valid login because they are ridiculously easy to spoof, you should implement some kind of activity timeout as well.
Make sure you have actually ended your Firefox session when testing - close all open tabs and windows, and watch the process list to ensure there are no instances left. If you are still having a problem, you are probably looking at some kind of bug in Firefox (or maybe you've made some strange change in about:config) and you need to ask for Firefox-specific help - SuperUser.com would be a better place for that. One thing you can be fairly sure of is that if it works everywhere else, it's not a problem with your PHP.
Related
Today is THE day I didn't find the answer I'm looking on the web (it never happened before). The fact is, I didn't find how to question google.
My problem : I run a PHP script "X" on my server (who need several hours) and I can't go to another page "Y" on the same server with Firefox.
But if I load page "Y" with Chrome, it works. How can I setup my server to launch several scripts (on the same server) with the same browser ?
This happens when you use sessions: When you run a script that uses a session, the session is locked. As the same browser is trying to access the same session, it will not work; the browser will have to wait until the session by the other tab / browser window is closed.
Possible solutions are for example:
Close the session as soon as possible / when you don't need it any more;
Don't use sessions for the long-running scripts;
Use different browsers / incognito mode so that the session information is not shared.
You're right.
I had to release the session lock in the scripts with "session_write_close() "and now it work.
Thanks for helping!
I have a PHP program that uses session variables to pass data over several PHP scripts. When I test it on my normal computer it flows just fine, and the session data holds through where expected, gets maintained on page refreshes, etc.
The strange thing I'm encountering is that on a secondary computer, the session is wildly inconsistent. I'll arrive at a page and it acts as if none of the session variables had been set. What's even stranger is, if I try reloading the page, sometimes the variables will actually load (and if I refresh again, they disappear again).
From what I can tell the problem doesn't seem to be browser-specific (I've tested on Chrome, Firefox and IE on both computers), but rather computer-specific, which seems really strange to me. I asked two other people to try it out, and discovered the exact same issue -- for one person the program runs just fine, but for the other person the session variables load inconsistently.
Any thoughts? I'm not doing anything fancy with the session, I just have the session_start() calls at the beginning of the scripts, post data via forms, and access/store via $_SESSION.
Edit: Some additional details --- in firebug, on the computer that isn't affected I'm seeing 3 cookies, which I guess I should be expecting (I'm admittedly not much experienced in session management and cookies). On the computer that is affected though, I'm not seeing any cookies at all in Firebug, even when the page does randomly load properly.
Also for clarification, I do expect the session data to be distinct for each computer, I'm not expecting data from one computer's session to be available on another computer's session.
Edit 2: I checked the cookies in firebug again, and it does seem like the 3 cookies are showing up on the affected computers (maybe it wasn't loading properly earlier today). I've done a var_dump of the $_SESSION variable on the pages that aren't displaying the data correctly, and sure enough all the information is there. It's just, for some reason it only sometimes loads in the HTML section below. I'll keep digging.
After a ton of digging around and testing, I finally figured it out, and the answer was surprisingly obscure and yet under my nose at the same time. My company uses VPN to tunnel remote desktops to our work servers. Although the pages I had set up on the work servers were accessible and worked properly via the browser (which is what threw me off), the session cookies weren't passing properly to the affected computers because those computers didn't have the site's IP address mapped to the work domain in their Windows hosts files. Once I mapped the IP address to the site domain, everything worked perfectly like my primary computer. Thanks to everyone who gave the issue some thought!
I have a website (www.mysite.com) with a private backend (www.mysite.com/admin)
When I'm adding content to the site in the admin area and switch back and forth between tabs in the same browser window to see the content I'm editing, my session is getting expired/ended/terminated and I'm redirected to the login page again.
I have used the same code many-many times before on many web sites (this is a CMS I've made by myself) without a problem. The only thing I can think of is that this particular website is hosted on a different web server and maybe it's a matter of a php.ini setting or server configuration. Any ideas?
Have you checked your browser cookies? (the actual client-side ones?) or tried your luck with another browser? It may sound a bit strange, but I had a similar problem and in my case it had to do with these cookies. It may be worth figuring out because of your odd problem. As you might know the phpsession value is stored in that cookie and so is the domain.
Good luck!
This could be a result of several things, but my first instinct is to check and see if the session cookies are expiring very quickly. Sometimes server headers may change expiry values. You may also want to check the cache headers being sent by the server. If you are using asynchronous functionality on the admin area, it is possible that somehow the server is changing the expiry of cached files which could affect this.
I am eager to see the solution to this.
A few things to check:
session.cookie_lifetime setting - Possibly too short; 0 is the default and keeps the cookie until the browser closes
session.cookie_path setting - You'll want this to be '/'
Session storage - Make sure the session data is being written.
Explicitly call session_close() if your sessions are stored in a database. That will ensure they are written before your objects and database resources are destroyed.
If serving through any sort of proxy, check for any changed header information.
If caching, check your dynamic pages (requiring sessions) are being served by your web app and not the cache.
If testing with your local /etc/hosts, first clear your cookies so the new server's cookies are fresh and don't conflict.
Confirm in your browser that the cookie is in fact being stored. Maybe it's not actually coming back in the header.
I had a problem like this before. I was just uploaded a site from my localhost to a remote host, and I haven't change the nameservers yet. The hosting company provided me with a temporary url to be able to see my website. The problem was that this url was like this https://server_name.grserver.gr:8443/sitepreview/http/my_site.gr/, the result was that any browser didn't accepted the session cookie because I didn't had an SSL sertificate so the sessions didn't worked at all. I browsed a little the plesk panel and I found an other temporary url that was using http protocol, with this everything was ok. So if you are using https try to check if you have a problem with your ssl sertificate (for expample if it has expired). You said the problem occurs when you login in the admin page, do you switch then to https?
There could be several reasons. As there is no code or no details about the site provided , I am assuming that the problem might be if you are using htpasswd. If u are using htaccess authentication, then your session gets destroyed.
From experience, I can tell you a few things.
First, sessions need to be started with
session_start();
At the top of every page you want to use sessions.
Next, to save session data, you need to call another function to tell php that you are saving stored data. That function is
Session_write_close();
That function is needed on the bottom of the page when you are finished writing data to a session and want it saved for later use.
With those two combined, that should allow you to properly write to a session, save the data you entered into it, and access it later on your site.
Good luck.
The problem has been found after reading this topic.
I had a custom php.ini in the root dir and apparently it was interfering with the $_SESSION. I don't know why but after deleting it everything works fine.
At first it seemed as if the problem was opening pages located in different sub-folders in several browser tabs however it narrows down to a sub-folders issue and the fact that the $_SESSION wasn't accessible across them.
I'd like to thank everyone that put some time into trying to help me figure this out.
First off, I'm not sure whether this is a problem in Opera 12.01 or not, but the problem only occurs in Opera. I've tested in FF14, Chrome 21, Safari 5 (Windows) and Safari Mac and Webkit browsers on Android and iPhone.
My application runs on the trigger.io forge platform and uses a proxy to route requests from the web application to the service. The proxy simply forwards the requests and cookies along and this works as expected in most of the browsers.
After inspecting the request in dragonfly, I noticed that the server sends the proper headers in the response, but Opera seems to be ignoring setting the values. I'm wondering whether this is due to some misconfigured path value for the cookie. I've attached screenshots of 2 requests in Firefox and Opera.
As you can see in the screens, FF sees the cookie headers and sets them appropriately, but Opera does not.
Firefox Request
Opera request 1 Screen
Opera Request 2 Screen
I haven't included the code from the proxy that does the request forwarding, so please let me know if you need that to gain some insight. On the service end, I'm running PHP and Codeigniter. Please let me know if I need to add any more info here on my environment, thanks.
UPDATE : This issue occurs even in my production environment which does not use a custom TLD. Other sites that use cookies work fine and cookies are enabled.
Double quotes are formally illegal in a cookie value. If you escape them as %22 it will work.
Have you checked if this is an issue with cookie domains ? I'm assuming you're using Javascript to set/read the cookies ? In any case there are 4 cookie domain issues that you might want to check (I know I've had these issue with an old FF version):
1 - check for illegal cookie characters: allowed cookie characters you might not be allowed to use '-' or '=' in the cookie name, and you shouldn't use non-ASCII characters in cookies at all. A base64 encode might deal with this.
2 - check that the domain on which you set your cookie (via javascript code or any other way) is identical to the domain on which the code is executed.
3 - check that the cookie domain is not localhost; see if you can test setting the cookie from a remote domain
4 - if you're using JS to set your cookies, try testing if you can set the cookie with a CGI in your browser to make sure it's not a browser issue. If it works which it should, see if you can read the cookie using JS (as opposed to setting it).
Let me know how this goes in the comments, I've dealt with similar issues a number of times and depending on what you get with these checks, I'm pretty sure I can help you fix the issue.
Have you checked the "leading dot" form of a cookie domain in setcookie. I've been using leading dots for years and only recently noticed my app wont set cookies on opera (chromium et al?) due to the leading dot which is part of a deprecated RFC. In opera, it's not that the leading dot gets ignored but the very setting of the cookie itself. I've removed the leading dot and its working now.
Looking at those Opera screenshots, they seem to be AJAX / XHR requests which are processed within the same second. Is it possible that Javascript is triggering both of those requests "simultaneously", so the response from the "first" is not arriving before the request for the "second" is constructed - and therefore the cookies have not yet been set?
I'm not familiar with the technologies/toolkits you're using, so don't know if these are stock code or part of your custom application.
I have a PHP site that makes use of sessions, which obviously are not supposed to be able to persist if you close your browser. I've done this scores of times, no issues.
And no issue currently - except within Microsoft's new Edge browser. If the user logs in, works in the site, closes Edge's window in the top right corner, and then re-opens the page and pastes the web address (or bookmarked it before), all their variables from the previous visit are still present. That's a problem, as each visit the viewer will likely want to give/lookup changing information.
I've successfully replicated the problem in Edge. What I can't figure out is why Edge is doing it. Every other browser kills the session and all its variables upon closing of the window (tested all the major browsers, including Internet Explorer). The only thing I can think of is Edge isn't actually closing as a program when the window is closing. Has anyone else ran into this problem? I can't find anything in the forums.
It is possible the session ended, but there is a bug with the cache.
I noticed that Edge is very aggressive with using cached pages. It would show a signed in page even after the user signed off (actually killing their session and updating the session cookie) because it would not respect the etag or any other cache instructions. I had to specifically prevent IE11 and Edge from caching at all.