Header graphic 3 of 8



Other stuff

Other sites

I wish this site were powered by Django

October 26th, 2010

Running Z-Push 1.4.2 with Apache and FastCGI/fcgid

Filed under: Mobile,PHP,Technology — jm @ 20:49

I spent half a night yesterday installing Z-Push, an open-source Microsoft Exchange ActiveSync push protocol implementation, which is written in PHP. Z-Push supports multiple back-ends from which it can push data to your mobile device, including maildirs, IMAP and vCard folders. Multiple other open-source groupware projects (like Horde.org) have produced their own back-ends.

I'm using my iPhone with my own mail system with a secure IMAP server and CalDav, based on Sun's Oracle Communications Calendar Server. I want the ability to remotely wipe my phone, though.

Z-Push itself only supports the "remote wipe"-command through Zarafa's administration console. However, there is a project called iRemoteWipe that provides a Z-Push back-end that checks with a LDAP database which remote devices are to be wiped. There's a good how-to on AFP548.com that shows how to make this back-end work with a SQLite database.

I will not cover the whole process of unpacking and configuring Z-Push, as it's easily done and well documented, but I want to describe the few bumps that I've hit along the way.

The thing that left me stumped is that I'm running PHP through mod_fcgid on a Apache 2.2 server with the worker MPM. The Z-Push installation instructions however, only cover the installation with mod_php. When I tried to access the "Microsoft-Server-ActiveSync"-URL on my server, I always got the error message "No input file specified". This first error was easily fixed. Z-Push uses a Alias directive to map its index.php-file to the ActiveSync-URL. I had issues with this before, so I knew that somehow Apache will not use pass the right URL to the fcgid-script handler. I just rewrote it using mod_rewrite to:

RewriteEngine On
RewriteRule ^/Microsoft-Server-ActiveSync \
        /z-push/index.php [PT,L,QSA]

Now however, Z-Push complained that it didn't get any authentication headers. While the documentation was right in that, when I accessed the URL using a browser, I got an authentication dialog... I still couldn't authenticate. It took hours before I remembered that using Apache with mod_php passes some HTTP headers using non-standard names. "Authorization" becomes "HTTP_AUTHORIZATION" for example. Armed with that knowledge and extensive googling, I finally found this forum post, which solved the remaining problem, as Z-Push assumes running under mod_php at the moment.

So the final configuration reads:

# Enable ActiveSync (Z-Push)
RewriteEngine On
RewriteRule .* - [E=HTTP_X_MS_POLICYKEY: \
RewriteRule .* - [E=HTTP_AUTHORIZATION:\
RewriteRule /Microsoft-Server-ActiveSync \
        /z-push/index.php [PT,L,QSA]

I hope this helps someone else out there :-).

July 21st, 2008

PHP gains closures

Filed under: PHP,Technology — jm @ 13:23

This PHP RFC contains a proposal for closures, lambda functions and callables in PHP. Looking at the rest of PHP, the syntax seems to be in the same style, with a new reserved word "use".

The RFC has been accepted and the code is in PHP's trunk. Well, it was about time, right?

Of course, PHP will still helpfully truncate your 64-bit database id columns by converting them into floating point numbers, if you're using a PHP version compiled on a 32-bit system, but of course not on a 64-bit system, because it wouldn't be PHP if it behaved the same on two random computers. But now you will be able to do that with real up-to-date, all-the-hype scripting language style in PHP 6.0 ;-).

February 23rd, 2008

WordPress Plug-ins available

Filed under: General,PHP,Technology — jm @ 00:48

I packed up some of the code that I wrote to customize my site. It can be downloaded on my plug-ins page. The first two plug-ins available are:

  • maurusnet_geoip_amazon

    A plug-in that helps to embed Amazon partner links into your site by using MaxMind's GeoIP database to find the right Amazon site (country-wise) for your user.

  • maurusnet_archive_widget

    A plug-in that makes WordPress' default "Archives" sidebar widget more accessible by putting it in a <form>-tag and making it work if JavaScript is disabled. You can see this plug-in in action right next to this post under "Archives"

