Assuming that you have the standard zend directory structure, you will have something like this:

/application
  /admin
    /controllers
    /layouts
    /views
  /default
    /controllers
    /layouts
    /views
  /feeds
    /controllers
    /views

Or something of the sort. When the user is in the admin section we want to use the layout folder from /admin, and when they are in the default section or in the feeds section of the site we would like to use the layout folder from /default.

We could simply go through all the controllers in the admin section and set the layout path in the init or preDisptach function:

This may work well for this simple example. However, every time we wish to add a controller to the admin section it would be necessary to setup the layout path and if ever we want to change the layout path for the admin module, there would be a lot of search-replacing.

A Much better solution is to write a plugin for the Zend Front controller. This plugin extends the Zend_Controller_Plugin_Abstract type and will be run each time the front controller is invoked, before anything is rendered.

Our plugin must have some very basic functionality:

1. Ability to register a layout for use with a specified module
2. Ability to fall back to the default layout if there is no layout registered for the current module

The Layout Plugin is as follows:

The $_moduleLayouts property maintains the mapping between modules and layouts.

The registerModuleLayout function allows us to register a layoutpath and an (optional) layout name for a module.

The actual magic happens in the preDispatch function (which is called by the front controller before dispatching the request). The function checks to see if there is a layout set for the current module; if there is, it switches the layout path to use the module-specific path. Next it checks to see if there is a layout name associated with the layout registered for this module. If there is, it uses it, otherwise it falls back to the default layout name.

In our bootstrapper file (html/index.php) we must setup the default layout and module layout paths and then register the plugin with the front controller. The following code snippit is only a sliver of the bootstrapper and assumes that $controller is an instance of Zend_Controller_Front (eg: $controller = Zend_Controller_Front::getInstance();)

It is important to setup the default layout so the plugin has a layout to fall back to if no module-specific layout is registered.

I hope that this tutorial has served as a quick and easy introduction to Zend Front Controller plugins and module-specific layouts.

From the developers website:

fakemail is a fake mail server that captures emails as files for acceptance testing. This avoids the excessive configuration of setting up a real mail server and trying to extract mail queue content.

I am quite impressed with this handy little script (written in both Python and Perl), as it works exactly as advertised: taking out the time required to properly configure a SMTP server and saving the hassle of having dozens of test messages showered across inboxes. Instead of forwarding emails on to their recipients, it simply saves a raw copy of the email to the specified directory.

The script has a windows installer that bundles the script with python and will run on all flavors of Linux and Unix assuming that they have perl or python installed.

To configure Zend_Mail use fakemail place the following in your bootstrapper or common config file:

The 'localhost' variable is the address of the computer that fakemail is running on (likely the local machine). The port number is the port that is specified when fakemail is run on the command line.

For more information about fakemail, binaries, and a usage guide. Visit the developers website at Sourceforce: http://www.lastcraft.com/fakemail.php

PLAIN TEXT
CODE:




<IfModule mod_expires.c>


     Header set Cache-Control "max-age=3600, public"


</IfModule> 

The above checks to ensure the mod_expires module is loaded in apache, and if it is the Cache is set to expire 3600 seconds from now: 1 hour. Furthermore, the page can be cached in a publicly accessible (shared) cache.

Getting caching working with Zend was a little more challenging. By default Zend (or PHP) writes caching information to headers disabling caching. However, the code snippit below (to be placed inside an Action Controller) blanks out the expires header, sets the cache-control header so that the page expires in one hour, and blanks out the Pragma header.

The expires header allows the server to specify a date when the cache expires (Rather than setting the max-age offset) and the Pragma indicates if the page can be cached in a proxy. I found, with Firefox 3, if Expires and Pragma weren't blanked out, they would take preference over the Cache-Control header, disabling caching of the page.

After the addition of caching, the page load was reduced to 8Kb of data pulled down over 9 requests: about a 90% optimization.

After I got the script setup and running I wanted a Gentoo init script that would automatically start the script on boot. After reading through some examples in my /etc/init.d/ directory I seem to have managed to cook up something that works:

PLAIN TEXT
CODE:




#!/sbin/runscript


# blacklist is free software; you can redistribute it and/or modify


# it under the terms of the GNU General Public License as published by


# the Free Software Foundation; either version 2 of the License, or


# (at your option) any later version.


#


# blacklist is distributed in the hope that it will be useful,


# but WITHOUT ANY WARRANTY; without even the implied warranty of


# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the


# GNU General Public License for more details.


#


# Copyright: Dustin Thomson


# Homepage: http://dustint.com


# Date: 2008-06-03


# Version 0.0.1


 


