|Problem with php sessions and ChromeFrame||Andres Lartigue Debian||8/21/12 3:55 AM|
I'm having a very hard time trying to understand a problem caused by chromeFrame on IE.
Server is creating new sessions each time the page reloads. We think it's caused by the change of the User Agent when the page loads, it's sending MSIE on top of the page and Chrome for the rest of it.
Is there a solution to these session generation ?
|Re: [google-chrome-frame:3213] Problem with php sessions and ChromeFrame||Alex Russell||8/21/12 4:27 AM|
This is the first we've heard of PHP session generation behaving this way. I'm surprised it's UA dependent. Are you not using cookies for sessions?
|Re: [google-chrome-frame:3213] Problem with php sessions and ChromeFrame||Andres Lartigue Debian||8/21/12 7:13 AM|
Yes, we're using cookies. I don't have control over the server, but I'd say that it's the default config.
|Re: [google-chrome-frame:3219] Problem with php sessions and ChromeFrame||Alex Russell||8/29/12 2:08 AM|
Can you point me at the app and/or tell me more about the server config? Or send the output of phpinfo()?
To view this discussion on the web visit https://groups.google.com/d/msg/google-chrome-frame/-/ED7DtqOAxN4J.
|Re: [google-chrome-frame:3219] Problem with php sessions and ChromeFrame||nathan...@gmail.com||8/29/12 6:49 AM|
I am having this same problem, it is really weird, Chrome Frame in IE7 uses the correct user agent when you just hit "refresh", but when going to a new url, or putting cursor in the URI address bar and hitting enter it gets a different UA
Here is the output of the relevant phpinfo, let me know if you need more.
$ php -r "phpinfo();" | grep session
session.auto_start => Off => Off
session.bug_compat_42 => Off => Off
session.bug_compat_warn => Off => Off
session.cache_expire => 180 => 180
session.cache_limiter => nocache => nocache
session.cookie_domain => no value => no value
session.cookie_httponly => Off => Off
session.cookie_lifetime => 0 => 0
session.cookie_path => / => /
session.cookie_secure => Off => Off
session.entropy_file => no value => no value
session.entropy_length => 0 => 0
session.gc_divisor => 1000 => 1000
session.gc_maxlifetime => 1440 => 1440
session.gc_probability => 0 => 0
session.hash_bits_per_character => 5 => 5
session.hash_function => 0 => 0
session.name => PHPSESSID => PHPSESSID
session.referer_check => no value => no value
session.save_handler => files => files
session.save_path => /var/lib/php5 => /var/lib/php5
session.serialize_handler => php => php
session.use_cookies => On => On
session.use_only_cookies => On => On
session.use_trans_sid => 0 => 0
Thanks for any help
|Re: [google-chrome-frame:3219] Problem with php sessions and ChromeFrame||nathan...@gmail.com||8/29/12 6:55 AM|
FYI As an update, I found that our application is salting the session fingerprint using user agent, which is what is causing this issue, I wonder what a secure work around might be?
|Re: [google-chrome-frame:3219] Problem with php sessions and ChromeFrame||nathan...@gmail.com||8/29/12 7:56 AM|
In our specific case I solved it using this function
$agent = $_SERVER['HTTP_USER_AGENT'];
$reg = '|(chromeframe/[0-9\.]+)|';
$matches = array();
$agent = $matches;
It is a temp fix because it requires a less secure salting method, but a little salt is nice :)
|Re: [google-chrome-frame:3219] Problem with php sessions and ChromeFrame||Andres Lartigue Debian||8/31/12 7:57 AM|
We have find both the source of the problem and the solution. Our host had Suhosin Patch 0.9.7 installed. They've set the parameters suhosin.session.cryptua et suhosin.cookie.cryptua to off on php.ini, and everything works fine now.
Apparently it makes php a little less secure, but it works.
Thanks for your help,