Tag: Zend Framework

Posted on

File uploads with Adobe Flex and Zend AMF

Leonardo França writes; Zend AMF is an implementation done in PHP to work with the communication protocol binary AMF (Action Message Format) and is part of ZendFramework. I had to implement a system to upload files that were a little different than what is typically used in Flash, with this feature had to be integrated into the Zend AMF.
Researching a little on the net, found a solution that was simpler than I thought based on that article with a few adjustments.
Begin with our gateway to be used as endpoint in Adobe Flex.

< ?php require_once 'Zend/Amf/Server.php'; require_once 'Zend/Amf/Exception.php'; require_once 'br/com/leonardofranca/vo/FileVO.php'; require_once 'br/com/leonardofranca/UploadZendAMF.php'; $server = new Zend_Amf_Server(); $server->setProduction(false);

$server->setClass('UploadZendAMF');
$server->setClassMap('FileVO',"br.com.leonardofranca.vo.FileVO");

echo($server->handle());
?>

Read more at; File uploads with Adobe Flex and Zend AMF – Workflow: Flash.

Posted on

Flex Builder 4.5.x Test Drive for Mobile Tutorials

Here is a very good multi-part tutorial on the ins and outs of mobile client / server development, that adds some quite useful functionality on Android, Apple IOS and Blackberry mobile devices.

In this Test Drive, you are going to create a Flex mobile application that retrieves, displays, and modifies database records (see Figure 1). A Flex application does not connect directly to a remote database. Instead, you connect it to a data service written in your favorite web language (PHP, ColdFusion, Java, or any other server-side technology). You will build the front-end Flex mobile application; the database and the server-side code to manipulate database records is provided for you as a PHP class, a ColdFusion component, or Java classes.

The Mobile Test Drive application running on a mobile device.

Figure 1. The Mobile Test Drive application running on a mobile device.

via Adobe Developer Connection.

Posted on

Zend_Config_Ini and a string

Rob Allen as usual writes useful stuff; One thing that is different between Zend_Config_Xml and Zend_Config_Ini is that with Zend_Config_Xml you can pass in an XML string as the first parameter of the constructor and it will work. This doesn’t work with Zend_Config_Ini as we use parse_ini_file() under the hood.

With PHP 5.3 however there is is a new function called parse_ini_string() which will allow us to load arbitrary ini string into Zend_Config objects. This can’t go into Zend Framework 1 though due to our PHP 5.2.4 minimum version requirement.

As I needed this for a project, I extended Zend_Config_Ini to support this feature, which means simply overloading a single method


class App_Config_Ini extends Zend_Config_Ini
{
/**
* Load the INI file from disk using parse_ini_file(). Use a private error
* handler to convert any loading errors into a Zend_Config_Exception
*
* @param string $filename
* @throws Zend_Config_Exception
* @return array
*/
protected function _parseIniFile($filename)
{
set_error_handler(array($this, '_loadFileErrorHandler'));
if (substr($filename, -4) == '.ini') {
$iniArray = parse_ini_file($filename, true);
} else {
$iniArray = parse_ini_string($filename, true);
}
restore_error_handler();

// Check if there was a error while loading file
if ($this->_loadFileErrorStr !== null) {
/**
* @see Zend_Config_Exception
*/
require_once 'Zend/Config/Exception.php';
throw new Zend_Config_Exception($this->_loadFileErrorStr);
}

return $iniArray;
}
}

The actual change is to see if the last 4 characters of the filename are “.ini” and if they aren’t then use parse_ini_string() instead of parse_ini_file(). The rest of the code is just error handling.

This is one area where I really like it when a class implements methods that done just one thing.

More at Rob Allen’s Dev notes

Posted on

Encrypt session data in PHP

Zimuel writes; As promised in my last post I present an example of strong cryptography in PHP to secure session data.
This is a very simple implementation that can be used to improve the security of PHP applications especially in shared environments where different users have access to the same resources. As you know, the PHP session data are managed by default using temporary files. In shared environment a malicious user that is able to access to these temporary files can easly read the session data because they are stored in plaintext (data in a session file is theserialization of the array $_SESSION).
In theory, the session data should be stored in folders that are accessible only by the owner of the web site, but never say never (btw, you can manage the location of the session data using the session_save_path function or changing the session.save_path in the php.ini).

To secure the session data I used strong cryptography to encrypt the content using the mcrypt extension of PHP. I chosen the simmetric cipher AES (Rijandel-256) to encrypt the session data and the openssl_random_pseudo_bytes() function to generate a random key of 256 bit.
The idea is to use a cookie variable to store the key that will be used to encrypt the session data. In this way the key is stored only in the client (the browser) and only the client is able to decrypt the session data on the server. Each time we encrypt the session data we re-generate the IV vector in a random way using the mcrypt_create_iv() function. It is very important to generate a unique IV in each encryption. This best practice increase the security of the encryption algorithm.
It’s important to note that this implementation is not secure against session hijacking attack. If someone is able to capture the cookie variable of a client and have access to the temporary session files, in the server, he/she will be able to decrypt the session data. Our goal is to protect session data against attacks on shared environments.

