Here are the slides from the talk I gave at PHP Appalachia about using PHP and Asterisk.
PowerPoint (585k)
PDF (390k)
I do a little bit of work for a friend on the side every now and then. He has a small online store set up with a credit card processor to handle processing payments for his credit cards. Every so often if he hasn’t gotten orders in a few days, he gets a bit antsy and asks me to log in and check to be sure no orders have gotten through without him getting an alert. Dutifully, I do this, as it usually only takes me about 30 seconds to make sure everything is working - as it always is.
However, a few months ago I tried to log into his virtual terminal account, I was treated to a ominous warning, informing me that my password had “expired” and asking me to enter my password again, as well as selecting a new password. I had never seen that before, so I checked to make sure I was logging into the right site and had not somehow managed to fall for a phishing attack. Sure enough, my password had “expired.”
Hmm. This is lame.
Maybe I’ll try to be smart with it and reenter the same password … nope. It’s smart. Can’t get around it. Because I had other things to do and this is already wasting my time, I concede defeat and create a new password for logging onto this site. Then, I do the unthinkable. Something that would make any security researcher and probably the “designer” of this system cringe in horror: I write the password down in a text file. Now anyone who manages to steal my laptop could potentially have access to this (of course, the file is encryped with the original password, though, so there is that).
Fast forward a few months. Another e-mail, another log into the virtual merchant terminal to check its status, another “password expired” message. Ah hah! Maybe I can set it back to what it used to be. No dice. It remembers all my old passwords. Every 45 days, I have to make and learn a new password or this website, which is a monumental pain since I only usually look at it about that often. I make another new password, and update my file. More of my time wasted. After 90 days with this processor, I have now had three passwords.
Now, I know how to create an encrypted file. But think about the users. The people using this are not computer experts. They are small businesses. Let’s say Bob at Bob’s Sunglasses has this account. But Bob doesn’t want to spend all day logged into his merchant processor account. Bob has sunglasses to look at! So, he gives the login information to his secretary Susan and tells her to process and fill orders as they come in. After 45 days, Susan gets a warning message one morning about changing her password. After spending an hour on the phone with tech support, she is able to figure out how to change the password.
Then, she does exactly what I did: she writes it down. Only she writes it down on a yellow post-it note along with the user name and account number (“just in case,” she says to herself) and sticks it right on the side of the monitor for everyone to see.
Automatically expiring passwords, from a security perspective, is an extremely bad idea because it encourages unsafe behavior with passwords. While theoretically it sounds like a great idea, it perversely encourages users to write passwords down - the last thing you want them to be doing - and just makes it all the more difficult for them to use your product. A better approach is to encourage or require users to have secure passwords in the first place, and to foster proper care for passwords.
For many, today marks the beginning of the Olympics. All eyes are on Beijing. But, 08/08/2008 also has some significance that many, unless they are web application developers, may miss.
Today is the official End Of Life for PHP 4.
I’ve written before about my curiosity as to whether or not the period we are living in will be well documented. So much of our lives are digital these days, and so much information has already been lost. I can look back at my own digital history and see how much information of mine has disappeared.
I have this big box of floppies. There are like 200 floppies in this box. Yesterday, on a whim, I picked up a USB to 3.5” drive and started going through some of the old disks in this box. I want to get rid of them because I haven’t looked at them probably in 8 or 9 years. A lot of stuff had already degraded to the point of not being readable - these disks have moved with me many times and have not lived in an environment conducive to data preservation. Many simply refused to mount properly and a lot of what did was often riddled with data errors.
As software engineers (especially ones who work on forward-facing user interfaces), we are taught to think about usability. Many of us are not good at it - including me (though I’m making a conscious effort to get better about it and “think more like a user”). Large companies, on the whole, have mastered this because they can expend huge amounts of money on research and focus groups to study what people want and how they interact with their software. Apple is a master at this. And, this is why the GIMP is terrible to use when compared to Adobe Photoshop. Oh, sure, the program itself is perfectly capable, but the interface was clearly designed by an engineer and not a graphic designer.
The other approach is, of course, to separate the engineers from the UI design people. In a company the size of Apple or Adobe, I’m sure this is probably what they do. But small to midsize companies simply can’t afford to do that and, even if they could, somewhere along the line some engineer has to interface with the front end code.
But thinking about the “user experience” is not just related to programming - any industry that has to deal with people who are not native or fluent with that industry can benefit from trying to “think more like them.”
The hotel I’m staying in for OSCON here in Portland, the Doubletree, is a good example of this. When you exit the elevator on the fifth floor, there is the standard sign that rooms 500-520 are to the right, and 521-541 are to the left. The room numbers are not on the doors - they are on small plaques next to each door. But, the plaques don’t uniformally face the hallway or face in a uniform direction - some face the way you are walking from the elevator and some, strangely, face the opposite direction so that they will never be seen unless someone is walking from the opposite direction as they would normally walk when looking for a room.
Think about this for just a second. The time when those plaques are needed the most is when someone is first finding their room, and they will almost always be coming from the elevator. After that, you usually remember, generally, where it is. In order to see half of the signs on the floor, you have to turn around and look behind you as you are walking.
To add to this, think about how you would normally look for a room in a hotel. Do you go all the way to the end of the hallway? No - you probably stop about 10-15 feet from the end if you determine that your room is not one of the remaining ones. So unless you are paying careful attention to the plaques on the wall, there is a chance that you will not ever see your room. This is the reason I spent ten minutes walking up and down the hall trying to find my room: it was at the very end of the hall with a plaque that was only visible if you were walking the opposite direction.
Now, it’s not like this breaks my entire world. I found my room, put my stuff down, and went out for a beer. But when looked at through the lens of usability, which software engineers are very familiar with, it could certainly use improvement. I’m sure the design makes perfect sense to the building architect and to all the people who work in the hotel. But to a guest, it makes little sense and requires extra time spent looking for their room.
By now, I’m sure we all know about search engine friendly (SEF) URLs - that is, URLs that are able to be traversed by a search spider. Spiders don’t like to see a bunch of stuff on the query string (file.html?blah=foo), but do like standard URL patterns like /file/foo.html. Not to mention that it’s a lot easier to read. But what happens when you need to do something more complicated - say, rewrite using different types of conditions with optional arguments?
Say, for instance, I have a script that takes arguments like this:
/file.php?id=1[&view=1]And I want to rewrite it to look like this
/file/(id).html[&view=1]In this case, the view argument is optional and could relate to any number of unique cases, such as internal viewing or refcode tracking, for instance. Well, your first thought might be something like this:
RewriteCond %{REQUEST_URI} ^\file\/\d+\.html [OR]
RewriteCond %{REQUEST_URI} ^\/file\/\d+\.html(.*)
RewriteRule ^\/file\/(\d+)\.html(.*) /file.php?id=$1&$2 [L]`But it doesn’t work. This is because the query string isn’t part of the URI available for the rule to match. But, mod_rewrite, being the cool Swiss Army knife it is, lets you get around this by back referencing to the condition. Using the % operator instead of the $ allows you to reference parentesized expressions in the condition, like so:
RewriteCond %{REQUEST_URI} ^\/file\/\d+\.html
RewriteCond %{QUERY_STRING} (.+)
RewriteRule ^\/file\/(\d+)\.html?(.*) /file/file.php?id=$1&%1 [L]
RewriteCond %{REQUEST_URI} ^\/file\/\d+\.html
RewriteRule ^\/file\/(\d+)\.html /file/file.php?id=$1 [L]`It’s described here in the docs. I thought this was a pretty cool solution to a problem that had been vexing me.
I ran into a situation today where I needed to diff files on a remote server against the ones on a local server when the only connection method I had to connect to the remote server was FTP. I wrote a little quick and dirty script to diff files over FTP. It’s stupid simple - it downloads the file and runs diff on it against a local file, outputting the result.
It’s great for finding changes on a webhost that cripples real developers by only offering FTP. It’s also a great companion to ftpsync, which apes some of the functionality of rsync, again on crippled webhosts.
The command format is:
ftpdiff <local file> <username:password@host:/path/to/file>Shared hosts are a reality for many small businesses or businesses that aren’t oriented around moving massive amounts of data. This is a given - we can’t all afford racks full of dedicated servers. With that in mind, I would urge people to be more careful about what they do on shared hosting accounts. You should assume that anything you do is being watched.
Take, for example, the /tmp directory. I was doing some work for a friend this weekend whose account is housed on the servers of a certain very large hosting company. While tweaking some of his scripts, I noticed via phpinfo() that sessions were file-based and were being stored in /tmp. This made me curious as to whether any of that session data could possibly be available for public viewing.
My first move was to simply try FTP’ing up and CD’ing to /tmp directory. No go - they have the FTP accounts chrooted into a jail, so the obvious door is closed. However, the accounts have PHP installed, so I can do something like this in a PHP script:
<?php
system("ls -al /tmp");
?>With this little bit of code, I can look into the tmp directory even if my FTP login is chrooted. Fortunately, sessions on this host are 600, so they’re not publically readable - this was my primary concern and the reason I took some time to check this out. But people are putting lots of things into the tmp directory with the misguided idea that it is their private temporary file dump, including one idiot who put a month’s worth of PayPal transaction data into tmp and left it 644 so that it was publically viewable.
Now, I’m a nice guy and the only thing I’m going to do with this information is laugh at it. But keeping in mind how dirt cheap hosting accounts are, there’s not a high entry barrier for someone with fewer scruples.
The key thing to remember is that, if you need temporary file storage on a shared host, do it someplace less obvious, set the permissions so that only you can read/write to it (600), and clean up by deleting files as soon as you possibly can.
My Facebook news feed hasn’t update since May 15th - a span of four days, in which I know many of my friends have posted or at the very least updated their status.
With 50-something friends, I know for sure some of my friends are updating - my feed just isn’t reflecting it. So, after Googling about (Facebook’s site, for the record, is extremely unclear about contacting the company and/or reporting bugs), I found this:
Great! A place to file a report. So I type in my report and submit …
D’oh. Apparently, I’m not the only one having this issue, either. C’mon guys, get it together! At least let us users know what’s going on.
The PHP that comes standard with Mac OS X Leopard doesn’t come with the PECL PS extension. PECL PS requires pslib, and the last version I verified to work the PS extension was 0.2.6 (I still have an outstanding bug for that). There’s a minor little bug that prevents it from compiling on OS X, so here are the steps necessary to get PECL PS working on Leopard:
Download PSLib 0.2.6. Unpack to somewhere on your filesystem (I use /usr/src)
cd pslib-0.2.6/src
Apply this patch to pslib.c (patch pslib.c leopard_pslib-0.2.6.patch)
cd ../
./configure
make
make install
By default this puts it in /usr/local/lib. Now install the PS extension using PECL.
pecl install ps
When it asks for path to pslib installation, /usr/local/lib
Once it’s done compiling, add the .so to your php.ini. You may have to move the .so or alter extension_dir in your php.ini.
sudo apachectl restart