Solved

Linux SESSION reset constantly

Posted on 2013-12-27
19
610 Views
Last Modified: 2014-01-08
Hi,

I did some mess with one of my Ubuntu 12.04 LTS servers by upgrading too much (obviously). In one night I installed (with having backup, of course):
- MySQL from 5.1 to 5.5
- PHP minor version upgrade
- memcache & memcached
- mod_pagespeed

From there on I have problems with SERVER SESSIONS.
PHP does not recognise session ID and creates new Session for each click, POST or GET on every page. So, for example, trying to login into Joomla is not possible. Also forums, Wordpress....any login is not possible due to this SESSION problem.

I also tried to set
$session_store = "database"
but sessions get reset and created over and over again also in database.

So, it is NOT a problem of:
- user or browser
- session store path

But it IS A PROBLEM most obviously in a mechanism, how PHP identifies visitor as existing visitor, so he/she can access existing server-side SESSION. As PHP does not properly identify visitor, he treats each click like a new visitor and creates session for him.

I already removed all accelerators, caches and mod_pagespeed.
No errors in apache logs.


Any idea what could be wrong?
0
Comment
Question by:Andrej Pirman
  • 9
  • 4
  • 3
  • +1
19 Comments
 
LVL 108

Expert Comment

by:Ray Paseur
Comment Utility
It sounds like the HTTP cookies are not being set or returned.  Is this on the internet where we can access it with a URL?
0
 
LVL 34

Accepted Solution

by:
gr8gonzo earned 250 total points
Comment Utility
Basically, session-handling comes down to the following process:

1. User accesses the web page and presents any cookies he/she has, including one containing a PHP session ID (if it exists).


2a. If a session ID is given by the browser, then PHP looks up the session to see if it exists on the server. The default storage mechanism should be to store session files in the server's /tmp directory. You should see files like /tmp/sess_<session ID here>.

