By default, Zend_View expects your view scripts to be relative to
your calling script. For example, if your controller script is at
"/path/to/app/controllers" and it calls
$view->render('someView.php'), Zend_View will look for
"/path/to/app/controllers/someView.php".
Obviously, your view scripts are probably located elsewhere. To
tell Zend_View where it should look for view scripts, use the
setScriptPath() method.
<?php
$view = new Zend_View();
$view->setScriptPath('/path/to/app/views');
Now when you call $view->render('someView.php'), it will look for "/path/to/app/views/someView.php".
In fact, you can "stack" paths using the addScriptPath()
method. As you add paths to the stack, Zend_View will look
at the most-recently-added path for the requested view
script. This allows you override default views with custom
views so that you may create custom "themes" or "skins" for
some views, while leaving others alone.
<?php
$view = new Zend_View();
$view->addScriptPath('/path/to/app/views');
$view->addScriptPath('/path/to/custom/');
// now when you call $view->render('booklist.php'), Zend_View will
// look first for "/path/to/custom/booklist.php", then for
// "/path/to/app/views/booklist.php", and finally in the current
// directory for "booklist.php".
Never use user input to set script paths
Zend_View uses script paths to lookup and render
view scripts. As such, these directories should be known
before-hand, and under your control. Never
set view script paths based on user input, as you can
potentially open yourself up to Local File Inclusion
vulnerability if the specified path includes parent directory
traversals. For example, the following input could trigger the
issue:
<?php
// $_GET['foo'] == '../../../etc'
$view->addScriptPath($_GET['foo']);
$view->render('passwd');
While this example is contrived, it does clearly show the potential issue. If you must rely on user input to set your script path, properly filter the input and check to ensure it exists under paths controlled by your application.