Content provider policy requests and responses

Use the Request and Response tabs to define control over HTTP headers, HTTP cookies, and filters. Filters provide a programmatic control over content during the request and response phases of the interaction between HCL WebSphere Portal and the web application.

Headers

Specify the allowed (propagated) or blocked headers in the requests and responses to and from the content provider. By default, the WAB propagates all client-side headers. The client-side headers are present in the request received from the browser. The WAB does not propagate headers listed in the block field.

Click Insert Header to add custom headers. The custom headers are useful for the following scenarios:

• To add more headers not in the request from the browser

• To add more headers not in the request from the content provider

• To use single sign-on

• To send more information

If we add a custom header with the same name as an existing header, the custom header overrides the existing header.

Cookies

Specify the allowed or blocked cookies in the request from the browser or the response from the content provider. By default, the WAB propagates all client-side cookies to the content provider. The client-side cookies are present in the request received from the browser. The WAB stores all the server-side cookies in the session. Server-side cookies are received from the content provider in the form of Set-Cookie response headers.

Click Insert Cookies to add custom cookies. The custom cookies are useful for the following scenarios:

• To add more cookies not in the request from the browser

• To add more cookies not in the response from the content provider

• To use single sign-on

• To send more information

If we add a custom request cookie with the same name as an existing cookie, the custom cookie overrides the existing cookie. If we add a custom response cookie, the WAB adds a Set-Cookie header. The WAB uses the provided name and value in responses sent from the Reverse Proxy servlet to the browser.

Filters

Filters are Java code started on demand to run custom actions. They modify the request programmatically. Filters are extensions to core feature. Use the servlet filter API to create custom filters. The filters manipulate the request or response from the portal to the content provider. Developers create the filters. First, the administrator clicks Insert request filter to specify the set of filters available to apply to this policy. Then, the administrator clicks Add Filter to apply the filter to the policy.

Create custom filters:

1. Create a Java file with the following sample code.

   The following code inserts a sample header into a request that goes from the portal to the content provider site:

   package com.ibm.wps.wab.filter;
   import java.io.IOException;
   import java.util.Enumeration;
   import javax.servlet.Filter;
   import javax.servlet.FilterChain;
   import javax.servlet.FilterConfig;
   import javax.servlet.ServletException;
   import javax.servlet.ServletRequest;
   import javax.servlet.ServletResponse;
   import com.ibm.wps.vwat.servlet.ReverseProxyRequest;
   
    public class RequestFilter implements Filter 
    {
       @Override
       public void destroy() 
       {
          // TODO Auto-generated method stub
       }
       @Override
       public void doFilter(ServletRequest request, 
              ServletResponse response,    
              FilterChain chain) throws IOException, ServletException 
       {
           System.out.println("Request Filter");
           ReverseProxyRequest reverseProxyRequest = (ReverseProxyRequest)request;
           Enumeration<String> headerNames = reverseProxyRequest.getHeaderNames();
           String headerName;
           System.out.println("Request Headers: ");
           while(headerNames.hasMoreElements())
           {
              headerName = headerNames.nextElement();
              System.out.println(headerName);
           }
           chain.doFilter(request, response);
       }
       @Override
       public void init(FilterConfig arg0) throws ServletException 
       {
          // TODO Auto-generated method stub
       }
    }

2. To engage the filter:

   1. Create a filter component Java file with at least one class that implements the javax.servlet.Filter interface.

   2. Compile the filter component Java file against the following items:

      • VWAT servlet. runtime.jar in the directory...
        wp_profile/installedApps/cell-name/wp.vwat.servlet.ear.ear/wp.vwat.servlet.war/WEB-INF/lib

      • VWAT engine JAR files (in the wp.vwat.engine.jar in wps/shared/app directory)

      • All portal/WAS Java archive and compressed files

      Use the Rational Application Developer Portal project because it already has the correct build paths for HCL WebSphere Portal and IBM WebSphere Application Server.

   3. Build a .jar file with the compiled class files.

   4. Place the .jar file in the same location as the runtime.jar file.

   5. Restart the WebSphere_Portal server.

Parent Web application bridge