Writing Custom Handlers

This section introduces handlers and using an example, explains how to write a custom handler:

Introducing handlers

When an API is created, a file with its synapse configuration is added to the API Gateway. You can find it in the <APIM_HOME>/repository/deployment/server/synapse-configs/default/api folder. It has a set of handlers, each of which is executed on the APIs in the same order they appear in the configuration. You find the default handlers in any API's Synapse definition as shown below.

<handlers>
      <handler class="org.wso2.carbon.apimgt.gateway.handlers.security.CORSRequestHandler">
         <property name="apiImplementationType" value="ENDPOINT"/>
      </handler>
      <handler class="org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler"/>
      <handler class="org.wso2.carbon.apimgt.gateway.handlers.throttling.APIThrottleHandler">
         <property name="id" value="A"/>
         <property name="policyKeyResource" value="gov:/apimgt/applicationdata/res-tiers.xml"/>
         <property name="policyKey" value="gov:/apimgt/applicationdata/tiers.xml"/>
         <property name="policyKeyApplication" value="gov:/apimgt/applicationdata/app-tiers.xml"/>
      </handler>
      <handler class="org.wso2.carbon.apimgt.usage.publisher.APIMgtUsageHandler"/>
      <handler class="org.wso2.carbon.apimgt.usage.publisher.APIMgtGoogleAnalyticsTrackingHandler">
         <property name="configKey" value="gov:/apimgt/statistics/ga-config.xml"/>
      </handler>
      <handler class="org.wso2.carbon.apimgt.gateway.handlers.ext.APIManagerExtensionHandler"/>
   </handlers>

Let's see what each handler does:

CORSRequestHandler: Sets the CORS headers to the request and executes the CORS sequence mediation logic. This handler is thereby responsible for returning the CORS headers from the gateway or routing the requests to the backend and letting the backend send the CORS headers.
APIAuthenticationHandler: Validates the OAuth2 bearer token used to invoke the API. It also determines whether the token is of type Production or Sandbox and sets MessageContext variables as appropriate.
APIThrottleHandler: Throttles requests based on the throttling policy specified by the policyKey property. Throttling is applied both at the application level as well as subscription level.
APIMgtUsageHandler: Publishes events to WSO2 Data Analytics Server (WSO2 DAS) for collection and analysis of statistics. This handler only comes to effect if API usage tracking is enabled. See Working with Statistics for more information.
APIMgtGoogleAnalyticsTrackingHandler: Publishes events to Google Analytics. This handler only comes into effect if Google analytics tracking is enabled. See Integrating with Google Analytics for more information.
APIManagerExtensionHandler : Triggers extension sequences. By default, the extension handler is listed at last in the handler chain, and therefore is executed last. You cannot change the order in which the handlers are executed, except the extension handler. To configure the API Gateway to execute extension handler first, uncomment the <ExtensionHandlerPosition> section in the <APIM_HOME>/repository/conf/api-manager.xml file and provide the value top. This is useful when you want to execute your own extensions before our default handlers in situations like doing additional security checks such as signature verification on access tokens before executing the default security handler.
See Adding Mediation Extensions.

Using APILogMessageHandler

Message logging is handled by APIManagerExtensionHandler for API Manager 1.9.1 and above. Addition to the above mentioned Handlers, APILogMessageHandler has introduced from API Manager version 1.9.1 onwards. APILogMessageHandler is a sample handler that comes with WSO2 API Manager that can be used for logging.

Why are logs removed from APIManagerExtensionHandler?

The primary purpose of ExtensionHandler is handling extensions to mediation and not for logging messages. When the logs are also included in ExtensionHandler, there's a limitation to improve the ExtensionHandler for developing features because it breaks the logs.

For example, When the ExtensionHandler moves to the top of the handlers set, most of the logs print null values since the handler runs before the APIAuthenticationHandler. Therefore, the logs are removed from the extension handler and APILogMessageHandler introduced as a sample.

To achieve logging requirements, this handler is not the only approach and with custom sequences also it is possible to log messages using the Log Mediator.

In order to enable logging by invoking APILogMessageHandler, follow the steps below.

To enable Message Logging per API :