The idea to encrypt the session data is not new, for instance Chris Shiflett proposed an implementation in his book “Essential PHP Security” (O’Reilly, 2006). Shiflett used a $_SERVER variable to store the key used to encrypt the session data. Kevin Schroeder, my colleague at Zend Technologies, implemented a very similar session encryption algorithm extending the Zend_Session class of Zend Framework (you can find it here). In my solution, I used some of the best practices related to strong cryptography to implement a secure session handler.

Below the source code of my implementation:

Full class @ Zimuel’s blog.

Posted on

A Zend Framwork compound form element for dates

Rob Allen writes; A while ago I needed to ask a user for their date of birth on a Zend_Form. The design showed three separate select elements to do this:

Screen shot of a 3 select boxes for a date on a form

A little bit of googling found this site http://codecaine.co.za/posts/compound-elements-with-zend-form which has not unfortunately disappeared, so the code in this article owes a lot of the author of that article.

It turns out to be remarkably simple to create a single Zend Form element that is rendered as multiple form elements. We create an element object and a view helper object and we’re done. Usage then looks like:

< ?php class Application_Form_Details extends Zend_Form { public function init() { $this->addPrefixPath('App_Form', 'App/Form/');

// other elements before

$this->addElement('date', 'date_of_birth', array(
'label' => 'Date of birth:'
));

// other elements after

$this->addElement('submit', 'Go');
}
}

Obviously, this form lives in application/forms/Detail.php and is rendered as usual in a view script. In our form definition, we have added an element called ‘date’ and with the addition of the addPrefixPath call have told the form that in addition to using the standard Zend Framework form elements, also look in library/App/Form. (Incidentally, we can also now override any supplied form element by simply dropping a replacement into the libraryApp/Form folder.)

The date form element lives in library/App/Form/Element/Date.php as Zend_Form knows to look in a subfolder for App/Form called Elements for any element objects and will look in the Decorator/ sub folder for decorator objects.

The Date element looks like this:

Read the rest at Rob Allen’s DevNotes.

Posted on

ExtJs, ExtDesigner and Zend Framework

Nils-Fredrik G. Kaland writes; Let’s say you are working on the user interface in Ext Designer / Sencha Ext Js, and after a while you find out you have ended up with a great amount of data stores. You also need to handle lots of Ajax requests and all the server side coding this invokes. But, why not think two steps forward already when working with the interface in Ext Designer? Of course, you are an experienced developer – so you have your database model ready. More on that later. Let’s start with the user interface in Ext Designer.

via ExtJs, ExtDesigner and Zend Framework

Posted on

Handling exceptions in a Front Controller plugin – Rob Allen’s DevNotes

Rob Allen wites in his DevNotes; If you have a Zend Framework Front Controller plugin which throws an exception, then the action is still executed and then the error action is then called, so that the displayed output shows two actions rendered, with two layouts also rendered. This is almost certainly not what you want or what you expected.

This is how to handle errors in a Front Controller plugin:

  1. Prefer preDispatch() over dispatchLoopStartup() as it is called from within the dispatch loop
  2. Catch the exception and the modify the request so that the error controller’s error action is dispatched.
  3. Create an error handler object so that the error action works as expected.

This is the code:

< ?php class Application_Plugin_Foo extends Zend_Controller_Plugin_Abstract { public function preDispatch(Zend_Controller_Request_Abstract $request) { try { // do something that throws an exception } catch (Exception $e) { // Repoint the request to the default error handler $request->setModuleName('default');
$request->setControllerName('error');
$request->setActionName('error');

// Set up the error handler
$error = new Zend_Controller_Plugin_ErrorHandler();
$error->type = Zend_Controller_Plugin_ErrorHandler::EXCEPTION_OTHER;
$error->request = clone($request);
$error->exception = $e;
$request->setParam('error_handler', $error);
}
}

}

That’s it.

via Rob Allen’s DevNotes.

Posted on

Local config files and Zend_Application

Rob Allen writes; A friend of mine recently had a requirement where she wanted to have two config files loaded into Zend_Application, so that the specific settings for the server were not stored in the version control system.

Hence she has two config files: application.ini and local.ini where local.ini is different on each server.

The easiest way to approach this problem is to load the two files within index.php, merge them and then pass the merged config file to Zend_Application.

The code to do this looks like this: Local config files and Zend_Application.

Proudly powered by WordPress