Jump to content

base64_encode not working but giving no errors


Go to solution Solved by mac_gyver,

Recommended Posts

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

  • Solution

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?

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!

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.

@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.

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.

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  :tease-01: 

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.

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. 

@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.  

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.