EXEC=/usr/sbin/blacklist


PID=/var/run/blacklist.pid


 


depend(){


        need net


}


 


checkconfig(){


        if [ ! -e /usr/sbin/blacklist ] ; then


                eerror "blacklist not found in /usr/sbin/blacklist"


                return 1


        fi


}


 


start() {


        checkconfig || return 1


        ebegin "Starting Blacklist"


        $EXEC &


        eend $?


}


 


stop()  {


        ebegin "Stopping Blacklist"


        start-stop-daemon --stop --retry 20 --quiet --pidfile $PID


        eend $?


} 

Alternatively, for those with wget, cd into /etc/init.d/ and:

wget http://dustint.com/wp-content/uploads/2008/06/blacklist
chmod +x blacklist

I have placed blacklist.py in /usr/sbin/ and renamed it to simply blacklist

Reto also hosts a handy "stage-4" backup script which can create a full backup of your filesystem.

I have been using the Dojo toolkit as my Javascript library of choice since back in early 2006 when it was still around version 0.4. Since then, the project has made tremendous strides including the release of version 1.0 and 1.1 with 1.2 on the way. At the beginning of 2008 I started using the Zend Framework to build MVC PHP applications and, with the release of 1.5, it has become my PHP framework of choice.

To my delight, the Zend Framework and Dojo have recently announced a partnership which will lead to tighter integration of these two great open source frameworks.

One of the most exciting additions to the Zend Framework is the Zend_Json_Server support for JSON-RPC. I have been using JSON-RPC with Dojo for quite some time and, up until now, it has been challenging to find a design pattern that plays nice with the Model View Controller implementation in the Zend Framework. However, with the addition of the Zend_Json_Server this is no longer the case.

Prerequisites:

This tutorial assumes you are familiar with developing in PHP and javascript and are experienced with dojo and the Zend Framework using the MVC paradigm.

Common Pitfalls

• Absolute paths are used in the code examples. Ensure that you modify them to reflect your server's directory structure. This tutorial assumes that you are working with a ZF project whose /html/ directory corresponds to the root of your webserver
• Ensure you place a .htaccess file in /html/scripts/ that disables the re-write engine. If you fail to do this step, when trying to load dojo libraries, ZF will be trying to find controllers that match the requests and throwing exceptions.

Patching Zend Framework

At the time of writing, the Json-RPC component has not been accepted into the Zend Framework (although it will be soon). To get the Zend Framework (ZF) working with Json-RPC we must download code from the incubator area of SVN. If you don't know how to use a SVN client to check out code, read about it here. Download the current version of ZF and then, using an SVN client, download http://framework.zend.com/svn/framework/standard/incubator/library/Zend/Json/ and place it in the json directory of your local copy of ZF.

Setting up the Directories

For the purpose of this tutorial I will be using code and examples from Nickel: the application that will eventually run SFU Bookswap V.3. I use a fairly standard MVC directory structure as recommended by the ZF docs:

application
	|-default
	|-controllers
	|-views
html
	|-images
	|-scripts
		|-nickel
			|-RPC
library
	|-Nickel
		|-Models
		|-RPC
	|-Zend
		| .... Framework checkout

The reasoning behind placing the Nickel folder in the library is so we can use Zend_Loader to load classes on demand. Also, as a condition of this, the classes in the Nickel folder follow the ZF naming convention: so, say, the class for a book model would be named, Nickel_Model_Book.

Similarly, there is a corresponding directory structure in the scripts folder. This is to be used with the Dojo packaging system. So, to access the RPC handle for the book model we would call a function such as nickel.rpc.book.getAuthor()

Creating the RPC Controller

The next step is to actually create the RPC controller. I have created a file in /application/default/controllers/RpcController.php which contains the RpcController action controller class. RpcController has two actions: one which will return the SMD (simple method declaration) to dojo when the JSON-RPC object is instantiated. The second action, the service action, actually processes the RPC request and returns the result. So, we have:

/application/default/controllers/RpcController.php
PLAIN TEXT
PHP:




<?php


class RpcController extends Zend_Controller_Action {


 


    public function smdAction(){


        $class = $this->_getParam('class');


 


        $server = new Zend_Json_Server();


 


        $server->getServiceMap()->setDojoCompatible(true);


        $server->getServiceMap()->setTransport('POST')


         ->setTarget($this->getHelper('url')->url(array('controller'=>'rpc', 'action'=>'service')))


         ->setId($this->getHelper('url')->url(array('controller'=>'rpc', 'action'=>'service'))); 


 


        $server->setClass($class);


 


        $this->view->data = $server->getServiceMap();


        $this->render('service');


    }


 