If PHP does not have read/write privileges to /tmp (check the Apache user's permissions, since most typical PHP setups are simply Apache plugins), then PHP will be unable to properly create and maintain sessions.


2b. If a session ID is not presented or if PHP cannot find an existing session on the server, it will try to create a new one.

I would debug this by first running Fiddler to make sure the browser is sending the session ID and PHP is responding with new session IDs every time. Also, I would make sure that I'm testing on a vanilla web page like this (to rule out script-based session management problems):

<?php
session_start()
if(!isset($_SESSION['time']))
{
  echo "New session created!";
  $_SESSION['time'] = time();
}
else
{
  echo "Existing session resumed!";
}
?>

I would also NOT use the database for session management (the only time I ever recommend database for session storage is for complex, load-balanced web sites). Using the default session storage location (/tmp) should be faster and less problematic.
0
 
LVL 82

Expert Comment

by:Dave Baldwin
Comment Utility
If you installed new versions without using the Ubuntu Package Manager, you may find that the paths aren't the same as the standard Ubuntu versions.  You also may find that the permissions weren't set the same either.

Note also that there are two versions of 'php.ini' in stock Ubuntu.  One is used by the command line PHP and another is used by PHP running in Apache.  Unless your new version of PHP replaced both of those, you may not be using the correct one.
0
 
LVL 108

Expert Comment

by:Ray Paseur
Comment Utility
0
 
LVL 18

Author Comment

by:Andrej Pirman
Comment Utility
Hello all,

thanx for responses!

No matter what method, domain, session save path or browser I use, SESSIONS are always re-created for every page refresh. PHP.INI location does not play role, except maybe some settings within it.

I have installed everything with Ubuntu's APT package maneger, except mod_pagespeed, which I removed by simply disabling it within loaded modules.

So again:
I appreciate very much your efforts, but please, do not look for mistakes on USER side. The issue is definitelly on server. I can see the /tmp folder on server getting filled up by new session files with each page refresh, so there's no issue with permissions, PHP.INI location and such.
Maybe something related to REFERRER, or REFERRER's IP or something like that. PHP session handler is not able to associate the current visitor with existing session - that's the problem.

Thank you all!
0
 
LVL 108

Expert Comment

by:Ray Paseur
Comment Utility
Back to the original question: It sounds like the HTTP cookies are not being set or returned.  Is this on the internet where we can access it with a URL?
0
 
LVL 34

Expert Comment

by:gr8gonzo
Comment Utility
The MOST COMMON mistake I've ever seen (and also done myself) is to discard possibilities. I've told people that an issue is not X and gone down the rabbit hole for days only to find out that it actually -was- X and I had prematurely ruled it out. That said, I know you said there are no issues with permissions, php.ini, and the user, but take it from a guy who helps developers troubleshoot problems on a daily basis - don't assume you're right about those things.

1. Don't discard what Dave is saying - the php.ini file will dictate any session-related configuration, and if PHP is using the wrong php.ini file, then you might end up with unexpected configuration settings. Try creating a phpinfo page (just put <?php phpinfo(); ?> into an empty PHP file and view it in your browser) and post the results here. It will tell you which php.ini file it is currently using and may give some information about your session setup.

2. Keep in mind that if you're using the package manager, then chances are that you're running mod_php, which plugs into Apache. This means that PHP runs as the Apache user and group, and it also means that any changes to the PHP configuration are only loaded when Apache is restarted (which you can do gracefully).

3. Make sure you are testing this problem using the script that I provided in my first comment. If you are testing it within an existing application, then there could be code-related problems that complicate the issue.

4. Check to see if the session files are EVER cleaned up. Sessions configured with an improper lifetime could basically end up getting created and never re-used. If you do use an existing php.ini file, try renaming it and restarting Apache to force PHP to use some default configuration. This can help rule out configuration issues with the php.ini file, but you'll need to use the phpinfo script to make sure that a php.ini file isn't being loaded.

5. It only takes a minute to download and run Fiddler and run a test to make sure that proper communication is happening. It will let you see the cookie settings being sent to the browser and what the browser is sending back. Fiddler is an EXTREMELY useful tool and it's free, so do yourself a favor and run a quick test with it. Preferably save the sessions archive and post the results here, too.

6. The referrer has nothing to do with session handling, unless there is code to change that. Again, use my test script for testing, and make sure you don't have any .htaccess files that change the behavior.
0
 
LVL 18

Author Comment

by:Andrej Pirman
Comment Utility
Oh, sorry, I forgot:
YES, of course it is publicaly available. Over 100 domains are affected.

I was just preparing you a link to one customer's site to test...but my test script showed, that this other domain WORKS AS IT SHOULD!

I am now testing from domain to domain to find a pattern...
0
 
LVL 18

Author Comment

by:Andrej Pirman
Comment Utility
Hmmm... that's weird.
See these two examples - both pages on the same server, same test script, also PHPINFO seems the same to me:
site 1 - NOT working
site 2 - WORKING

What I noticed is that NON working site adds parameter CSRF_TOKEN to url when clicking on "refresh" link on page, while working site does not.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 82

Assisted Solution

by:Dave Baldwin
Dave Baldwin earned 250 total points
Comment Utility
session.referer_check probably needs to be set to a null string, not '0'.  The session.referer_check is supposed to be a string and if it's not found the session is marked invalid.  http://www.php.net/manual/en/session.configuration.php#ini.session.referer-check

Here's the request and response headers from loading and refreshing the page directly that show that your SESSIONID does change each time.  It may be because of session.referer_check = 0.  The CSRF_TOKEN is not likely to have anything to do with it.
http://jujitsu-ng.si/test.php

GET /test.php HTTP/1.1
Host: jujitsu-ng.si
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Date: Sat, 28 Dec 2013 23:48:57 GMT
Server: Apache/2.2.22 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=iVLZFUSamX3jma12c22e1T2R4RZBg3g_dih8CoLRVQlUrfjmCZmIRQKkucWuQpUx; path=/; secure
X-Powered-By: ZeroPower SGH 5.3 EngineX and some PHP code, of course
X-Hacker: Yeah, my site is not hack-proof, I know :/ Just plz, don't ruin my business ;)
X-BlowJob: Life sucks, but does it swallow?
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 818
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
----------------------------------------------------------
http://jujitsu-ng.si/test.php

GET /test.php HTTP/1.1
Host: jujitsu-ng.si
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
Date: Sat, 28 Dec 2013 23:49:25 GMT
Server: Apache/2.2.22 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=fTOZhAErQNPAmX03P-ExtvFuhMpfTzoxcp4mRhb210h49HWnZUTNdsbUE5J_ujX6; path=/; secure
X-Powered-By: ZeroPower SGH 5.3 EngineX and some PHP code, of course
X-Hacker: Yeah, my site is not hack-proof, I know :/ Just plz, don't ruin my business ;)
X-BlowJob: Life sucks, but does it swallow?
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 819
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
----------------------------------------------------------

Open in new window

0
 
LVL 18

Author Comment

by:Andrej Pirman
Comment Utility
Hi Dave,

thanx for your input.
Yes, I know that SESSIONS get recreated with every refresh. That's the main problem.

I have tried settings that you recommended, so I set this to empty string instead of "0":
session.referer_check =
But that did not change anything :(

As I examined the issue, it seems related to mod_security.
See PHPINFO pages of above links and scroll to the bottom. The WORKING page has a lot of mod_security stuff there, while the NON-working page does not.

I do not know why is mod_security in charge with one web site, while it is not kicking-in with other.
0
 
LVL 82

Expert Comment

by:Dave Baldwin
Comment Utility
Did you restart Apache?  Changes in 'php.ini' do not take effect until you do.
0
 
LVL 18

Author Comment

by:Andrej Pirman
Comment Utility
Hi Dave,

of course I did restart :)

Still examining the symptom, why one web page employs all the rules of mod_security, while other does not.
0
 
LVL 18

Author Comment

by:Andrej Pirman
Comment Utility
So far I got to blind spot:
- session files do get created in both web sites in /tmp directory,
- directory permissions are 777
- session file permissions are 600
- session file CONTAINS data in both sites
- BUT in problematic web sites session file cannot be read by PHP script!

I checked and compared every possible detail, but could not find any differences. Permissions are the same on both sites (except user/group are different, because environment is chrooted). The OWNER of web site directory is memeber only of "sshusers" group.
Apache VHOST files are exactly the same.
PHP is exactly the same version, same method (Fast-CGI).

BUT still the question is why PHPINFO at the very bottom shows different details for each site.
0
 
LVL 34

Expert Comment

by:gr8gonzo
Comment Utility
Whoa - hold up! FastCGI? I thought you said you had installed PHP via apt (Ubuntu package manager) or did I misunderstand that? Last time I checked, the packages installed the mod_php, not php-fpm / FastCGI.

FastCGI definitely has different permissions setups, since you're dealing with a separate, dedicated PHP process. Can you give us more details on the configuration and steps you used to upgrade?
0
 
LVL 18

Author Comment

by:Andrej Pirman
Comment Utility
Hi,

I cannot provide exact steps of upgrade process, because it was done 1 month ago, then for 14 days we though everything is OK and backups become obsolete. then there was a problem on Magento web sites, which we thought it was due to Mysql 5.1 to 5.5 upgrade, and we fixed it with Magento fix. Then there was a Joomla problem, again, we fixed it, as it was reported only on 1 web site.
Another week later we begun receiving a lot of complaints from Joomla customers, saying they cannot login to backend anymore. So a lot of mess.

Approximate UPGRADE process:
- upgraded MySQL 5.1 to Percona 5.5
- updated PHP from 5.3.x to latest 5.3.x
- added memcache and memcached
- added mod_pagespeed
- (all of above via APT-GET)
- then I tried to complie PHP-FPM 5.4.x as a second PHP for my clients, but could not integrate it into Control Panel. Actually, in WebHosting Control Panel (ISPConfig) I added PHP-FPM with success, but web sites with that option selected did not run PHP-FPM, but previous version of PHP via FastCGI 5.3.x

...then problems begun, as I said, and I removed most or actually ALL of accelerators (memcache, memcached, mod_pagespeed, mod-security) and also:
- updated all packages on server
- upgraded MySQL from 5.5 to 5.6 version, latest

It's hard to experiment, because it is PRODUCTION, web hosting server.

Now the issue is down to these facts:
- 100% web pages are working
- among those, 70% of Joomla sites also enable LOGIN, while 30% of Joomla instalations do NOT allow login due to lack of SESSION. IT does not matter which version of Joomla it is. Affected are all versions from 1.5 to latest 3.x.

Enhanced scripts from GOOD and BAD web sites:
Good, working, session OK
Bad, NON-working, session NOT usable

If I copy script (or whole Jooomla installation) from one site to another, it will behave according to the domain. Working script will become non-working, if I copy it to bad domain.
0
 
LVL 18

Author Comment

by:Andrej Pirman
Comment Utility
Oh, my....
How could I (and the whole bunch of experts and my friends) overlook the obvious:

SESSION PARAMETERS from testing web site:
Array ( [lifetime] => 0 [path] => / [domain] => [secure] => 1 [httponly] => )

It was just wrong setting in PHP.INI:
session.cookie_secure = On

Open in new window

Should be Off.
0
 
LVL 18

Author Closing Comment

by:Andrej Pirman
Comment Utility
I have actually found final solution myself, but you helped me with testing script, which made me think. At least but not last, your efforts are worth rewarding, so thank you.
0
 
LVL 82

Expert Comment

by:Dave Baldwin
Comment Utility
Glad you found it, thanks for the points.
0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Explain concepts important to validation of email addresses with regular expressions. Applies to most languages/tools that uses regular expressions. Consider email address RFCs: Look at HTML5 form input element (with type=email) regex pattern: T…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now