PHP
Archived posts from this Category
How smart is Smarty?
Posted by admin on 18 Feb 2009 | Tagged as: PHP, Web Design & Development
I started using the smarty template engine today for one of the applications that I develop at work. The application previously used a home-made templating system that was much more primitive in comparison. It was basically a string replacement engine.
I had started reading the documentation on the Smarty website a few days ago, and I must say, I am impressed with what this so-called “template engine” can do.
I quote template engine because on the offset, that’s what Smarty appears to be. But upon further investigation it becomes apparent that Smarty is much more than this.
This ability to have conditionals and language constructs purely in the presentation layer means that one can use PHP to obtain and sort the required data, into arrays if necessary and then pass on the raw data to the template which can then decide what to do with it, or how to display it. This is the limitation of more simple string replacement templating systems.
Although I am still new to the Smarty way of doing things, the more i discover about Smarty, such as it’s built-in language file support, and auto-generation of HTML select/option tags given an associative array the more I like it.
Only time will tell if it can cut the mustard though, once it’s been implemented on the whole application and tested. But from what I’ve read, it’s up to the job.
A really simple introduction to templating using PHP
Posted by admin on 01 Nov 2008 | Tagged as: PHP, Web Design & Development
When developers talk about application development they often spout things like
“When developing an application it is beneficial to separate business logic from the presentation logic”
Which all sounds very technical and intellectual, but what are they going on about when they say things like this?
Imagine a simple website. Three pages liked together by hypertext links. Each of the pages contain text and images hard coded as HTML and the files have a .html extension. There’s no processing behind the scenes, no PHP/ASP or Java, the pages content never changes. These are called static pages. It would be fair to say that this website is almost completely made up of presentation logic. Logic, or code concerned with display and not processing any information.
Now, imagine a PHP scrpt that a form on this website posts it’s information to when someone clicks the submit button. Let’s call it ‘process_form.php’, and lets say this form takes the information posted to it, checks the information is usable, and then redirects you to another page depending on what you entered in the form. This processing of information would be an example of business logic.
Often In web applications, business logic and presentation logic, along with CRUD (database logic) are often fused into single scripts. Such as having a single PHP script that does some processing and outputs the result in HTML format. Though often useful, this can become problematic and cumbersome if you wanted to change the way your web page looked without changing the way it does any processing.
Along comes templating…
Templates allow you to seperate your static content from your processing. This way, you could easily change your static content without worrying about the processing code getting in the way and vice versa.
A simple HTML file could look like this:
<html>
<head>
<title>Title Text</title>
</head>
<body>
This is the content
</body>
</html>
<head>
<title>Title Text</title>
</head>
<body>
This is the content
</body>
</html>
If we wanted to output PHP in this file we could do something like this:
<html>
<head>
<title>Title Text</title>
</head>
<body>
<?php echo ‘This is the content’ ?>
</body>
</html>
<head>
<title>Title Text</title>
</head>
<body>
<?php echo ‘This is the content’ ?>
</body>
</html>
This would be an example of single-tier, or fused logic. Which makes it difficult to just change our HTML because the HTML and PHP are intertwined in a single layer. Say we created a template file of our original HTML file that looked like this and gave it the extension .tpl
<html>
<head>
<title>{TITLE}</title>
</head>
<body>
{CONTENT}
</body>
</html>
<head>
<title>{TITLE}</title>
</head>
<body>
{CONTENT}
</body>
</html>
In this example we have replaced the content withcontent placeholders that we can reference later on.
Now, we can produce a simple PHP function that will replace the placeholders with our content after our PHP business logic layer has finished with it. The function may look something like this:
function render($array,$template){
$template = file_get_contents($template);
foreach ($array as $key=>$value){
$template = str_replace(’{’.strtoupper($key).’}',$value,$template);
}
echo $template;
}
This way, from our PHP business logic layer, we can easily produce our presentation layer with any data we like without having to alter the template in any way. An example of calling our template from the business logic layer would be something like this:
render(array(’title’=>’The Page Title’,'content’=>’This is the page content’),’template.tpl’);
Haunted by register_globals security issues
Posted by admin on 09 Oct 2008 | Tagged as: PHP
Yesterday I went to an interview for a new job. As with many programming/developer jobs after a bit of a chat the interviewer and a lead developer gave me a small test on my PHP knowledge.
I was given 3 pieces of paper with some PHP code on them that was intentionally erroneous and given 15 minutes to mark all the errors on them.
Hindsight is a beautiful thing I suppose. After leaving the interview something came to mind that i didnt notice straight away.
The code was using something like this:
// define $loginstatus = true only if user is authenticated
if (login_user()) {
$loginstatus = true;
}
if (login_user()) {
$loginstatus = true;
}
Because we didn’t first initialize the $loginstatus variable as false using:
$loginstatus = false;
the variable might be defined through using the register_globals setting instead, such as from a GET URL query string from a posted form, e.g.
auth.php?loginstatus=1
So, anyone can be seen as authenticated when testing like this!
if ($loginstatus) {
// show logged in stuff
}
// show logged in stuff
}
Oh boy! how dangerous could that be! Even though register_globals had been turned off since PHP 4.2.6 as default, it sould not be taken for granted as when it is turned on can be a security loophole, which is why it’s scheduled for removal.
I cant believe I missed it at the time (although it did come to me afterwards) It’s that easy to create a potentially unsecure application.
As of PHP 6 though this can no longer happen, as the register_globals PHP setting is being removed comletely. Good.
