June 2011 Posts

Because there doesn’t seem to be a good, simple way to track oil prices on the Mac dashboard anymore since the previous widget I used quit working, I whipped up a quick little widget that allows me to monitor the price of Crude Oil on the New York Mercantile Exchange. You can download it over on its own page.

PHP’s filter functions are really, really great. I’ve started using them almost any time I need to get input from a user and, personally, I don’t think you should use the old $_GET, $_POST unless you know what you are doing and there is some specific thing you’re trying to accomplish that you can’t with filter. Filter forces you to think carefully about what inputs your script takes and what format it takes them in. But there are also some behaviors of filter that can bite you in the rear if you aren’t really careful. One of these is knowing which flags you need to pass and what the difference between validation and sanitizing, when is the right time to  use each, and what flags to use. I ran into a good example of this today where I messed it up. I had configured filter_input_array to pull in a variable as FILTER_VALIDATE_FLOAT, probably because I wasn’t thinking like a user and instead was thinking like a developer. I’m the type of person that, when a form wants to know my phone number, I only enter 10 digits without parentheses or dashes. But users are different. They like friendly things. In this case, the user was entering “16,473.54” and the like into that box. Now, I can look at that and say, “yeah, that’s a float” (actually, it’s currency). It should be considered a valid value. But FILTER_VALIDATE_FLOAT will throw this out because it has a comma in it, unless you pass FILTER_FLAG_ALLOW_THOUSAND. Then, and only then, does it return the above as a valid value (in this case “16473.54”). But I looked at the code again. In this case, the value doesn’t need to be there except in a specific case, which I handled in error checking in the code, so I switched it to a Sanitize value instead. It’s probably a good idea to only use  FILTER_VALIDATE_* functions when your user has to give you a valid value and your script would fail if that wasn’t the case. If a validation returns false, you should fail the process and return a (nice) error message to the user. Sanitize functions allow you to accept a little wider range of data and still return a valid value from it. The docs have a great example of this involving email addresses. So if you’re writing PHP these days, definitely use filter. Just be careful and mind the flags and the difference between validation and sanitizing.

I’ve finally put together a website for dystill: www.dystill.org I’ll continue to post updates about this project here, though. I’ve also finished working on a plugin for Roundcube (the popular open-source webmail client). It can be found for download at the address above.

Version (do those really matter anymore? :P) 0.2 of dystill has been released. This version brings a significant change to dystill. Namely, it breaks the unofficial association between dystill and Postfix that has existed since I first wrote it last year. I did this for a couple of reasons: To hopefully increase adoption. Dystill now (really!) stands independent of any MTA. Use it with whatever you want (sendmail, Qmail, etc). You actually always could, but you’d have to ape some Postfix tables. You don’t have to do that anymore. To make it easier to write web-based front-ends to dystill’s MySQL database, enabling users to add rules. This was done by adding an “email” column to the filters table, updating that field with the recipient address, and dropping the old user_id field. Also, a “maildir_path” config variable was added to the config, specifying where the maildirs live. There was also a minor bugfix I came across the other day where certain uncommon (but legal) characters could result in unreadable maildirs.