We all know about Firebug, probably the best developer add-on out there, and how awesome it is and how many times it helped us debug some nasty Javascript code, mess around with CSS and HTML on-the-fly, to track the time load of every external page element our app loads… It’s so cool that it even has it’s own add-ons! (FirePHP, YSlow and FireCookie). Really, it helps our developer lives to suck a bit less.

Note: the following text is not about bashing other developers and their works, but to highlight the importance of proper input filtering. I myself have failed on this, several times.

Let’s go back to the part where we mess with the HTML by the means of this, may I say, application. You can add, hide, remove HTML elements, add, alter, remove, attributes from HTML elements… Adding, hiding, deleting - boring; altering - fun! I have this urge to try to break every form on every website I find. Not to do any harm, just to take a look how my fellow developer did his job and if I see anything that’s not right, I try to contact him to fix that, cause, y’know, I’m a nice person… Anyhow, I recently found some sites where all the textfields and textareas were filtered properly and no harm could be done - all my “hack” attempts were caught by their application. Nice. Oh, look, a select box! Right-click, inspect element, value=”xyz”, change that to value=”abc”, submit the form… and poof! A sexy SQL error. All that with the help of our li’l friend, Firebug. The elements where the user is required to provide some information “by hand” were processed correctly, but the select box was not.

OK, let’s take this one step further. On a site where the user can register an account and afterwards can edit his or hers profile. I register, go to the user panel, the usual stuff - change email, password, location, DoB (Date of Birth)… A quick inspection of the source - a hidden field “id” with a number in it. Hmm… Quickly, I register another account, note the “id” on that second account, go back to the first account, change the “id” of the first account to the “id” of the second account, change the DoB (just to see any actual information changing), click submit… “Your profile has been updated successfully.” Mine? Not really, the DoB is like it was in the first place… Go to the second account… Oh boy. I successfully changed the DoB of the second account, with my first account. Now, I haven’t seen their source code, but I can imagine what was going on. Something like this:

$id = (int)$_POST['id'];
$dob = $_POST['dob'];

$sql = "UPDATE users SET dob = '" . $dob . "' WHERE id = " . $id;

On the positive side, when I entered letters in that hidden field, I was told by the app that I haven’t filled all the fields correctly, which means they filtered even the hidden field, but skipped to check if that “id” is actually me.

OK, I know, the title is “Bad Firebug!” and the problems are actually about filtering user input, but I needed a catchy title to have your attention on Twitter :P

Even tho a field seems “unchangeable”, with a help of an awesome little app, it becomes changeable. And dangerous.

Filter input, escape output :)

P.S.: On the image above you can see my profile on a bulletin board, where I changed my year of birth from 1986 to 986 with Firebug. The years are in a select box; the lowest value is 1910. You can see my actual profile here.

On a forum, there was a question today, about adding language “support” to the routes using Zend Framework. The guy wanted routes like /en/foo/bar or /de/baz. I wrote there an example for that using Zend_Router_Routes_Chain, so just posting that example here, too :)

For what chains are for, is described in the manual, so I won’t be covering that :P

Basically, we’re prepending the language route to the other routes. This way, we have defined the route for the languages in one place only, plus, the other routes don’t have to worry about the language, too.

// this goes in the bootstrap class
public function _initRoutes()
{
    $this->bootstrap('FrontController');
    $this->_frontController = $this->getResource('FrontController');
    $router = $this->_frontController->getRouter();

    $langRoute = new Zend_Controller_Router_Route(
        ':lang/',
        array(
            'lang' => 'en'
        )
    );
    $contactRoute = new Zend_Controller_Router_Route_Static(
        'contact',
        array('controller'=>'index', 'action'=>'contact')
    );
    $defaultRoute = new Zend_Controller_Router_Route(
        ':controller/:action',
        array(
            'module'=>'default',
            'controller'=>'index',
            'action'=>'index'
        )
    );

    $contactRoute = $langRoute->chain($contactRoute);
    $defaultRoute = $langRoute->chain($defaultRoute);

    $router->addRoute('langRoute', $langRoute);
    $router->addRoute('defaultRoute', $defaultRoute);
    $router->addRoute('contactRoute', $contactRoute);
}

Assuming that we have an Index controller, with actions index and contact and a Foo controller with actions index and bar, paired with the routes from the above example, we could do requests like:

/ => /index/index/lang/en
/de => /index/index/lang/de
/sr/contact => /index/contact/lang/sr
/en/foo => /foo/index/lang/en
/fr/foo/bar => /foo/bar/lang/fr

Requesting a page like, e.g. /de/baz, would give us a 404 page, cause we don’t have a Baz controller.

HTH :)

Happy hacking!

O hai. First things first — someone should slap me for being such a lazy blogger. Somehow I lost all the motivation I had in the beginning, but looks like it’s back now :) I finally had the time to play around with the latest Zend Framework version (v 1.9 now). I managed to skip the whole 1.8.x version, so this whole Zend_Application stuff is quite new to me. I spent a few days poking around the manual and the code to make it work. And it works! Yey for me! And yey for Rob Allen for his post on Bootstrapping modules in ZF 1.8!

Zend_Tool is an awesome tool. Creating a new project is like “zf create project project_name” :) And the new bootstrapping process with the Bootstrap class is somehow much clearer to me now… Anyways, lets skip to the code.

The goal

I wanted to set up routes in such way that when a user requests a page, all requests for non-existing controllers/modules are directed to a specific controller (not the error controller). In other words, if we have controllers IndexController, FooController and PageController, anything but http://example.com/index and http://example.com/foo is directed to the PageController. This can be useful for CMSs or blogs to make pretty links. Here’s where the Zend_Controller_Router_Route_Regex stuff comes in:

$route = new Zend_Controller_Router_Route_Regex(
    '(?(?=^index$|^foo$)|([a-z0-9-_.]+))',
    array(
        'controller' => 'page',
        'action' => 'view',
        'slug' => null
    ),
    array(
        1 => 'slug',
    ),
    '%s'
    );

$router->addRoute('viewPage', $route);

Basically the regex does the following: if it’s index or foo don’t match anything, thus calling up those controllers, in any other case match what’s requested and pass it to the PageController’s viewAction as the slug parameter. The fourth parameter, the ‘%s’, is needed so that ZF can rebuild the route in components like the Zend_Navigation.

Now, when the PageController, viewAction get’s called up, we can check, for example, if a page with that slug exists (like, in a database). If it exists, show the content, otherwise call up a 404 page with the error controller. In this fancy and sexy way we can call up pages without passing ID’s or even letting the user know what part of the website is working on his request. He just request’s http://example.com/some_random_article and kaboom! he get’s the content :)

Page navigation

Oh the joy when I saw Zend_Navigation in the library! And it even includes view helpers to help us render links and menus and breadcrumbs! Yey! There are a several blog posts which go in details about Zend_Navigation, so I won’t be bothering with that. What I wanted to make with Zend_Navigation is to have a menu of all the pages rendered everywhere. Here’s where action helpers kick in. I made an action helper which makes up the structure of the links/pages. Something like this:

<?php
class Zend_Controller_Action_Helper_LinkStructure extends
        Zend_Controller_Action_Helper_Abstract{
function direct(){
$structure = array(
    array(
         'label'=>'Home page',
         'uri'=>'/'
    ),
    array(
         'label'=>'Articles',
         'uri'=>'',
         'pages'=>array(array(
                                  'label'=>'Article 1',
                                  'uri'=>'article_1'),
                              array(
                                  'label'=>'Article 2',
                                  'uri'=>'article_2'),
                         )
    )
);
return new Zend_Navigation($structure);
}
}

This is a simple example of the structure; I’m actually making it out from the database, with all the categories, subcategories and pages.

Links everywhere

To have this menu on all pages, we need to render it in the layout.phtml. Rendering is quite simple:

// somewhere in layout.phtml
<?php echo $this->navigation()->menu(); ?>

Of course, we need to pass the menu to the navigation helper somehow. To avoid doing $this->navigation($this->_helper->linkStructure()); in all the controllers, we could do that once in the bootstrap (any other ways to make it happen?):

// in Bootstrap.php somewhere in the Bootstrap class
function _initView(){

        $view = new Zend_View();
        $view->doctype('XHTML1_STRICT');
        $view->headMeta()->appendHttpEquiv('Content-Type', 'text/html; charset=UTF-8');

        // our helper is in app/controllers/helpers folder, but ZF doesn't know that, so tell him
        Zend_Controller_Action_HelperBroker::addPath(APPLICATION_PATH.'/controllers/helpers');
        // now get the helper
        $linkStructure = Zend_Controller_Action_HelperBroker::getStaticHelper('LinkStructure');
        // and assign it to the navigation helper
        $view->navigation($linkStructure->direct());

        $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
        $viewRenderer->setView($view);

        return $view;
}

There. Now we have our menu rendered on all pages. Sexy isn’t it? :)

That’s it for now. Hope someone will find this useful :) Now I gotta go, need to get ready for a punk rock concert tonight!

Happy hacking!

Wordpress is one of the best blogging platforms out there — if not the best. It’s very powerful, can be easily extended and modified. It’s documentation is very well written and, so far, had answer to all of my crazy questions :)

You know what’s the best part of Wordpress? With some knowledge of PHP and MySql, you can turn it into much more than just a blogging platform. After doing some HTML to WP work for Roger, I thought of one way how could Wordpress be transformed into a CMS. Note the “one way”. This is not the only way for doing this, and, most likely, not the best way.

I didn’t look much, but I think that there are some nice plugins out there that can do this. But, where’s the fun in the download, upload, activate process? Nowhere!

I will show you how to change your Wordpress into a CMS and it really doesn’t take much coding to achieve this! The example presented here is simple and will have a static page for it’s home page, another static page for the “Portfolio” page and the blog. The home and portfolio page will have some of own content and both will include some content from other static pages. You all most likely know the blog part ;)

Static pages

Things you should know: each static page has it’s title, it’s slug or name (the thing that shows up in your browsers address bar: http://example.com/portfolio/ - right there, the portfolio is the slug!), has the parent attribute and the template attribute. The parent attribute is used when it’s needed to make one page a child of another, i.e. to show Page2 as a subpage of Page1. The template attribute is used when we want to apply some different layout and styling to a static page. Read more about static pages and how to create your own page templates.

Continue reading this post…

Today I was messing around with Trac, installing it and doing some basic configuration. While my dev machine gets updated, I want to share my process of installing Trac.

What is Trac?

As said on the Trac homepage:

Trac is an enhanced wiki and issue tracking system for software development projects.

It’s free, it’s open source, it comes under the BSD license and it’s really awesome. You can write a wiki with it, have a ticket system, connect it with SVN, so you can browse the sources from the browser and see all the commit messages, when was something changed, added… It can support one project, it can support multiple projects. It can be viewable/editable by anyone, or you can close it down for your little team…

Trac is big. It has lots of plug-ins, so you can extend and customize your Trac. I haven’t played with them yet, but as soon as I will, you’ll get notified ;)

It’s written in Python. It can run on it’s own server, or it can run under Apache (where there are also several options). It can use SQlite, PostrgeSQL or MySQL databases. Currently it can connect only to SVN.

I’ll show you how to setup a basic Trac 0.11-dot-something-dot-something. It will run under Apache with mod_wsgi, use a SQlite database, connect to the SVN repository and require user authentication.

Continue reading this post…