The purpose of this implementation is to allow you to rapidly introduce authentication and access control to your application. By implementing the internals of WordPress to serve this purpose, you get a rich, secure and familiar user interface from day one and don't have to create roles, resource lists or control panels yourself. Expanding on the default WordPress setup is also rather trivial; so even using it as a beginning scaffolding for a much more complex access control system later on may save you considerable time.

Authentication

Are you who you say are? This is what's classified as authentication. In Zend, this is driven by the Zend_Auth singleton and its various adapters. If you're logged into WordPress, Vulnero will inject your WordPress identity into the Zend_Auth object as part of its bootstrap. You can check if a user is authenticated simply by calling the hasIdentity method:

public function indexAction()
{
    $auth = Zend_Auth::getInstance();
    $this->view->isLoggedIn = $auth->hasIdentity() ? 'logged in' : 'not logged in';
}

Access Control

Now that we know who you are, what are you allowed to do? WordPress calls these capabilities and roles (see: http://codex.wordpress.org/Roles_and_Capabilities). A role is a broad definition of your status (e.g.: administrator or contributor) and a capability generally refers to a specific task (e.g.: edit_posts or manage_options).

Through the Vulnero_Controller_Plugin_Acl controller plugin and its Vulnero_Controller_Action_Helper_Acl action helper, you can easily enforce WordPress roles and capabilities within your routes:

public function topSecretAction()
{
    $this->_helper->acl->assertHasRole('administrator')
                       ->assertHasCapability('manage_options')
                       ->assertHasCapability('edit_posts')
                       ->setDenyController('login')
                       ->setDenyAction('index');
}

The above serves two purposes. First, you're defining that the user visiting the route must have the administrator role within WordPress and both the manage_options and edit_posts capabilities. Secondly, you're configuring where the user will be redirected should they not meet these requirements, in this case the login controller's index action.

Note: Not setting a deny controller or action will result in a RuntimeException which will be caught by the error controller with a "permission denied" message.

Identity Object

A large amount of information about the user can be found in the Zend_Auth identity object such as name, email and so forth. Querying this object is the equivalent of the wp_get_current_user() function.

Vulnero_Acl

Although unused by the Vulnero internals, a Zend_Acl object is also available as Vulnero_Acl. In this implementation, all of the WordPress roles and capabilities are setup as roles and resources respectively. This nested structure may provide additional utility depending on what you want to do:

$acl = new Vulnero_Acl();
$acl->isAllowed('administrator', 'manage_options'); // true
$acl->isAllowed('subscriber', 'manage_options'); // false

• Adding a WordPress Administration Page
• Displaying Errors and Debugging Information