Content provider policy requests and responses for Web Application Bridge | HCL Digital Experience

Use the Request and Response tabs to define a fine-grained 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 Digital Experience 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 Web Application Bridge propagates all the client-side headers. The client-side headers are present in the request that is received from the browser. The Web Application Bridge does not propagate headers that are 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 that are not there in the request from the browser
  • To add more headers that are not there in the request from the content provider
  • To use single sign-on
  • To send more information
If you 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 Web Application Bridge blocks all the client-side cookies from reaching the content provider. The client-side cookies are present in the request that is received from the browser. You need to specify the client-side cookies that need to be propagated by selecting Block all, except in the Cookies section of the Request tab and specifying individual cookies.

Click Insert Cookies to add custom cookies. The custom cookies are useful for the following scenarios:
  • To add more cookies that are not there in the request from the browser
  • To add more cookies that are not there in the response from the content provider
  • To use single sign-on
  • To send more information

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

Filters

Filters are Java code that can be started on demand to run custom actions. They modify the request programmatically. Filters are extensions to the 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.

Due to a change in the architecture of Web Application Bridge (WAB) in HCL Digital Experience 8.5, while legacy WAB filters may still invoke actions, they may no longer modify requests and responses. For applications which require request or response modification, WAB filters designed for Version 8.0 and earlier versions must be rewritten and redeployed as servlet filters instead. For more information on servlet filters, refer to Javadoc for javax.servlet.Filter.

Map these servlet filters to wp.vwat.servlet.ear by modifying the web.xml of the underlying wp.vwat.servlet.war. To ensure that these mappings persist the installation of maintenance for HCL Digital Experience, follow this process to redeploy wp.vwat.servlet.ear:

  1. Run the following command:
    <profile>/bin/wsadmin.sh -user <admin> -password <password> -lang jython -port <SOAP_CONNECTOR_ADDRESS>
  2. Then run the following command:
    <wsadmin> AdminApp.export('wp.vwat.servlet.ear','/tmp/wp.vwat.servlet.ear')
  3. Execute the following command:
    <profile>/bin/EARExpander.sh -ear /tmp/wp.vwat.servlet.ear -operationDir /tmp/vwat_expanded -operation expand -expansionFlags all
  4. Modify /tmp/vwat_expanded/wp.vwat.servlet.war/WEB-INF/web.xml (and web_merged.xml, if it exists) and map the filter to the appropriate URL(s).
    For example (the filter-class should be in <PortalServer_root>/shared/app/ or a shared library):
    <filter>
    <filter-name>Sample Request Filter</filter-name>
    <filter-class>com.hcl.dx.SampleRequestFilter</filter-class>
    </filter>
    <filter-mapping>
    <filter-name>Sample Request Filter</filter-name>
    <url-pattern>/*</url-pattern>
    </filter-mapping>
  5. Save the modified web.xml.
  6. Run the following command:
    <profile>/bin/EARExpander.sh -ear /tmp/wp.vwat.servlet.ear -operationDir /tmp/vwat_expanded -operation collapse
  7. Then run the following:
    AdminApp.update('wps', 'app', ['-operation', 'update', '-contents', '/tmp/wp.vwat.servlet.ear', '-deployejb.classpath', '<PortalServer_root>/base/wp.base/shared/app/wp.base.jar'])
  8. Execute the following:
    AdminConfig.save()
  9. Sychronize the nodes, if clustered.
  10. Restart the JVM(s).

Sample code for a WAB filter converted to a servlet filter:
package com.hcl.dx;
import java.io.IOException;
import javax.naming.Context;
import javax.naming.InitialContext;
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 javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;
import com.ibm.portal.um.Principal;
import com.ibm.portal.um.PumaHome;
import com.ibm.portal.um.PumaProfile;
import com.ibm.portal.um.User;
public class SampleRequestFilter implements Filter {
private PumaHome ph;
@Override
public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain)
throws IOException, ServletException
{ SampleRequestWrapper wrappedReq = new SampleRequestWrapper(req); chain.doFilter(wrappedReq, resp); }
public void destroy()
{ // do nothing }
public void init(FilterConfig arg0) throws ServletException {
try
{ Context ic = new InitialContext(); ph = (PumaHome)ic.lookup("portal:service/usermanagement/Puma"); ic.close(); }
catch (Throwable t)
{ t.printStackTrace(); }
}


public class SampleRequestWrapper extends HttpServletRequestWrapper {

SampleRequestWrapper(ServletRequest req) { super((HttpServletRequest) req); }

/*
* NOTE: This is only a proof of concept implementation.
* 
* Other methods may require overriding too, like:
* - getQueryString()
* - getParameter(String)
* - getParameterMap()
* - getPathInfo()
* - getRequestURI()
*/ 

@Override
public StringBuffer getRequestURL() {
// Example of using PUMA in a servlet filter
String userPath = "ldap";
try {
@SuppressWarnings("deprecation")
PumaProfile pp = ph.getProfile(getRequest());
User cu;
cu = pp.getCurrentUser();
if (pp.getIdentifier((Principal) cu).contains("defaultWIMFileBasedRealm")) { userPath = "file"; } 
} catch (Throwable t) { t.printStackTrace(); }
final StringBuffer originalUrl = ((HttpServletRequest) getRequest()).getRequestURL();
return new StringBuffer (originalUrl + "/" + userPath);
}
}
}
"