Somehow, when calling another script (all other scripts than index.php), all my CMS authorisation data gets deleted. The login boolean and username consists. This only appears using Chrome/Chromium.
The chrome developer tools don't show any errors, only 200 OK and 304 Not modified.
This is really annoying since I've changed to Chromium for Firefox being to ressource-heavy.
Any solutions?
Its going to be really hard to debug without any code or anything. When you say session data I assume you are referring to your php session. This has nothing to do with the browser. Are you making sure you aren't changing the domain/subdomain while browsing at all (which will cause you to lose your session). You can check your php.ini session settings but that shouldn't matter if it is working on other browser.
I'm guessing this is occuring because your session isn't getting started properly OR the session data is getting cleared somehow in your code.
Now it appears in Fx too. The problem: The hoster updated to PHP5 and there register_globals was set to On again.
Related
This is a weird problem and I really don't know how to explain it so please bear with me. The thing is I have a php project which has been coded from scratch(no template engine or frameworks), and it works fine on localhost, but as soon as I upload it on server, for some odd reason, the pages and session data seem to arrive from a cache. For example if I try to delete a value(by submitting a form), the page loads and still shows the value, if I then hit Ctrl+F5(force reload on FF), it loads correctly showing( or rather not showing) the deleted record.
Can this happen due to any server-side settings?
Try and clear all sessions from your browser. I have experienced something similar, it could be sessions set by your local host on the browser that is conflicting with it.
Try and set cache for php files to 0 using htaccess.
I spent about 45 minutes yesterday trying to research and troubleshoot this, so hopefully someone has another idea I can try.
It started out with one of my PHP scripts detecting that the session $_SESSION was empty, so it stopped executing the rest and threw an error for me.
This entire project has worked on that server for at least half a year without any problems, and no update to code or server has been made since then.
Here's what I did then:
I created a new PHP file for testing, made sure there was nothing before or after the <?php ?> container, and wrote this code:
session_start();
var_dump($_SESSION);
$_SESSION['test'] = 5;
Then I ran the file by itself repeatedly, and it always came up with an empty session.
I had run into this before, so I checked the folder where the session files are located on the server (in my case /var/lib/php5), made sure it had the correct directory owner and permissions, deleted all the files in it and restarted apache.
No dice...
I ran the file again a few times, and each run created a NEW session file, and the session file did contain the test=5 entry, so sessions do write correctly.
So I checked the browser cookies. They are there and working as far as I can tell - both the phpsessid cookie and another cookie my site creates were there. If I delete all cookies and then run my test file again, the phpsessid cookie is recreated normally and does contain the same session id that was created as a session file.
I also added var_dump(session_id()); to the code right after session_start();, and it gave me a brand new session id every time the script ran.
We're running a PHP version that does not support session_status() yet, so that's not an option, either (not sure exactly what it would do, anyway, I'm flying rather blindly here).
So, we know sessions are created properly, the files contain the data, the cookie contains the correct id.
So as far as I can tell, the issue must lie either with the browser not sending the cookie data back to the server or the server not recognizing the session id from the cookie as an existing session.
While I was testing this, Firefox wanted to install an update, so I ran the update, but no change.
Firefox is set to receive cookies, and I did not find any exception set anywhere that would prevent them.
Given that this has been working fine for over 6 months, some freak accident must have corrupted something, but I don't know enough about Linux or the internal workings of PHP and sessions to even know where the start diagnosing.
At some point I did try session_write_close() which didn't change anything (and my whole project has always been working fine without it).
The ONLY thing that worked was this:
$c = $_COOKIE['phpsessid'];
session_name($c);
session_start();
var_dump($_SESSION);
$_SESSION['test'] = 5;
But I use session_start in a ton of pages and don't want to go through all of them to enter code that I shouldn't need in the first place...
Any thoughts?
Thanks in advance!
--- EDIT ---
I checked into the issue again, and I can confirm that the cookie name is phpsessid instead of PHPSESSID (thanks for pointing that out, #Cobra_Fast), so that is getting closer to the cause of the issue. I went into the php.ini file to put the value for session.name into quotation marks, then restarted apache, but still no change - the cookie name is still lower case. I haven't found an antivirus program on the computer, and I doubt that there's any network security that could do this... If the PHP settings are corrupted as #Cobra_Fast suggested, how could this be fixed? Editing the file just now didn't help...
After testing some more, we found a really weird thing:
Only one client computer was affected by this! We ran the code on another computer, and it worked normally, and the session cookies are written and read properly.
So it was not the server acting up at all!
I have no clue how this one computer could be just converting cookie names to lower case - it makes no sense at all, especially because it happens in two browsers...
But at least we have a "fix" for the situation, and it's out of our hands since they immediately said they were going to check that computer and re-install it if needed.
I am so majorly confused about this right now, but at least it's over :-)
Thanks for your responses!
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.
I'm not exactly sure the question I should be asking. Sorry!
I'm working on re-doing my web site so as to be using PHP5. The server lives in a buddy's basement and I just ssh in to do my coding and view the pages just like any other page out there.
I keep track of login details in $_SESSION.
When I'm sitting at my home machine I can log into the site and everything is as I expect it in terms of the SESSION being available on all pages. When I log in on my work machine, I get a successful log in and can see the SESSION variables, but as soon as I go to another page the SESSION is gone as evidenced in session_id().
My previous web site built in PHP4 (and tweaked to keep PHP5 happy) does not exhibit this behavior allowing me to log in as expected at either location before and after the change to PHP5.
I guess I'm just looking for a clue as to what to explore next... Of all the puzzles I've encountered while teaching my self to code this one appears on the face, just crazy.
I think Jake is on to something about the cookies. Make sure your browser at work is set to accept cookies from that domain. Make sure there isn't any antivirus/antimal-ware that has disabled this. I'd use fiddler to watch the traffic and headers on your work machine, and your home machine. you should be able to quickly spot the difference since it sounds like a client issue.
It could be that the computer at work isn't supporting session cookies. It's been a while since I last read about PHP Sessions, but from what I remember...
session_start() is called.
php checks to see if the browser has sent a cookie to the server (a unique identifier needs to be supplied.
if so, it then checks checks on the server for a file with the name of the session id
if successful, it parses the file and sets the variables into the $_SESSION array
Notice that step one of this process is to actually start the session with session_start() this needs to be called before any output at all.
Have you got session_start() before output?
Do you make use of session_start() in your various php files ?
One way to get around this problem could be to store your sessions in a database.
This DevShed article by Rich Smith is a good place to start:
Storing PHP Sessions in a Database
The session is no longer saved as a file on the server, but rather an entry in the DB, and should solve any cookie issues.
Are the settings in php.ini for session.auto_start the same in both ini's?
See http://de3.php.net/manual/en/session.configuration.php#ini.session.auto-start
So I have been working on a project for a client on their current web site which has been in existence for quite some time. The version of PHP used is 4.4.7, and I am not in a position to ask them to upgrade. (The system is old and it could break something) This past week I made some changes to my project, everything worked fine cookies set, pages worked. I go to test the site earlier and all of the sudden the cookies no longer work. After 2 hours of troubleshooting I finally just set up a simple test page composed of this:
<?php
setcookie('eventCookie','1', time()+7200,'/','.levijackson.net');
echo $_COOKIE['eventCookie'];
?>
I put this on both their site as well as my own (I changed the .levijackson.net to the appropriate domain)
I did 2 refreshes of the page on both pages and only on mine did it return the cookie. So what could have caused something like this? Is there a certain setting that may have been changed by their admin/host?
I did test and HttpOnly cookies still work, so I am going to switch to them while I troubleshoot.
edit: Almost forgot to mention, it works fine in FF but in Chrome and IE it doesn't work at all. Not sure if this will be useful, but I still think that it is not the browser.
Thanks
Levi
Just a guess-- it could be that their server has auto_prepend_file enabled, and the file that is being auto-prepended outputs something to the client. Once anything is sent to the client, set_cookie() will not work, since cookies have to be set in the page header, which must be sent before anything is sent to the client.
If it's not that, try diff'ing the "PHP Core" section of a phpinfo() dump, looking for any other settings that might somehow affect this.
Edit: Here's something else you can try, if both sites are publicly accessible. Go here: http://web-sniffer.net/. This site will show you the actual HTTP headers which are being returned by the site. Run the test file for both sites, and look to see if there is any difference in the Set-Cookie headers which are returned.