    public function serviceAction(){


        $class = $this->_getParam('class');


 


        $server = new Zend_Json_Server();


        $server->setClass($class);


        $server->setAutoEmitResponse(true);


 


        $server->handle();


    }


} 

The smd Action takes ‘class' as a parameter. This is the name of the class that we wish to expose via Json-RPC, such as Nickel_Rpc_Book. Please note the function call setDojoCompatible(true) which forces the server to generate dojo-compatible SMD definitions. The target function call sets the target of the function calls (the service url) to the service action defined below.

The service action simply processes the RPC request by calling the specified function with the sent parameters.

There is a fairly large security hole opened by this implementation. Since any value can be passed to the ‘class' argument, it is possible to remotely call functions for any class that can be auto-loaded. A ‘safer' implementation would simply concatenate the class parameter with "Nickel_Rpc_". This way is less likely that an attacker could compromise your server by calling a dangerous function.

Writing a RPC Class

Now that we have the RPC server set up we need some classes in Nickel_RPC to call. For the purpose of this example we will use a very simple Book class that has basic functionality:

/library/Nickel/Model/Book.php
PLAIN TEXT
PHP:




<?php


class Nickel_RPC_Book {


    public static function simpleEcho(){


        return “Hello World”;


    }


    public static function getTitle($bookId){


        $book = new Nickel_Model_Book($bookId);


        return $book->getTitle();


    }


    public static function setTitle($bookId, $title){


        $book = new Nickel_Model_Book($bookId);


        $book->setTitle($title);


        $book->update();


        return true;


    }


} 

In the above RPC class, in addition to the simpleEcho function, we have two static functions: one that reads the title from the Book Model, and the second which writes a new title back to the database via the Book model. Notice that the functions are static: this is because, in the case of our book anyways, a notion of $this doesn't really make since, as we don't actually know what book we want the title for unless we pass the book ID from dojo.

Writing the RPC Front-end

Now that we have the backend written, it is fairly quick to write the frontend.

The first step is to create the book rpc file so we can include nickel.rpc.book using a dojo.require statement:

/html/scripts/nickel/RPC/book.js
PLAIN TEXT
JavaScript:




dojo.provide(‘nickel.rpc.book’);


dojo.require(‘dojo.rpc.JsonService’);


 


nickel.rpc.book = new dojo.rpc.JsonService(‘/rpc/smd/class/Nickel_RPC_Book’); 

The above code snippet should be saved as book.js and placed in /html/scripts/nickel/rpc. When this file is included, a new JsonService object is created with functions populated from the SMD generated by the RPC controller class. As a result, nickel.rpc.book will now contain three functions: simpleEcho, getTitle and setTitle.

Using The Front-end.

Finally, we have the opportunity to see the fruit of our labour. Create an indexController and the accompanying view. In the view, after including dojo.js, create a new script block:

/application/default/views/index/index.phtml
...
PLAIN TEXT
JavaScript:




<script type=”text/javascript”>


    dojo.registerModulePath(‘nickel’, ‘/scripts/nickel’);


    dojo.require(‘nickel.rpc.book’);


 


    dojo.addOnLoad(function(){


        nickel.rpc.book.simpleEcho().addCallback(function(msg){


            alert(msg);  //Alert: Hello World


    });


 


    nickel.rpc.book.getTitle(1).addCallback(function(title){


        alert(title);   //Alert: title of book with ID 1 in database


    });


 


    nickel.rpc.book.setTitle(1, ‘Foo’).addCallback(function(result){


        alert(‘success’);   //Sets the title of book with ID 1 to ‘Foo’


    });


});


</script>


... 

dojo.registerModulePath adds a module path to the dojo loader. This allows us to include our custom nickel modules easily and on-demand.

Conclusion

The Dojo Toolkit and Zend Framework provide a highly structured, maintainable JSON RPC system when used together. This can be used to easily propagate dirty javascript data objects to persistent storage in the backend, as well as expose PHP function calls to javascript to return useful data.

I hope you have enjoyed this tutorial. If you find any typos, mistakes or just wish to leave a message, please add a comment below.

I also encourage you to link to this post if you have found it at all useful in developing your web-application.

I love Adblock Plus - I refuse to use the internet without it. I also quite enjoy Greasemonkey. Unfortunately, neither is yet compatible with the new Firefox 3b5. I got tired of waiting so I took measures into my own hands.

The XPI file format is basically a glorified zip file, so you can unzip it with a compression utility and modify the maximum version number in install.rdf. Basically I replaced the value in the em:maxVersion field with 3.* so to make it compatible with all versions of Firefox.

