Fixing json_encode() Problem in PHP 5.5 on Ubuntu 13.10

I upgraded to Ubuntu 13.10 over the weekend and everything went pretty well. It automatically brings PHP 5.5 with it, too. When I tried to run a web app I was working on, though, I received this message:

Fatal error: Call to undefined function json_encode()

I subsequently Googled around and came across a highly-ranked blog article which makes it sound like PHP 5.5 drops support for json_encode because of some silly licensing argument. The truth is, PHP 5.5 does NOT drop support for json_encode. For a much better and much clearer explanation, I recommend reading this article.

Now, enough of the balleyhoo! How do we fix it?

It was was easy! Install the php5-json package and restart Apache. Voilà!

sudo apt-get install php5-json
sudo /etc/init.d/apache2 restart

Note that the author of the blog article linked above mentions that re-installing the php5-dev pacakged fixed his woes. While that didn't help me, you may want to give it a try if the above didn't help you.

Symmetric-Key Encryption: AES in PHP and what "mode" to choose

Doing some encryption? Want to use the same key for encryption and decryption? Well, I did too. Here are the results of a lot of internet searching.

The 'mcrypt' extension in PHP is the place to go for AES, symmetric-key encryption. AES is safe and secure – the US government has even ok'd 192-bit AES (and up) for top secret documents. You can install it by running yum install php-mcrypt (if you're running Red Hat or CentOS) and then it is available for your coding pleasure.

The next decision is what "mode of operation" to use for your AES encryption. There are a few different ways to do all the fancy math and permutations. Some are more secure than others. You'll notice that when using the mcrypt_encrypt() command, you have to specify the mode as the 4th parameter. You have a choice to make. PHP 5.4 currently has the following modes available (you can find all the options available to your environment by using mcrypt_list_modes):

• cbc
• cfb
• ctr
• ecb
• ncfb
• nofb
• ofb
• stream

If you're in the same boat I'm in – aka "not a cryptographer" boat – then this is just a nice list of letters. But there are a lot of cryptographers who put a lot of good info on the interwebs, thank goodness. I ran across this article on AES usage tips, then there is the overly-neutral Wikipedia article, and a good-enough answer to a similar question on Stack Exchange.

Here are my collected thoughts on the matter:

1. One glaring thing I came away with from all these sources is this: DON'T USE ECB. 
2. The second thing I came away with is this: CTR would be the ideal, if it was available. This is because it does some authentication to make sure the encrypted message really is an encrypted message and not some sort of cryptographic trojan horse. (The simple solution to this is to make sure you HMAC hash your encrypted text to make sure it isn't tampered with.)
3. The last thing I came away with is: Use OFB or CFB because they are pretty darn good and available in mycrpt.

Other thoughts? Do you know of even better articles on modes of encryption? I'm all ears!

Checking the last SQL statements used by PHPActiveRecord

I'm using PHP-ActiveRecord on a project and am loving it. But there are some things to learn and as a guy coming from the write-your-own-sql world, I do occasionally want to check what SQL queries that ActiveRecord is sending out there. I've used this bit of a code a few times to do so and it is immensely helpful for me as I try to see if I'm using this package correctly:

echo Model::table()->last_sql;

Pop that in after you do your Model::find() or Model->save() or whatever, just be sure to swap 'Model' out with your model's actual name.

Error starting Apache (httpd) - Configuration files not readable

Here is an interesting issue I ran into today while setting up a new VM. I had copied the Apache conf file and SSL/TLS certificate files onto my new server as root using wget. All of the file's ownerships and permissions looked right and I thought I was ready to go. Then I ran into these two misleading errors:

Could not open configuration file /etc/httpd/conf.d/ssl.conf: Permission denied

and

SSLCertificateFile: file '/etc/pki/tls/certs/mydomain.com.crt' does not exist or is empty

Contrary to what Apache reported, the ssl.conf file did have the correct permissions and the crt file did exist and had contents. So what gives? Our trusty SELinux friend is at it again, it seems. Because I had copied these files in from somewhere else, SELinux was detecting something off. It is an easy fix, though. Just run this command, specifing each of the files above:

restorecon -v /etc/httpd/conf.d/ssl.conf

and

restorecon -Rv /etc/pki/tls/certs/

That -R is for "recursive" and it means I want it to do the whole directory.

After fixing up the SELinux permissions for these files I brought in, everything started up just fine!

Using SQLite for Unit Testing in PHP

Unit testing is infamous when one attempts to test database-interacting classes. I noted that some had suggested using SQLite when running phpunit to test these sorts of classes. Been working for me, so I thought I'd jot it down here.

First, make sure sqlite3 is installed. On Ubuntu you'd run the following at the command prompt (assuming this step is necessary, but now I'm not quite sure):

sudo apt-get install sqlite3 libsqlite3-dev

Next, make sure PHP support for sqlite3 is installed enter this at the command prompt:

sudo apt-get install php5-sqlite

And then, in the part of your PHP script where you set up PDO (if that's the class you use, as I do), you can specify sqlite's in-memory DB:

$conn = new PDO('sqlite::memory');

Non-Profit Merchant Account Tips

I feel like I've been around the block with merchant accounts. This is especially true for non-profits and online donations – I've been working in this field for a number of years. If you want to accept donations online and you want to do it without giving PayPal a big chunk of it, merchant accounts are the way to go. You'll need a platform or a good programmer, but those are pretty easy to come by these days (wink, wink).

If you're a non-profit the risk you pose to the financial world is low giving you a little leverage when securing a merchant account. Here are few tips for those who are looking:

• Say 'no thanks' to contracts - The merchant service provider doesn't really need you to sign a contract. They just don't want you to leave and who can't blame them, that's how they make money. But you don't need no stinkin' contract. There is too many providers who will give you a good deal on a merchant account without one. Plus, you need an out if they decided to raise their prices on you one day (which happens, sometimes without warning).
• Opt for 'interchange plus' pricing - There are a few pricing options out there. Interchange plus usually ends up being the best deal because they give you wholesale rates plus a little overhead added on. In this case, if a donor uses a debit card that has a really low discount rate (say 0.5%, thanks to the Durbin amendment) then your saving a ton of money. Other common, not-as-good options include 'tiered' and 'ERR' pricing. You might say that tiered pricing is credit card processor lingo for 'round it up and I'll keep the change' and ERR pricing is synonymous for 'round it up and add some extra just in case'.
• Ask for an itemized list of fees - The merchant world is all about fees, fees and more fees. And merchant service providers, generally speaking, do their best to hide fees. They do this so often that even when they're trying to be transparent, they're still hiding fees. It is really crazy and one of the few industries that can somehow get away with it (not sure why that is). When you get a merchant account quote, tell them you want to know about them all: gateway fees, statement fees, PCI compliance fees, IRS fees, Visa/MC fees, AMEX fees, discount rates, per-transaction fees, per-auth fees, batching/settlement fees, .... everything!

Hope this helps and if you have any questions, reply below.