We have several quality domains with the identical code base. We are converting from using the native PHP session handler to a custom session handler writing the session data to MySQL. On certain domains the session handling is broken because the session data written to the database is corrupted.
At first we thought it might have something to do with different PHP levels on the different domains. However, we have ruled this out as one domain where it is not working has the same PHP level as a domain where it is working.
This question seems similar to the one at Custom Session Handler not working on PHP5.6 but does on PHP7. However, in our case the issue is not resolved by adding session_write_close().
Here is some debugging output from the two different instances that clearly shows what is happening. In each case, first a print_r of $_SESSION is shown, followed by the contents of the session data as it will be written to the database:
On first domain designated as "local":
Before write--session data via print_r:
Array ( [debug] => Array ( [0] => Session ID e2104hafmvtur2rsof78m918gs ) [scr_width] => 2560 [recent_page_view_history] => Array ( [0] => / [1] => / [2] => / [3] => / [4] => / [5] => / ) [my_user_label_full] => Independent Sales Rep [my_user_label_short] => Rep [opp_user_type_id] => 2 [opp_user_label_full] => Principal [opp_user_label_long] => New Line [opp_user_label_long_seo] => Independent Sales Companies & New Line [opp_user_label_short] => Principal [user_value_stmt] => Industry Expertise [opp_user_value_stmt] => Sales Opportunity [with_or_as] => as an Independent Sales Rep. This guide for companies that hire reps will help you understand how to be a better rep. [is_help_open] => 1 [referrer] => / [IE_warning_given] => 1 [link_mode] => 0 [isTouchScreen] => 0 [dynamicInputWording] => point your cursor at [dynamicInputWordingCapitalized] => Point your cursor at [devicePixelRatio] => 2 )
Before write--data passed into custom session handler write():
debug|a:1:{i:0;s:37:"Session ID e2104hafmvtur2rsof78m918gs";}scr_width|s:4:"2560";recent_page_view_history|a:6:{i:0;s:1:"/";i:1;s:1:"/";i:2;s:1:"/";i:3;s:1:"/";i:4;s:1:"/";i:5;s:1:"/";}my_user_label_full|s:21:"Independent Sales Rep";my_user_label_short|s:3:"Rep";opp_user_type_id|i:2;opp_user_label_full|s:9:"Principal";opp_user_label_long|s:8:"New Line";opp_user_label_long_seo|s:42:"Independent Sales Companies & New Line";opp_user_label_short|s:9:"Principal";user_value_stmt|s:18:"Industry Expertise";opp_user_value_stmt|s:17:"Sales Opportunity";with_or_as|s:117:"as an Independent Sales Rep. This guide for companies that hire reps will help you understand how to be a better rep.";is_help_open|b:1;referrer|s:1:"/";IE_warning_given|b:1;link_mode|i:0;isTouchScreen|s:1:"0";dynamicInputWording|s:20:"point your cursor at";dynamicInputWordingCapitalized|s:20:"Point your cursor at";devicePixelRatio|s:1:"2";
The above looks as expected and the website works normally.
On second domain designated as "dev":
Before write--session data via print_r:
Array ( [debug] => Array ( [0] => Session ID v301fcrls9ijktjtlc7n4gd3n5 ) [scr_width] => 2560 [recent_page_view_history] => Array ( [0] => /landing-page.php [1] => /landing-page.php [2] => /landing-page.php [3] => /landing-page.php [4] => /landing-page.php [5] => /landing-page.php ) [my_user_label_full] => Principal [my_user_label_short] => Principal [opp_user_type_id] => 1 [opp_user_label_full] => Independent Sales Rep [opp_user_label_long] => Sales Rep [opp_user_label_long_seo] => Independent Sales Rep [opp_user_label_short] => Rep [user_value_stmt] => Sales Opportunity [opp_user_value_stmt] => Industry Expertise [with_or_as] => with Independent Sales Reps. [is_help_open] => 1 [referrer] => /landing-page.php [IE_warning_given] => 1 [link_mode] => 0 [isTouchScreen] => 0 [dynamicInputWording] => point your cursor at [dynamicInputWordingCapitalized] => Point your cursor at [devicePixelRatio] => 2 [site_user_type] => 2 [lp_source] => register-external )
Before write--data passed into custom session handler write():
pQkKjjiuhsxKkLD5bG1pcvfRiU073NotPwuYW3TrIAEwiKACrZ1s6dbIQmOeo7430UQAYgu_GENi_KhZx4vSUdaV4iXmSOVxNZgoNC_7-xDzOMDdRo7zp3sk-_aEv3XyenNiNtcy5GkE7UH1O1qKG-WBXel7bDNJ6hVUaadz9DoBwzhHFid5O5TOBT9gccwzAab2DWN-sa4vjwSDwaQ03rxquQT07iv4T_BQPvB2_pLYB_fz7GSI470o-bePEb4N209gd3oUA4xlg0Hw4pCssCN6FO6vtamNzaTqXDpS-f9nGhxpALp1eUZ1ts9nzbAZQ_llj0XbOW3FtnmnargZjbigJBWvL5XmD_bg5yIZwCHxJ4w8CWrKjasjfuInLMmzi02ViEtjmxtCZ5kLMETjE42MOSRuqrK7wr6zZFEha3gK2wfzQvrIwbr3ZEQTOpzBinYggiECiLAkpH4qy6XTjgnc-RT4_r4L7_LD2rBtXKjm3gNJgjZeLjeUMZubXBcLVGiW1ELuLgq0zHmU6ppIAMhk1rkThOMq3qgyQ0rsJGauTPDrImWzbbbnBgbooYywscjZjf-KNoRyCEaZRFga1zEeQWheEYFO7miVXFi-BSZZYJfXFHuto-kcfV9yZHInlz9p1Lcgd0YpbVUeIwZb2MUPhhzASDUnu4uuy_iVUn6WsyuEciQVYhEDcLBYJ6zHlSTs46vOWJdjE19LR8HQQL5jKJZBJpeC_jqgTNDWsVC5B1hZKpFswDZnOrUgEKOS9rHfusYOw0Ydczhr67TBTzCVUZvJVbm77LgBuY-JuLCv2Yv6mMCltXohtxMhb5t6PMXTnQTsinJD_SdY0YQZbAo26iPlO3u690IJd2tncPFZavwcflKodm_KW0LLtUR4CX4MZ0tmqY0qB1lkW8qgri6aZKAvgurr9BZhZcNqcsnAb6Po7zLdZOtwM3KF51LBzbcxGiDG6yWUy_9nw9p_y9GadXbfhfFbmR5jTQsaJLxR2-Y_2TiMxhgkWu7G2Buv6IZqUD-dCvU9vXQTnyUhlVijsO1pP02IxqtyO4D8cGp4k8l7IxeuqxsbX2oj7IdhiYIwG5t5IfEKTOQiimjPV0jSsBhwIftD5U-ofwpEQjcd7MLrzm7iX3eZuFnVvvNsMg_TCOScvs4b0DhV46KdDLfdD4WMoVhI6QnFH4s7jiqI9TYQNLRqSZNqO1cdFGHSyLcT1qGpDpZn0-ljpV_nzrYDXe6d2fsejqBZs_aWAZQFFJ7qMwUzVX53dzLgTf3ziAzPwPayQl8NBd8VptIKiVLZfN1v0tofRPuNXXVUd2s.
As you can see, rather than the special serialized version of the data, it becomes obfuscated in some way. And session handling is broken.
On a domain designated as "qa", the output is identical to "local". Please note that "local" has php 7.1, while both "dev" and "qa" have php 5.6. The php.ini files for all three domains have identical settings for session.* variables.
Question: what is the cause of the obfuscation of session data?
We found the solution. It was that Suhosin was enabled on some domains but not on others. Suhosin automatically encrypts the session data.
We will be losing Suhosin as we move forward as it appears to not be an integral part of PHP 7+. Either is is not available, or does not compile properly.