Doug_M

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.

That'd be nice but unfortunately I am stuck with CentOS 6.4 and this vm will only ever see security updates going forward.

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!

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.

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

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!

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

Sweet! Short and simple (and obvious too). Thanks, Doug

Hi, I'm trying to create a multi-dimensional array from the results of an MDB2 query. All the examples I can find have the array "hard-coded" so to speak and so are not helpful. Here's what I have: // perform query $result = $mdb2->query($sql); // get results if ($result != null) { // build app array while ($row = $result->fetchRow()) { $apps[] = array(array($row[0], $row[1], $row[2])); } } Of course this doesn't work. The brackets on $apps work for a single-dimension array. I've tried two sets of brackets but that's not right either. Regards, Doug