Using :nth-child from CSS3

As written is a previous posting about PHPUnit I also wrote the time has come to rewrite an application that is now mainly functional to a object oriented model. As doing standardized unit testing becomes easier and not an one project solution. One of the first goals is to separate the presentation layer from the application layer.

To complete this goal the first requirement is to see which browser versions needed to be supported. Based on the numbers from it is safe to say that both Mozilla Firefox and Google Chrome users are following the latest version in majority. For Microsoft Internet Explorer it is a different story as IE8 is the last possible version on Windows XP and the out of the box version for Windows 7. The numbers for IE8 are declining for months now and Microsoft started to push IE10 out to customers. For now I will select IE9 features when implementing Cascading Style Sheets and those features also need to be supported by the previous released version of Firefox and Chrome.

While moving a lot of inline style sheet information into separate file I also found the odd and even row coloring code. This code assigns a different style sheet class to the rows in question, but with CSS level 3 the pseudo-class selector :nth-child exits and this now can be done in the presentation layer and making the application layer lighter. So a style sheet file that defines the correct tr:nth-child(even) and tr:nth-child(odd) pseudo-clases will do the trick.

tbody tr:nth-child(odd) {
    background: rgb(255,255,255);
tbody tr:nth-child(even) {
    background: rgb(245,245,245);

The following HTML-tags are now completely clean and generating the correct colors will be done by the webbrowser. Saving expensive server-side execution time and precious bandwidth both resulting in a quicker response for the user.


As this is the first step to separate the presentation layer form the application layer it is also a step that can take a while due to checking if everything still works and looks correct. The next step maybe even more daunting as it requires the separation of creating HTML-tags and business logic. As it looks now I will be moving everything into a PHP-version of known from Perl.

Starting to stop SQL-injections, part 2

In a previous posting I gave an example on how to make database queries safer by using parameter binding and basically stopping SQL-injections. The next step is to make the code more readable and maintainable. This doesn’t sound a like a priority for secure software development, but readable code is also code that can be verified and maintained by other people. It gives you the edge to debug problems quickly and invites others to supply patches. So let take the example where the previous posting ended.

$sth = $dbh_rw->prepare('select userid from accounts where username = ?');

For one or two parameters this may work, but when queries become bigger you need to start counting and counting beyond three is a bad idea in most cases. So let change the question mark with a named variable called ‘:username’ in this example. One could then use the function bindParam() to specify which named variable needs to be replaced and has additional features, but in this example we use the standard binding during in execute phase.

$sth = $dbh_rw->prepare('select userid from accounts where username = :username');

Please remember to use a named variable only once in a SQL-query as it will only be replaced one time and not multiple times.

Starting to stop SQL-injections

In a lot of PHP-examples strings are concatenated before a database query is being executed as below. Some examples advise to use PHP-functions mysql_real_escape_string() and/or addslashes() to make database query safe against SQL-injections. But this isn’t really a solution as when using addslashes() also requires the use of stripslashes() after retrieving data from a database. Some sites show the lack of a proper implementation and show the famous \’ string in a website.

$sth = $dbh_rw->prepare('select userid from accounts where username = "'.$form_username.'"');

Like in Perl with DBI, also PHP has PDO that allows for variables to be parameterised while executing a query as in the example below. This removes the need for home made solutions that don’t cover all usecases and allows for a way to provide a stable and more secure interface for your applications when communicating with databases.

$sth = $dbh_rw->prepare('select userid from accounts where username = ?');

This doesn’t stop the need of sanitizing variables like as with input from users.

Cleaning input enough?

Input validation is known issue, but writing some PHP-code today let me write the following and I’m wondering if I forgot something. It is only to make sure no cleansed variable will enter a switch statement for example.

  if (isset($_POST['action'])) 
    if (strlen(preg_replace("/[^a-zA-Z0-9-]/i","",$_POST['action'])) == 0)
      $page_action = $_POST['action'];
      $page_action = '';
    $page_action = '';
  switch ($page_action) {

For now I need to check the code that no $_POST variable is entering the code unchecked before I put the code online. This also include variables for SQL-statements to eliminate SQL-injections.

Condensed Perl-code

Bij het opschonen cq herschijven van wat code kwam de volgende regel uit mijn vingers. Deze condensed Perl-code blijkt ook nog redelijk leesbaar te zijn.

do $domains{lc($1)}++ if /postfix\/qmgr.+ from=<.+\@(.+)>,/;

Of het verstandig is moet de toekomst uitwijzen, maar het past nu wel netjes op één regel zonder wrapping. Een ding wat wel langzaam duidelijk wordt is dat Perl een taal is die je door de jaren heen je code anders laat uitschrijven. We zullen zien wat de toekomst brengt, maar ik vrees het ergste 😉