Of course, these maximum version numbers are there for a reason: newer versions of Firefox may break the extension functionality, but no problems so far.

For the lazy, I have uploaded the patched install files. Of course I give zero guarantees or warranty for the correct operation of these patched extensions. I encourage you to upgrade to the official compatible version as soon as possible.

To install:

1. Download File
2. Drag downloaded file into open Firefox window
3. Enjoy an Ad-free internet

Adblock Plus For Firefox 3 Beta 5 The Adblock Plus Development build now supports Beta 5. Get it here: http://adblockplus.org/devbuilds/

Greasemonkey For Firefox 3 Beta 5

We can see that we have two choices: force the users to login to each separate application separately, or somehow combine all the applications under a single login.

A Central Authentication Service

Central Authentication Services allow a user to share a single login across multiple applications and even websites. OpenID and Yahoo are examples of large CAS hybrids that are becoming increasingly popular amongst social networking sites. However, CAS does not have to be so global in scope, many universities and companies use CAS when their services are best provided by several applications.

How it works

The series of events that occur during a CAS authentication session are as follows:

1. User attempts to gain access to the secure area of a photo gallery
2. The gallery detects that this user is not authenticated to view this content
3. The user is re-directed to the login page of the Central Authentication Service. A callback URL is passed to the CAS by means of a GET variable
4. The user enters their login information and it is verified. A cookie is set to identify this user as authenticated in the future
5. The CAS redirects the user to the callback passed by the photo gallery. A ticket is passed to the photo gallery callback page by means of a GET variable
6. The photo gallery establishes a secure connection to the CAS and checks to ensure the ticket is valid, if it is, the user has been successfully authenticated

Depending on the CAS setup, when the user enters another secure area of the website, say the wiki, they will be redirected to CAS, then transparently redirected back to the wiki callback page. This occurs because the user has already authenticated themselves with CAS, so there is no need to re-enter login credentials. To the user, it appears as if they were immediately authenticated by the wiki.

A Central Authentication Service also reduces some aspects of user information management as, if the user wishes to update their password; they need only do it once. However, CAS does not solve the problem of propagating other types of user information, such as the users name and contact information to the various applications. Furthermore, the authentication routines of the participating applications much be refactored to authenticate the user via CAS, then load the user information out of the local application database.

In Conclusion:

Central Authentication is a good way to improve the user experience if you are currently forcing users to authenticate multiple times. Furthermore, from a developers standpoint, it is a clean and safe way to pass authentication tokens between applications, especially if these applications may reside on separate domains.

For more information on CAS, including a JAVA server implementation, protocol descriptions and clients in multiple languages visit http://www.ja-sig.org/products/cas/index.html

The only trouble I ran into was when I wanted to used Dijit Widgets in my templates. Since on my main page I didn't know what template I would be calling, I didn't know which Widget classes to include with dojo.require(). To fix this, I have come up with a little hack that does the job, although not too elegantly.

Bascially my approach includes hooking into dojo.parser and changing its behaviour. Now when it is parsing widgets from the page it checks to see if they exist and, if not, it does the appropriate dojo.require() to try to pull them in.

var fn = dojo.parser.instantiate;

dojo.parser.instantiate = function(nodes){

    dojo.forEach(nodes, function(node){

        var className = node.getAttribute(dojo._scopeName + "Type")

        if(!dojo.isFunction(dojo.getObject(className))){

            //It is not an object... yet

            dojo.require(className);

        }

    });

    return fn(nodes);

}

The above code-block shows the implimentation. Simply place this in between <script> tags in your header. Now you should be able to do dojotypes anywhere on your page and have the appropriate classes automatically included.

There are several disadvantages to my approach. For example, if you have a typo in one of your dojoType, it will try to pull down a file that doesn't exist. We also have the impact of running through the array of nodes an additional time, although since the dojo.parser.instantiate function is already bounded by O(n) this shouldn't make a noticeable impact.

The CookieInjector userscript simplifies this process, by allowing the user to copy-paste the cookie portion of the dump and have the cookies from the dump automatically created on the currently viewed web page.

To Use The Script:

Fire up Wireshark, formally Ethereal, if you don't have Wireshark you can grab it from: http://www.wireshark.org/. Start listening for traffic on the same interface you use to access the internet. To cut down on extra packets, enter tcp as a capture filter. TCP is a transport layer protocol featuring reliable transport, congestion control and connection oriented transfers. Since HTTP uses connections between client and server and therefore the TCP protocol, is is safe to filter out all non-TCP packets. To further filter the packets that Wireshark is displaying enter http.cookie in the filter field. This will filter out all packets which are not using the HTTP application layer protocol and all HTTP packets which do not contain cookies.

