I have a site I'm deploying and I've hit a problem. I was testing my code in a sub-directory of my clients hosting package and everything seemed fine. However I've moved the folders/files to the site root and now I'm intermittently losing all session data.
I've taken a look with LiveHeaders in Firefox and these cookies are being set:
Cookie: __utma=196298984.443251570.1275554915.1275554915.1275557276.2;
__utmz=196298984.1275554915.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmb=196298984.188.10.1275557276; PHPSESSID=3f5a363de3b7ec6084c7fdf90bec78a8;
__utmc=196298984
and
Cookie: __utma=196298984.443251570.1275554915.1275554915.1275557276.2; _utmz=196298984.1275554915.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmb=196298984.189.10.1275557276; PHPSESSID=3f5a363de3b7ec6084c7fdf90bec78a8;
__utmc=196298984
I'm by no means an expert on headers so if you need other information, I should be able to get it.
For a session to work, two elements have to both be working:
First, the browser must send the same PHPSESSID cookie with every request. The session ID will change from one session to another, so if you login tomorrow (or later today, or in a different browser, et cetera) you'll get a different ID than you have now, but during a single session the ID should not be changing.
Second, the server must be able to access the same files associated with that ID during every request. By default, PHP stores that information in the /tmp/ directory. If you have access, you could even poke around there and see what's getting stored.
The first issue is easiest to test for. Take a look at what cookies are being sent while the session is working, and then check again after the session stops working and see if the PHPSESSID has changed. The most likely cause for behavior like this would be a poorly set local computer clock, poor timeout settings on the session, et cetera.
The second issue is a bit trickier. If your browser is sending the right cookie with every request, but PHP can't access the file with information about that session, the problem is with the server. You might consider storing your sessions in a database (if you're using one anyway), which is easily done with code in the PHP manual.
A couple of things that come to my mind:
1 : Make sure that if your session is being created on www.abc.com, then all browsing happens on exactly that domain, if some pages are being sent to abc.com instead of www.abc.com, this is likely to cause session/cookie problems.
2 : also make sure that session_start instruction is available on top of ALL pages.
Related
For some reason the php session cookie file is not being stored on XAMPP in the default tmp directory, and I ran a search of the entire XAMPP for the session_id() and there are no results. Any ideas??
There is one file "sess_6mkb82rg31nmgjmf7i3ee7mjif" but it doesn't appear to be in the same format as a client-side cookie and is not the correct session id. The correct one is statically across multiple page loads "u8c6ldb8dcpddr55d542vodtpr". There are database queries coded into the file I found. I'm not sure what this may be. However it is in the correct directory where sessions are stored because there is a file called why.tmp and it says do not delete the session files.
What I am trying to do is find the session file and copy the contents to a new file with a new id because I've seen that creating a new id every page load is recommended on stackoverflow to reduce the risks of hacks by session fixation.
I am sure that the code doesn't change the session id after I get it from the virtual server because I am only at the point of getting the contents of the old session file so far.
I have built a successfully running framework that has no problems with sessions other than me finding the session file. It must be stored outside of the XAMPP directory or the data is saved within another file.
Thanks for your time!
There is a warning near the top of session_regenerate_id() in the php manual that states that on unstable networks, you may loose the session data. But for no apparent reason I decided to go back and look at the examples anyways and there is an example solution to this problem under the following heading in the manual:
Example #2 Avoiding lost session by session_regenerate_id()
Unfortunately this is normal for simulated services like Xampp and others users like me is currently having that problem if do you need more information Check de OficialXamppForum that talks about to create a $_COOKIE (for any propourse) after to use the method setcookie($NameCookie,$Content,time()+$Seconds); the LocalServer correctly assign the Cookie, but!, later if I going to refresh the page pressing F5, the cookie will be erased, now, I recommend you press the button (i) near the link in your browser and check if the info and expiration date are correctly like this image:
Later, if any information is correctly trust me the cookie was set correctly, that "XamppIssue" is not happen only on PHP-Cookies, also occur with the method $_SERVER['HTTP_CLIENT_IP' that is assumed to allows to read the private ip user ex: (XXX.XXX.XXX.XXX), but! in XamppServer was loaded like this "::1::" or "1" or "::1" or ":1:" or ":1" and can check this discussion here in StackOverFlow when the people says that the method was applied correctly but because is a LocalHost has those limitations at time to executing PHP .
Finally if you want to check DEFINITELY!! if your PHP runs correctly use a host like 000WebHost or Azure to discard any problems.
Have a nice day :D :D .
For a period of time cookies were set on a single site with different values for the domain. This resulted in some people having cookies with the same name set for both .www.domain.com and .domain.com. The site is intended to be accessed as www.domain.com. This is accomplished with .htaccess rules.
The code will use .domain.com. now for the session.cookie_domain going forward.
The issue I am having is that when both cookies exist the browser sends both (both are valid). I see this is so in the headers and also when dumping out apache_request_headers(), however, when I dump out $_COOKIE I see just one of them.
["Cookie"]=>
string(74) "foobar=hkej4qdnq5kismiq3kl07qv6k2; foobar=ocvn7anlu2f2k2l37nl9ou3c21"
And then...
array(1) { ["foobar"]=> string(26) "hkej4qdnq5kismiq3kl07qv6k2" }
My session interface read($id) method is checking the old cookie and not the one we set on login.
What is the best way to address this? I am thinking I could just change the session name/identifier and start fresh. Or maybe evaluate the Apache headers in my read implementation. I have not found much that is relevant in searching the web, just a bunch of fluff from w3schools polluting the results, so I thought this might be a good one to post here.
I had the same problem and solved it by changing the session name.
PHP allows you to access the variable $_SERVER["HTTP_COOKIE"] and parse it yourself. This allows you to access both values, of the cookie, but you can still not tell apart the correct and the wrong cookie.
Unless those cookies contain really valuable data, I would not care about the old values and just start new.
Just change the session name from PHPSESSID to SITESESSID or something else of your choice. This will make sure that your application ignores the old cookie all together. If the lifetime of your session is 0, then its a SESSION Cookie(Gets deleted when the browser is closed), in such case you can change the session name back to PHPSESSID after a few days or a month of implementation since you will be sure that no one has the old cookie.
BTW: The browser isn't sending two cookies. It's just your old session cookie still alive.
I run a website which can be reached through different domains: domainname.de, domainname.ch, domainname.at, domainname.es etc. ...
When my customer wants to pay we gets to a payment page which is of course https secured. Due to server limitations I am only allowed to have one SSL Certificate which I only put on one domain: domainname-secure.com.
Because I charge different prices I need to know which domain the user belongs to, so when redirecting to domainname-secure.com I save the domain (e.g. domainname.de) in the session variable $_SESSION['domain_default'] and pass the sessionID by adding session_id=[session_id] as a get parameter.
Then I check I take $_GET['session_id'] and run the follow command to have the session available on the domainname-secure.com:
session_id($_GET['session_id']);
session_start();
When I test it myself, it works perfectly fine but I make a log entry when somebody gets to domainname-secure.com and has not have set $_SESSION['domain_default'].
This occurs several times a day but I really have no clue why this does not work! I am testing it again and again from many different links but for me it works perfectly fine.
Can some of you imagine why it sometimes does not work?
Is it not "good" or insecure to pass the session ID to another domain and is it not always readable after redirecting?
I know it is hard for you to determain a mistake but I am searching for some know issues with session or maybe a tip how to do it in a better way?
Session are administered by PHP on a per domain basis meaning they don't mix domains intentionally.
If you would be using another session storage mechanism such as writing into the database or using memcached sessions you'd be able to overcome this limitation.
There are two approaches if you want to be able to access the session info when changing domains either:
Don't use PHP's $_SESSION, setup your own session management with memcached/redis/sql;
Or:
Use PHP's $_SESSION, but when transferring from one domain to another serialize the data in $_SESSION and put it somewhere accessible from both domains like sql;
Ok this is a weird one. I've just moved the CodeIgniter code to my client's webhost, serverlogic.com. This code has been working on over 40 other servers, but now suddenly I'm running into walls. I'm using DB sessions.
This doesn't work:
$this->session->set_flashdata('contact_message', validation_errors());
$this->session->set_flashdata('first_name', $this->input->post('first_name'));
$this->session->set_flashdata('last_name', $this->input->post('last_name'));
$this->session->set_flashdata('email', $this->input->post('email'));
$this->session->set_flashdata('zip', $this->input->post('zip'));
$this->session->set_flashdata('phone', $this->input->post('phone'));
$this->session->set_flashdata('comments', $this->input->post('comments'));
This works:
$this->session->set_flashdata('contact_message', validation_errors());
$this->session->set_flashdata('first_name', $this->input->post('first_name'));
$this->session->set_flashdata('last_name', $this->input->post('last_name'));
$this->session->set_flashdata('email', $this->input->post('email'));
/*$this->session->set_flashdata('zip', $this->input->post('zip'));
$this->session->set_flashdata('phone', $this->input->post('phone'));
$this->session->set_flashdata('comments', $this->input->post('comments'));*/
As the set_flashdata() method uses cookies to keep track of data, could it be that there is some server limit that is hit once there is too much data stored in the cookies? When investigating the headers on my server it's setting more cookies when compared to this server.
I'm also getting a PHPSESSID cookie from their server, but I don't know where it is coming from. i'm not a server admin and as they are using Nginx I'm totally in the dark on this one.
As the set_flashdata() method uses cookies to keep track of data, could it be that there is some server limit that is hit once there is too much data stored in the cookies? When investigating the headers on my server it's setting more cookies when compared to this server.
You just answered your own question,
As you said flashdata uses cookies to store the data, the fact that it is only this one server means a possibility of two things.
This particular setup is setting more data due to your code (e.g. you might not be storing a particular variable on your other setups which just happens to be tipping this over the edge).
This server is setting more cookies by itself (a possibility with nginx), it could also be an issue with nginx doing some form of internal rewrite on your cookies so a domain issue is stopping the cookies from working properly, but this is less likely.
You said that you get a page cannot be displayed error, my suggestion, look into the server logs to find out if there are any errors. next inspect the cookies using the chrome developer tools or similar, find out if the data looks like it has suddenly been cut off.
Have you tried commenting out each set_flashdata to see if it's one particular statement? Or did you work backwards from comments? Or did you just happen to start with zip?
If you are using DB sessions the structure of your table where the session data is being stored is important. The only thing I can think of is that your columns aren't set up correctly for the types of data and the length of each amount of data being stored.
Maybe double-check the table structure with other tables you have defined on the servers.
The problem is that I have a PHP script (A) that does signup, authorize Twitter, then the twitter calls back to a return PHP script (B).
In script (A), I set some $_SESSION variables, and in script (B) I will get it. Very straight foward.
I have tested it on my computersss, and it all works. I can see the session variables in script (B) set by script(A). so as my friends.
However, the most important thing is, my boss' computer cannot see it! that's the worst. he also tried on his computersss, still didn't work at his end.
I even reboot and restart the server, but still, situation remains the same.
So, my question is, is there any kind of restriction that the server cannot set the session on a computer? or,.. in which situation, the server will fail to set the session?
Server: Apache 2.2.3. Using Plesk
PHP: 5.2.5
Maybe a stupid question, but anyway... does your boss block cookies on his computer?
If that were the case and for some reason PHP was set up to not 'fall back' to passing the session ID via the query string (or the redirect stripped it somehow), that may be a problem.
The session id is different on different computers because that's the idea behind sessions. You assign a number to each visitor (the session id) and by that number you can identify users and store information in each users $_SESSION array. This array is available only to that single session/user.
If you want something to store data for all visitors of your site, you might want to use a database or a serverside cache.
Since it’s the session that fails, check that the client uses the same session on every request and not a new one. Check if the session ID is carried along properly. If you’re using a session cookie, check its validity settings and see if the session cookie is accepted by the client. See PHP Session/Cookie problems with Windows XP, Vista, IE and certain users.