Open the synapse Configuration of the API located in <APIM_HOME>/repository/deployment/server/synapse-configs/default/api directory and add below handler before </Handlers>.
```
<handler class="org.wso2.carbon.apimgt.gateway.handlers.logging.APILogMessageHandler"/> 
```
Copy the following code into the <APIM_HOME>/repository/conf/log4j.properties file to enable printing DEBUG logs.
```
log4j.logger.org.wso2.carbon.apimgt.gateway.handlers.logging.APILogMessageHandler = DEBUG
```
Restart API Manager.

To enable Message Logging into APIS created from publisher automatically :

Open the <APIM_HOME>/repository/resources/api_templates/velocity_template.xml file and copy the following handler beofore </Handlers>.
```
<handler class="org.wso2.carbon.apimgt.gateway.handlers.logging.APILogMessageHandler"/> 
```
Restart API Manager.

Writing a custom handler

The outcome of using a Class Mediator vs. a Synapse Handler are very similar. However, when using a custom handler you need to maintain a customized velocity template file that needs to be manually merged when you upgrade your product to a newer version. Therefore, it is recommended to use custom Handlers when you wish to specify the exact order of execution of JARs as this can not be done with Mediators.

Let's see how you can write a custom handler and apply it to the API Manager. In this example, we extend the authentication handler. Make sure your custom handler name is not the same as the name of an existing handler.

WSO2 API Manager provides the OAuth2 bearer token as its default authentication mechanism. A sample implementation is here. Similarly, you can extend the API Manager to support any custom authentication mechanism by writing your own authentication handler class. This custom handler must extend org.apache.synapse.rest.AbstractHandler class and implement the handleRequest() and handleResponse() methods.

Given below is an example implementation:

package org.wso2.carbon.test;

import org.apache.synapse.MessageContext;
import org.apache.synapse.core.axis2.Axis2MessageContext;
import org.apache.synapse.rest.AbstractHandler;

import java.util.Map;

public class CustomAPIAuthenticationHandler extends AbstractHandler {

    public boolean handleRequest(MessageContext messageContext) {
        try {
            if (authenticate(messageContext)) {
                return true;
            }
        } catch (APISecurityException e) {
            e.printStackTrace();
        }
        return false;
    }

    public boolean handleResponse(MessageContext messageContext) {
        return true;  
    }

    public boolean authenticate(MessageContext synCtx) throws APISecurityException {
        Map headers = getTransportHeaders(synCtx);
        String authHeader = getAuthorizationHeader(headers);
        if (authHeader.startsWith("userName")) {
            return true;
        }
        return false;
    }

    private String getAuthorizationHeader(Map headers) {
        return (String) headers.get("Authorization");
    }

    private Map getTransportHeaders(MessageContext messageContext) {
        return (Map) ((Axis2MessageContext) messageContext).getAxis2MessageContext().
                getProperty(org.apache.axis2.context.MessageContext.TRANSPORT_HEADERS);
    }
}

Engaging the custom handler

You can engage a custom handler to all APIs at once or only to selected APIs.

To engage to all APIs, the recommended approach is to add it to the <APIM_HOME>/repository/resources/api_templates/velocity_template.xml file. For example, the following code segment adds the custom authentication handler that you wrote earlier to the velocity_template.xml file while making sure that it skips the default APIAuthenticationHandler implementation:

<handlers xmlns="http://ws.apache.org/ns/synapse">
  <handler class="org.wso2.carbon.test.CustomAPIAuthenticationHandler"/>
  #foreach($handler in $handlers)
    #if(!($handler.className == "org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler"))
      <handler xmlns="http://ws.apache.org/ns/synapse" class="$handler.className">
      #if($handler.hasProperties())
        #set ($map = $handler.getProperties() )
        #foreach($property in $map.entrySet())
          <property name="$!property.key" value="$!property.value"/>
        #end
      #end
      </handler>
    #end
  #end
</handlers>

Given below is how to engage handlers to a single API, by editing its source view.

Note that when you engage a handler by editing the API's source view, your changes will be overwritten every time you save the API through the API Publisher.

Build the class and copy the JAR file to <APIM_HOME>/repository/components/lib folder.
Log in to the management console and click Service Bus > Source View in the Main menu.
In the configuration that opens, select an API and navigate to the <Handlers> section.
The second handler is the current authentication handler used in the API Manager. Replace the second handler with the handler that you created. It will engage your custom handler to the API Manager instance. According to this example, it is as follows:
```
<handler class="org.wso2.carbon.test.CustomAPIAuthenticationHandler"/>
```