Next go to a website that uses cookies. Most websites which support user logins or shopping carts use cookies for these purposes. Make sure that the website that you visit does not encrypt the entire session (such as a banking website), otherwise the packets will be encrypted and not viewable in wireshark. After capturing a couple packets which contain cookies scroll down to the Hypertext Transfer Protocol portion of the packet preview, expand it, and scroll down to the cookie line. Right click on the line, and select copy->Bytes (Printable Text Only). This will copy the human-readable portion of the packet which represents the Cookies associated with this website.

If you haven't already, install Greasemonkey, and the CookieInjector userscript. Clear your private data, ensuring that the Cookies and Authenticated Sessions options are selected. This will delete all your cookies, so we can see the script in action. Press alt-c to view the CookieInjector dialogue, paste the cookie string from wireshark into the text box and click OK.

Congratulations! Your cookies have now been restored!

How The Script Works:

After the page has loaded the CookieInjector class is initialized. This involves setting up the dialogue and binding a function to the onkeydown event. When the user presses the ALT-C key combination, the CookieInjector keyPress function is called, which checks to see if the correct key combination has been triggered. If it is valid, the dialogue's display style is changed, making it visible in the middle of the page.

After the user enters the cookie that was copied from Wireshark, the script does a quick cleanup of the string, and then adds the cookies to the browsing session.

Note that the cookie's host will be the domain that is loaded in the browser when the cookie is injected. The root path will be used for the root of the cookie to ensure that the cookie is persistent across the entire domain. Finally, the cookie is a session cookie, which means that the cookie will expire when the browser is closed.

Security Implications Of Cookies

The use of cookies for identification and authentication presents a dangerous security risk for un-encrypted connections. Most websites (such as Hotmail, Facebook and Gmail), only encrypt the username and password when initially authenticating the user and all traffic following the initial handshake is un-encrypted. As a result, the cookie information is readable by anyone who is listening with appropriate software, and malicious users can steal the cookies of other users on the network, possibly gaining access to their accounts. Un-encrypted or weakly encrypted wireless connections (those which do not use WPA or stronger encryption schemes) are especially susceptible to cookie stealing. This is because anyone with a wireless card can simply listen to all network traffic as it is broadcast through the air, intercepting cookies, images, web pages and any other traffic which may or not be intended for them. Intercepting traffic on a switched network (most LANs) is more complex, but can be accomplished using ARP Poisoning or software such as Ettercap

The take-home lesson is to use encrypted connections, like https, whenever privacy is important. Always remember that if the connection is not encrypted anyone could be listening in.

Download CookieInjection Userscript

External Links:

Greasemonkey: https://addons.mozilla.org/en-US/firefox/addon/748
HTTP Protocol: http://en.wikipedia.org/wiki/HTTP
TCP Protocol: http://en.wikipedia.org/wiki/TCP
Cookies: http://en.wikipedia.org/wiki/HTTP_cookie
Wireshark: http://www.wireshark.org/
Ettercap: http://ettercap.sourceforge.net/
ARP Poisoning: http://en.wikipedia.org/wiki/ARP_spoofing
Ethereal: http://www.ethereal.com/

As part of this initiative ULife maintains an events calendar that is available both in HTML and RSS formats. I was much more interested in the RSS feed as it can be easily parsed and manipulated by server-side PHP.

How The Refactor Works (In A Nutshell)

The basic operation of the script is very straight-forward.

1. A copy of the ULife calendar RSS feed is downloaded and cached from https://events.sfu.ca/rss/calendar_id/3.xml.
2. The RSS feed is parsed by a slightly modified version of Last RSS which converts the feed into PHP associative arrays.
3. The arrays are then passed to the Smarty Template Engine which makes the output look all pretty

Simple eh? There is a little bit more of business logic, as the user is able to specify the template file to use, the CSS file to use, the number of days to display as well as indicate if the script is to output a full HTML page or just the HTML code needed for the calendar.

Currently the preferred way to include the calendar on a dynamic web-page is to use the PHP readfile (or equivalent) command with the argument being the path to the Refactor script. If the page is not dynamically generated the other option is to use a Javascript include, which uses cross site scripting to fetch the content and write it to the screen.

Right now there is only a single template available - a vertically aligned one, and a single style - a dark one. Users of the script can of course come up with their own style-sheets by simply downloading and editing the dark style sheet to their liking. If there is demand for it, I will write more templates, starting with a horizontally aligned template, along with a couple more style sheets.

To play around with the Calendar Refactor take a look at http://ulife.dustint.com