I hope you find these helpful. If you use them, feel free to drop me a line, or a comment on the plug-in's page. I'd appreciate it.

Also, don't forget that the sourcecode of my bookmark search engine is also available on its help page

February 22nd, 2008

PHP sucks… now even more.

Filed under: General,Java,PHP,Python,Technology — jm @ 01:52

I finally made the time to update I'm sorry, but PHP sucks. This part of my site gets by far the most traffic and I found it important to update it to reflect all the changes that have occurred since I originally wrote it in 2006. I also created a new sub-section on programming languages where I'll write down trivia about Java and Python and other programming languages that I use daily, concentrating on weaknesses and bugs that are less-known, but can become highly volatile for a project.

Of course, I don't have nearly as much material on Java and Python like I had on PHP, but you never know, perhaps I'll even receive a few suggestions :-).

February 12th, 2008

Content optimization

Filed under: PHP,Technology,Web — jm @ 19:07

Experimenting with YSlow, a FireBug plug-in for Firefox, has proven very productive. I've said it before: FireBug in combination with the Web Developer Toolbar and Jesse's Bookmarklets makes Firefox the best web development environment around.

So I spent an hour today improving maurus.net's YSlow rating. In detail, I added general output compression support by enabling zlib.output_compression in my php.ini and adding a deflate filter for JavaScript and CSS files. I also added "Expires"-headers to images, CSS files and JavaScript files. These optimizations alone, together with disabling ETags, as recommended by the YSlow FAQ, made a huge difference in this site's loading speed. Last but not least, YSlow pointed out some redundant <script> tags on the front-page.

Here's the Apache configuration I used:

FileETag none
ExpiresActive On
# images and css expire after two weeks
ExpiresByType image/gif A1296000
ExpiresByType image/jpeg A1296000
ExpiresByType text/css A1296000
AddType text/javascript .js
ExpiresByType text/javascript A1296000

AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/css

While I did all this, I also had to solve the problem that updating files for my weblog wouldn't be as simple anymore, because users would visit my site with old stylesheets and JavaScripts for two weeks when I updated my site. I decided to do the following:

  • JavaScript libraries like YUI now live in versioned directories like /yui-2.4.1/.

  • All CSS files and JavaScript files that belong to my site get a query-parameter appended to their URL that is equal to their last modification date. Thus, as soon as the file changes, its URL changes, too. Here's an example of how I load a CSS file in my header.php:

    @import url(realstyle.css.php<?php 
    echo '?ts=' . 
      filectime(TEMPLATEPATH . '/realstyle.css.php')); 

    The resulting URL looks like this:

    @import url(realstyle.css.php?ts=20080212171452);

In summary, with a primed cache, this site will now load a lot faster than before, but if I change anything the changes will still be reflected the moment I make them. The only caveat is that I can't change images on the fly without changing their filenames, but that doesn't bother me much because I never did that anyway.

February 06th, 2008

Yay, shipping software rocks

Filed under: General,PHP,Python,Technology — jm @ 02:02

I always like that feeling when you're getting something out the door, even if it's just a small update to your own site. So check out the new front page. Having just 5 recent links from del.icio.us which additionally required you to allow JavaScript from a different domain always bugged me. This has finally changed.

You can read about the cute little webservice that powers the new front page here. Like most software I write right now, it's written in Python.

Aside from that I refactored a few small bits of the theme

  • The magnifying glass in the header has a darker background to make it more prominent

  • The included copy of Yahoo! UI is now 2.4.1

  • I whipped up a plug-in to modify WordPress' included "Archive" widget so that it's more accessible when it's in select-box form (it lives in a form now and has a "Go"-button)

  • Subsequently I switched off the long monthly archive list in the weblog's sidebar. I wanted to do this to make room for future enhancements.

The beautiful part of it is that I had a good excuse to do all this because I needed to acquaint myself with different autocomplete widgets. Now back to doing real work...

