Doug_M Posted May 9, 2013 Share Posted May 9, 2013 Hi, I've got a project that is being migrated from an older SLES 10 server to a vm running CentOS 6.4. On the older server and in test environments everything works as it should. On the vm base64_encode seems to not be working but does not give any errors. I have a session var where I take an array, serialize it and base64_encode it. When that var is read in another script it is base64_decoded and un-serialized. Like I said this works everywhere but the vm. On the vm I examined the session file and the var is serialized only. I've checked php.ini and the output of phpinfo, comparing them with my dev environment and I don't see anything that would indicate why this isn't working. If the base64_encode function was disabled in php.ini (it isn't) there'd be a warning message when my script tries to use it. When testing there are no errors of any kind until base64_decode is run on the un-serialized var. Then the error "PHP Warning: base64_decode() expects parameter 1 to be a string, array given". This of course is because the var was only serialized despite being assigned as: $_SESSION['whatever'] = base64_encode(serialize($somearray)); The vm setup is CentOS 6.4 with PHP 5.3.3 on Apache 2.2.15. I'm banging my head against the wall right now so any suggestions would be much appreciated. Thanks, Doug Quote Link to comment Share on other sites More sharing options...
Solution mac_gyver Posted May 9, 2013 Solution Share Posted May 9, 2013 the problem is likely due to register globals or you have a session_write_close() prior to that assignment statement so it isn't actually storing to the session data and you are seeing a previous value that was stored or the code isn't successfully starting a session so that you are seeing a previous value stored in the session data. do you have php's error_reporting/display_errors both set to full on so that any session or variable reference errors will be reported? have you tried just echoing the base64_encode of a string to see what it outputs? Quote Link to comment Share on other sites More sharing options...
Doug_M Posted May 9, 2013 Author Share Posted May 9, 2013 I telework and am 2 hours away from the vm to which I do not have remote access. Point is, I can't test things out today and won't be going there in person until I have enough ideas to test. That being said I do have a printed copy of phpinfo output and register_globals is on whereas is it off in my dev environment. The vm was set up by another department and I was told php settings were default install values. I doubt that though because in my personal testing of CentOS 6.4 register globals is off. How does register globlas being on interfere with base64_encode? Thanks, Doug PS You're making my day and it's only 9:30 here! Quote Link to comment Share on other sites More sharing options...
mac_gyver Posted May 9, 2013 Share Posted May 9, 2013 register_globals (thanks php.net) would overwrite $_SESSION['whatever'] any time you do $whatever = some value; and it will also get overwritten by a $_POST['whatever'], $_GET['whatever'], or $_COOKIE['whatever'] value. Quote Link to comment Share on other sites More sharing options...
Doug_M Posted May 9, 2013 Author Share Posted May 9, 2013 Well that certainly sounds like the culprit. I've asked a colleague to test it out but it may take some time before they get back to me. This is one of those rare times when teleworking sucks! Thanks again, Doug Quote Link to comment Share on other sites More sharing options...
jazzman1 Posted May 10, 2013 Share Posted May 10, 2013 SELinux doesn't allow your httpd daemon to talk to the LDAP server on the same machine, so I had the same problems from Centos 6+ versions. Speak with your sysadmin and change the configuration file of SELinux. Quote Link to comment Share on other sites More sharing options...
mac_gyver Posted May 10, 2013 Share Posted May 10, 2013 @jazzman, your reply is for some other thread. Quote Link to comment Share on other sites More sharing options...
jazzman1 Posted May 10, 2013 Share Posted May 10, 2013 @jazzman, your reply is for some other thread. @mac_gyver can you prove your statement? If SELinux's configuration is enable by default you should not use php functions that talk to LDAP server as copy(), mkdir(), mail(), and so on..... I am CentOS (RedHat) user more than 13 years, so I'm almost 100% sure that the problem is there. Quote Link to comment Share on other sites More sharing options...
Doug_M Posted May 10, 2013 Author Share Posted May 10, 2013 SELinux doesn't allow your httpd daemon to talk to the LDAP server on the same machine, so I had the same problems from Centos 6+ versions. Speak with your sysadmin and change the configuration file of SELinux. I took care of that well before this issue presented itself. I can't remember the command off the top of my head but there is an setsebool command to allow httpd communication among other daemons. I needed that to enable Apache to "talk" to PostgreSQL. But either way I don't think this is related to base64_encode of a PHP session var as it is not a case of Apache communicating with another daemon. Thanks, Doug PS Still waiting for my colleague to try out the register_globals change. I will reply to this thread with the results when I get them. Quote Link to comment Share on other sites More sharing options...
mac_gyver Posted May 10, 2013 Share Posted May 10, 2013 @jazzman, READ the thread you are replying in. it concerns a php $_SESSION variable being overwritten. Quote Link to comment Share on other sites More sharing options...
Doug_M Posted May 10, 2013 Author Share Posted May 10, 2013 Well thanks mac_gyver, that did the trick. Now the hard part, finding out why the person who set up the vm turned register_globals on ('cause it doesn't come that way) without insulting their feelings! Quote Link to comment Share on other sites More sharing options...
mac_gyver Posted May 10, 2013 Share Posted May 10, 2013 if you can upgrade to php5.4, register_globals have been completely removed and so cannot be turned on, and you won't ever see program variables being overwritten by the language itself. Quote Link to comment Share on other sites More sharing options...
jazzman1 Posted May 10, 2013 Share Posted May 10, 2013 I took care of that well before this issue presented itself. I can't remember the command off the top of my head but there is an setsebool command to allow httpd communication among other daemons. I needed that to enable Apache to "talk" to PostgreSQL. But either way I don't think this is related to base64_encode of a PHP session var as it is not a case of Apache communicating with another daemon. Thanks, Doug PS Still waiting for my colleague to try out the register_globals change. I will reply to this thread with the results when I get them. @Doug_M, you did not mention by the fact of SELinux configuration above. You also said that you're using the same php version with the same configuration but obviously is not true. I've checked php.ini and the output of phpinfo, comparing them with my dev environment and I don't see anything that would indicate why this isn't working. Hey mac_gyver, it's a good trick, where did you get that Quote Link to comment Share on other sites More sharing options...
Doug_M Posted May 10, 2013 Author Share Posted May 10, 2013 if you can upgrade to php5.4, register_globals have been completely removed and so cannot be turned on, and you won't ever see program variables being overwritten by the language itself. That'd be nice but unfortunately I am stuck with CentOS 6.4 and this vm will only ever see security updates going forward. Quote Link to comment Share on other sites More sharing options...
jazzman1 Posted May 10, 2013 Share Posted May 10, 2013 That'd be nice but unfortunately I am stuck with CentOS 6.4 and this vm will only ever see security updates going forward. That's extremely easy in CentOS. Open up a terminal as a regular user and just install "Remi" repository by redhat package manager (RPM) ## Install Remi & Epel Repository on RHEL/CentOS 6.4-6.0 - 64 Bit ## su -c 'rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm' password: (root pass) su -c 'rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm' password: In case you are on CentOS 32: ## Install Remi & Epel Repository on RHEL/CentOS 6.4-6.0 - 32 Bit ## rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm Then, install Apache, MySQL 5.5.x (in case you're using mysql-server) & PHP 5.4.x ## Installing on RHEL/CentOS 5-6 ## su -c 'yum --enablerepo=remi,remi-test install httpd mysql mysql-server php php-common' password: Install a php 5.4.x modules, you can customize this process too: ## Installing on RHEL/CentOS 5-6 ## su -c 'yum --enablerepo=remi,remi-test install php-mysql php-pgsql php-pecl-mongo php-sqlite php-pecl-memcache php-pecl-memcached php-gd php-mbstring php-mcrypt php-xml php-pecl-apc php-cli php-pear php-pdo' Finally set the run-levels to Apache, MySQL ## Enable Apache and MySQL on Run-Levels ## # chkconfig --levels 235 httpd on # chkconfig --levels 235 mysqld on ## Apache Commands ## # /etc/init.d/httpd start # /etc/init.d/httpd stop # /etc/init.d/httpd status ## MySQL Commands ## # /etc/init.d/mysqld start # /etc/init.d/mysqld stop # /etc/init.d/mysqld status When I followed this guide few weeks ago, I've got an error for missing library named: libvpx. You can download it by wget and install it by rpm: wget ftp://ftp.pbone.net/mirror/atrpms.net/el6-x86_64/atrpms/stable/libvpx0-0.9.7.1-1_1.el6.x86_64.rpm su -c 'rpm -ivh libvpx0-0.9.7.1-1_1.el6.x86_64.rpm' That's all Hope, that helps you. Quote Link to comment Share on other sites More sharing options...
Doug_M Posted May 13, 2013 Author Share Posted May 13, 2013 That's extremely easy in CentOS. Didn't mean I don't know how to do it. I meant I am not allowed. This is strict corporate environment on an internal network with policies that prevent me from...well...having what I want. Quote Link to comment Share on other sites More sharing options...
jazzman1 Posted May 14, 2013 Share Posted May 14, 2013 @jazzman, READ the thread you are replying in. it concerns a php $_SESSION variable being overwritten. @mac_gyver, I am aware of what the message is, but in fact that this message could be also appear as a result of SELinux configuration! That's why my first reaction was to ask @OP about that. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.