I am working in a Php application and I have a problem regarding session management.
Whenever I request an an asset (by requesting a file file an extension) that isn't there, I correctly receive a 404 response, but a new session cookie is set. Hence the next time I make a request I am logged out.
The new cookie is set when the call to session_start() is made. It seems that Php is not able to understand the fact that there is already a session cookie present in the HTTP request and therefore it generates a new one.
To make everything more interesting, this happens only in our production environment, where we have Zend Server with Php 5.4.23. The problem does not manifest itself locally where we have just Php 5.4.16.
Do you have any suggestion on how I could solve or investigate futher this issue?
Related
I am using SimpleSAMLphp (SSP) to handle authentication for my Yii website (via a remote IdP), and version 1.16.3 has been working fine. However, when I update my composer.json file and pull in version 1.17.2, the local PHP session on my website is no longer destroyed, leaving the user logged in. (The user is successfully logged out of the IdP, however.)
I did some Googling, and reviewed discussions that looked relevant:
The change in how session IDs are generated, to comply with PHP config.
Documentation about a mismatch between PHP session settings for the application and SimpleSAMLphp (as a possible source for session-related errors).
The need to give PHP and SimpleSAMLphp different session cookie names: https://github.com/simplesamlphp/simplesamlphp/issues/365#issuecomment-212351265
I also reviewed some discussions in the SimplSAMLphp mailing list:
https://groups.google.com/d/topic/simplesamlphp/k0AhOO8LLSk/discussion
https://groups.google.com/d/topic/simplesamlphp/x8d53SkhEhE/discussion
In addition, I tracked the logout process using SSP 1.16.3 and 1.17.2 recording each Cookie header in requests, Set-Cookie header in responses, and session files in existence at multiple steps along the way, which showed some distinct differences... but I don't know what to conclude from this information.
When I begin the logout process on my website (which is built using Yii 1.x)...
I start by bringing up a clean docker container of my website, opening a fresh private Firefox window, and opening SAML Tracer. I verify that no session files currently exist on the server (i.e. in the new docker container).
I go through the login process.
1.16.3 and 1.17.2 behave almost identically. At the end of the login process...
For both, my PHP session cookie's session file exists and is 7722 bytes.
1.16.3: My SSP session cookie's session file exists and is 2294 bytes.
1.17.2: My SSP session cookie's session file exists and is 2302 bytes.
I go to /auth/logout/ on my site, and the browser dutifully sends along my current PHP (PHPSESSID) and SSP (SimpleSAML) session cookies.
1.16.3: no Set-Cookie headers are returned.
1.17.2: a Set-Cookie header is returned for the SSP session cookie, but the value is the same as it was before.
I am redirected offsite (to the remote IdP) as part of the logout process.
I am returned to /simplesaml/module.php/saml/sp/saml2-logout.php/default-sp?SAMLRequest=… (and along go current PHP and SSP session cookies).
1.16.3: a Set-Cookie header is returned for the SSP session cookie, but the value is the same as it was before.
1.17.2: two different Set-Cookie headers are returned for the SSP session cookie, neither of which matches the previous value.
I am redirected offsite again, as a further step in the SAML logout process.
I am returned to / (the root of my site), with my (unchanged) PHP session cookie and (most recent) SSP session cookie.
1.16.3:
a Set-Cookie header is returned for the PHP session cookie, giving it a new value.
the session file for the previous PHP session cookie has been deleted from the server.
the session file for the new PHP session cookie is empty.
the session file for the most recent SSP session cookie is 474 bytes.
I am no longer logged in on my website.
1.17.2:
no Set-Cookie headers are returned, for either the PHP or the SSP session cookie.
the session file for the PHP session cookie is 7722 bytes.
the session file for the SSP session cookie is 338 bytes.
I am still logged in on my website (but not on the IdP).
I can (sort of) alleviate the problem by telling Yii during the logout process to return an empty value for the PHP session cookie (PHPSESSID) and set it to expire an hour ago, but since that leaves the session file itself still in place, that approach seems unsatisfactory.
Given that information, does anyone have any ideas or pointers on where I could look next to try to determine what might be causing this?
As things stand, I don't know if this is a result of me using Yii incorrectly, me using SSP incorrectly, or a bug in SSP 1.17.2.
I have not yet managed to distill this down to a minimal, reproducible example, and I apologize for that. The code is open source, though I doubt anyone wants to go digging through it:
This commit of my code is how I tested SSP 1.16.3:
https://github.com/silinternational/developer-portal/tree/2fa781f8bbdf9bb248038e18af64b024eb9a67e1
This commit of my code is how I tested SSP 1.17.2:
https://github.com/silinternational/developer-portal/tree/e581cbe0f309786cc99eab296896c8c7bdb29b99
It turns out that I simply needed to tell SimpleSAML's Session class to do some cleanup, after which the PHP function session_name() resumed returning my application's session name ('PHPSESSID') rather than SimpleSAMLphp's session name ('SimpleSAML'). That allowed my application's logout code to kill the correct session, fixing my ability to log the user out of my application.
Here was the code change that fixed it for me:
$sspSession = \SimpleSAML\Session::getSessionFromRequest();
$sspSession->cleanup();
This is something weird. I am developing an app that checks via AJAX if the session timed out at every page load and every user action. On top of this, I make other ajax calls for other user actions.
This works well on my xampp server, locally. However, when I'm testing them on my client's server, a shared host working on a CPanel thingy, the first AJAX call works, and then all the other calls fail with an error code of 500.
Is this familiar to someone?
PHP has a session lock, Check that your session is not locked after the first session starts. I had once face these problem in my own PHP MVC framework where i was actually requesting multiple times the url with the jquery, after first one then my session was locked, check on it, if that might be the case
I'm having problems with PHP sessions that only occur on my testing server (everything works fine on my localhost). I'm developing a custom Wordpress theme, based on Roots. My localhost is OS X (PHP 5.4.4) and the testing server is Ubuntu (5.3.10-1ubuntu3.8).
The problems include:
New sessions created each time I refresh the page (which I can see by rendering session_id() in the footer and checking /var/lib/php5/session)
Functions called through an AJAX request unable to access the correct session, even though session_name() and session_start() are called before they try
Other details:
I'm trying to save variables into a named session, so each time I call session_start() I'm currently doing it like this:
session_name('my_session'); //Not sure if this line strictly required
if (!session_id()) {
session_name('my_session');
session_start();
}
The above is first called in a function init_sessions, hooked into Wordpress like this: add_action('init', 'init_sessions');, then also used in the other files that need access to session variables (e.g. those requested via AJAX).
On localhost, I can see the session file created in /Applications/MAMP/tmp/php and also see a session appear under the Cookies tab in Firebug. However on my testing server, although (too many) session files are created in /var/lib/php5/session, I don't see the session appear in Firebug.
Running phpinfo() doesn't show any significant difference between the PHP directives on my localhost and those on my testing server.
The testing server is really two (Rackspace) servers with a load balancer, but I don't think this is an issue as session persistence is set up.
The testing server is set up as a subdomain e.g. test.my-domain.com.
I've got PHP error reporting turned on but haven't noticed any.
I've deactivated all other Wordpress plugins.
I'm sure it's more likely to be a problem with my script than Rackspace's set-up, but I'm a bit stumped at the moment. I'm particularly curious about why I can see session files created on the testing server in /var/lib/php5/session, but don't see them appear in Firebug's Cookies tab.
Any ideas very welcome. Thanks!
Ok - think I've identified what's going on (though not resolved it yet). It looks as though the problem is down to Varnish. When a user is logged-in, the session functions perfectly. Thanks to everyone that suggested a fix.
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.
This morning my local php starts behaving strangely: the session ID changes on each request (making sessions unusable).
The code:
<?php
session_start();
The same page is available through "localhost" and "test" which is a /etc/hosts entry for localhost.
Requesting this same file on "localhost": the PHPSESSID cookie stays the same; on "test" it changes on every request.
Absolutely nothing changed in my code (no BOM or buggy code) or in Apache's config. I may have updated PHP (5.4.4), but reverting to the previous version (5.4.1) showed the same behavior. The same code running on a remote server (php 5.3) has been running ok for ages.
It's probably a bug in PHP :( but before reporting, I want to be sure I didn't overlook anything.
Any idea?
Thanks for your amazingly fast answer.
In fact the browser works fine, everything is working fine, even PHP.
I just forgot I added a .htaccess clearing all cookies to upload to a CDN. The only thing I didn't check was the .htaccess.
I feel stupid (and tired).
Thanks again.
Install some software watching HTTP headers like
Live HTTP Headers Firefox addon https://addons.mozilla.org/en-us/firefox/addon/live-http-headers/
WireShark sniffer http://www.wireshark.org/
and check whether
Server sends the cookies as it should
Browser sends them back.
Probably the Cookie header contains settings which make Browser not to send it back, and therefore server generates a new cookie (new session) for every request.
Especially check the path setting of the cookie you send.
Also, it might be some new policy in browser, or a security plugin, or maybe antivirus... try different browser, or bare curl program, and disable web shield of your antivirus if applicable.