November 11th, 2006

WordPress 2.0.5

Filed under: PHP,Technology — jm @ 23:23

This PHP bug (#36705) broke the recent WordPress upgrade to 2.0.5 for some people (running fastcgi). There’s a WordPress plug-in by one of WP’s authors that fixes the issue. Unfortunately, there isn’t an easy fix that fixes the problem for all people. If you want to know why, you need to read the discussion of the braindead bug.

It’s one more reason why building maintainable systems in PHP is really, really hard. From the bug’s discussion it seems that PHP’s documented behavior changed silently between versions. It’s not strictly a PHP-only problem, though, as you could also blame fastcgi for its behavior, but changing your API, keeping wrong documentation is exactly what I’ve come to expect from PHP. At least I’ll make sure to check if there’s a similar problem with Python running under fastcgi.

November 07th, 2006

PHP has a UTF-8-related security vulnerability in htmlspecialchars() and htmlentities()

Filed under: PHP,Technology — jm @ 03:19

Fucking beautiful :-/. All versions <=4.4.0 and 5.2.0 are vulnerable.

Advisory: PHP HTML Entity Encoder Heap Overflow Vulnerability

July 28th, 2006

Typo3, PHP, MySQL connections and Unicode

Filed under: Attitude,Cutting the crap,PHP,Technology — jm @ 15:30

I have said it before and now I have to say it again.

Over the last three months I've spent a ridiculous amount of time on a Typo3 project for the Chair for Business Engineering at the University of Regensburg. We built a full-featured DMS based on Subversion, Typo3's DAM and WebSVN. We got hit by PHP's miserable Unicode support so hard, it isn't even funny anymore.

I always assumed that using Unicode strings with PHP can derail a project badly as soon as you run into one of the thousand's of possible problem scenarios, but now that it happened to me, I can prove it. What happened was that while Subversion, interestingly, fully supports UTF8-encoded log messages and URLs, it also gives an error and exits if it detects encoding errors. So on multiple occasions, when we built a log message in a PHP script by concatenating 2 Strings like $str = $strFromWebBrowser . $strFromPHP; we'd end up with an error message, because $strFromWebBrowser was UTF8-encoded by the browser, but $strFromPHP was not. We were able to fix this by enforcing internal UTF8 encoding using PHP's mbstring extension and limiting ourselves to the few string functions that mbstring does overload.

The second and really hard to debug problem that hit us was that Typo3 4.0 (Typo3's total crappiness is a topic for another post) still opens database connections using PHP's old mysql library. This means that if you want to work with MySQL 4.1 or better, you don't get support for all the fancy new binary protocol features, like the client character set support in the connection packet header. So now you have a database that's fully UTF8-encoded in MySQL 5.0, but every connection that Typo3 opens in its central database class class.t3lib_db.php has character_set_client set to "latin1". This means that if PHP sends UTF8 data across this database connection, the string is double-encoded. This also happens when Typo3's "force_utf8" option is set. It took a long night with hexdump and this ISO8859-1 to UTF8-table to figure this out and we fixed it literally in the last minute.

You might think that enforcing a client character set using MySQL's init-conn configuration option could solve the problem, but unfortunately MySQL seems to ignore this setting in the current release. So the only option was to patch Typo3's database code, inserting these two lines into the code:

@mysql_query('SET NAMES utf8',$this->link); @mysql_query('SET CHARACTER SET utf8',$this->link);

I still think that PHP's new mysqli library is crap, too, because the parameter binding is as bad as Java's (no named parameter support) and the resultset handling just sucks, but at least it fixes most SQL-injection attacks by supporting prepared statements. That Typo3 is still tied to MySQL as a database is just sad, but I can't decide what they should fix first, the ugly admin interface or their database code. I tend to the latter as you can't install Typo3's DAM extensions if you install their database abstraction layer (that nobody uses anyway), which is an undocumented dependancy, by the way, that hit us during the first few weeks of development.

So there you have it: please please please don't use PHP for a project if you have any other choice.