Maarten Balliauw {blog}

ASP.NET MVC, Microsoft Azure, PHP, web development ...

NAVIGATION - SEARCH

Munin PHP based mod_security

Today, I discovered a nice PHP thing: Munin. This is a PHP version of Apache mod_security, allowing it to be run on IIS too. Munin performs rule based checks on HTTP headers, get and post data, ... The standard rule set disallows some things like path traversal and possible fopen() attacks.

In addition to these rulesets, one should add some more for filtering out SQL injection attacks, cross-site script loading, ... These things should already be covered in your code, but an extra filter at the front door is always nice.

You also get a nice control panel in which you can check rules that have matched and thus might indicate possible misuse of your website. You can also manage rules in this front-end.

PHP WSDL generator

Everyone who has ever created a webservice in PHP, using the PHP5 native functions, NuSOAP, PEAR, ..., certainly has cursed a lot while creating WSDL files for those services. Today, I found a nice helper class, Webservice Helper, which does a lot of tricks for you.

Webservice helper creates the WSDL file for your service, and for related classes. Also, a basic authentication system is included.

One necessary thing in your code is PHPdoc-style documentation. Webservice helper travels that documentation and uses reflection to generate class mappings. But normally, one should always document code.

As I'm a C# fanatic too, I created a simple service using Webservice helper, and tried connecting using C#. It works perfectly! The web service browser in Visual Studio recognizes the WSDL and generated method names, and talking to a PHP webservice feels just the same as talking to a C# webservice. Maybe I should think about enabling some webservices on my blog to allow me to easily post new articles...

Use Zend Framework on IIS

A while ago, I was experimenting with the Zend Framework. At first, I tried running a small sample on top of IIS, but unfortunately, that did not work... On Apache, it worked like a charm. Very nice, but what do you do when your site runs on an IIS machine?

I started experimenting. First of all, I found out that Zend Framework also accepts URL's like http://localhost/index.php/controller/action/ as well as http://localhost/controller/action/. The first one is really handy! The only thing you have to do is to feed index.php the right query string and you're up and running. Changing all your URL's from /x/y to index.php/x/y should do the trick.

But this does not look pretty in my browser. I don't want the index.php in between!

Searching Google, I found some ISAPI filters that provide URL rewriting, but none of them are free. As a Belgian, I don't like spending my money when results are not guaranteed. Luckily, another idea popped up in my mind: let's fool IIS! Everybody using IIS knows that you can customize your 404 (page not found) error page. What about trapping all 404's to a central page, that can dispatch the request to my index.php file? A schematic overview:

I assume  you are familiar with configuring IIS and its error pages. All you have to do is save this file as RewriteController.aspx, and point your 404 error page there.

Now go ahead and try! The RewriteController.aspx changes the internal request in IIS from http://localhost/index/index (default action) to http://localhost/index.php/index/index. The address bar of your browser stays the same thoug. Subsequent requests are all routed this way, which means you can keep using your path's without index.php in between.

Some remarks:

  • If Zend Framework always tries the no route action, try using Zend_Controller_RewriteRouter instead of the default Zend_Controller_Router.
  • RewriteController.aspx can be rewritten in another scripting language too, but ASP.NET provides some nice shorthands to server variables...
  • Routing all errors trough RewriteController.aspx is probably a small performance bottleneck. Not noteworthy, but on high-traffic websites I expect this to slow things down
  • Another best practice on the Zend Framework is to redirect the noRoute to some sort of a 404 page