Handle logout hooks

Sometimes you need to catch the user logout action, particularly when using an SSO.

Powerful login / poor logout features

eZ Publish has a powerful abstract authentication system. It means that you can virtually use any form of authentication through Login Handlers (LDAP handler is an implementation of it). It is even possible to authenticate an already-logged-in-user from an external application, through SSO Handlers (see my tutorial about SSO Handlers).

However, there is no "logout handler" system, so it is not currently possible to catch the logout process (eZ Publish version is 4.4 Fuji at the time of writing). That's a shame because it makes almost impossible to trigger an SSO logout for example.

This has been already logged as a feature request on issues.ez.no, but fortunately there is a workaround :).

The workaround

Digging into the kernel, I found that it was actually possible to configure the redirection on logout. By default, eZ Publish redirects to /user/login, as configured in site.ini.

Here's a code extract from kernel/user/logout.php (logout view of user module) :

$ini = eZINI::instance();
if ( $ini->variable( 'UserSettings', 'RedirectOnLogoutWithLastAccessURI' ) == 'enabled' && $http->hasSessionVariable( 'LastAccessesURI' ))
{
    $redirectURL = $http->sessionVariable( "LastAccessesURI" );
}
else
{
    $redirectURL = $http->postVariable( 'RedirectURI', $ini->variable( 'UserSettings', 'LogoutRedirect' ) );
}

return $Module->redirectTo( $redirectURL );

It means that if you don't use RedirectOnLogoutWithLastAccessURI, configured in site.ini, eZ Publish checks if a RedirectURI variable has been posted, and if not, takes the [UserSettings].LogoutRedirect in site.ini.

So the solution would consist in developing a module, let's say mysso/logout, and in configuring [UserSettings].LogoutRedirect to point on this module. In the logout view of this module, just do whatever you need to do to complete yout logout process and redirect the user to the homepage (this is an example).

Yes, sure it means one more HTTP 302 redirection, but well... This is IMHO the best solution until we have proper logout handlers and handleSSOLogout() in SSO handlers ;-). If you want such a feature, go vote for the associated request !