Examples of AJAX proxy configurations

Examples of AJAX proxy configurations

The following two examples show sample proxy-config.xml files that you can use as templates to define own configurations. You can use these samples as a base to write own AJAX proxy configuration

Example: Generic proxy configuration to access multiple target hosts
You can use the configuration shown below for applications that need to connect to several different target hosts. For example, this can be a feed reader portlet that can be configured with the feed URL. Accordingly, the configuration defines only one context path mapping element, which is used for all incoming requests. The specified access policy restricts the set of allowed HTTP operations to GET and HEAD. It does not declare any mime type elements, that is, the proxy does not filter the received HTTP responses based on their content type header.
<?xml version="1.0" encoding="UTF-8"?>
<proxy:proxy-rules
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.0">
   <proxy:mapping contextpath="/proxy" url="*" />
   <proxy:policy url="*" acf="none">
      <proxy:actions>
         <proxy:method>GET</proxy:method>
         <proxy:method>HEAD</proxy:method>
      </proxy:actions>
   </proxy:policy>
   <proxy:meta-data>
      <proxy:name>max-connections-per-host</proxy:name>
      <proxy:value>10</proxy:value>
   </proxy:meta-data>
   <proxy:meta-data>
      <proxy:name>max-total-connections</proxy:name>
      <proxy:value>150</proxy:value>
   </proxy:meta-data>
</proxy:proxy-rules>
Example: Proxy configuration to access a specific target host
In contrast to the example shown above, the second example is meant for applications which connect to only one specific data source. For example, this can be an external REST service. The example shows how to connect to a REST service that offers read and write access to a knowledge base that provides articles. Accordingly, the configuration declares one context path mapping, which maps the context path "/knowledge" to the URL pattern "http://mycompany.com:8081/knowledgebase".
<?xml version="1.0" encoding="UTF-8"?>
<proxy:proxy-rules
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.0">
   <proxy:mapping contextpath="/knowledge" url="http://mycompany.com:8081/knowledgebase" />
   <proxy:policy url="http://mycompany.com:8081/knowledgebase/abstracts/*" acf="none">
      <proxy:actions>
         <proxy:method>GET</proxy:method>
         <proxy:method>HEAD</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy:proxy-rules>
Example: Map-specific access policies
This example shows how you can declare access policies inside of a mapping element.
<proxy:proxy-rules
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.1">
   <proxy:mapping contextpath="/proxy/*" />
   <proxy:mapping contextpath="/myproxy/*">        
      <proxy:policy url="*" acf="none">
         <proxy:actions>
            <proxy:method>GET</proxy:method>
            <proxy:method>PUT</proxy:method>
            <proxy:method>POST</proxy:method>
            <proxy:method>DELETE</proxy:method>
         </proxy:actions>
      </proxy:policy>
   </proxy:mapping>
   <proxy:policy url="*" acf="none">
      <proxy:actions>
         <proxy:method>GET</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy:proxy-rules>
In the sample configuration shown above, the "/proxy" mapping represents a "public" entry point that must be restricted, as every user has access to it. The "/myproxy" mapping is already restricted, because only authenticated users can access it. Consequently, access policies set for "/myproxy" can be less strict than policies for "/proxy". Accordingly, the access policy for "/proxy" accepts only HTTP GET requests, whereas the access policy for "/myproxy" accepts HTTP GET, PUT, POST and DELETE requests.

Example: Filtering IP addresses via the proxy configuration
The sample configuration below shows how to use IP filtering rules:
<proxy:proxy-rules
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    
   xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.1">
   <proxy:mapping contextpath="/proxy/*" />
   <proxy:ipfilter>
      <proxy:deny>9.6.0.0/255.255.0.0</proxy:deny>
      <proxy:allow>9.6.1.0/255.255.255.0</proxy:allow>
      <proxy:deny>9.6.1.4</proxy:deny>
   </proxy:ipfilter>
   <proxy:policy url="*" acf="none">
      <proxy:actions>
         <proxy:method>GET</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy:proxy-rules>
The declared IP filter determines that all 9.6.*.* IP addresses are blocked, whereas all 9.6.1.* IP addresses are allowed, except for the specific IP address 9.6.1.4. Consequently, the proxy does not allow you to access IP address 9.6.2.5 or 9.6.120.7. Instead, the proxy responds with a 403 status code and an error message. The IP addresses 9.6.1.5 or 9.6.1.120 are accessible.

Example: Configure the AJAX proxy to support single sign-on
This example shows how you configure the proxy to support single sign-on. The configuration makes the proxy forward the respective LTPA and JSessionID cookies LTPA tokens.
<proxy:proxy-rules
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    
   xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.1">
   ...
   <proxy:policy url="http://mycompany.com/*" acf="none">
      <proxy:actions>
         <proxy:method>GET</proxy:method>
         <proxy:method>HEAD</proxy:method>
         <proxy:method>POST</proxy:method>
         <proxy:method>PUT</proxy:method>
         <proxy:method>DELETE</proxy:method>
      </proxy:actions>
      <proxy:cookies>
         <proxy:cookie>LTPAToken</proxy:cookie>
         <proxy:cookie>LTPAToken2</proxy:cookie>
         <proxy:cookie>JSESSIONID</proxy:cookie>
      </proxy:cookies>
      <proxy:users>
         <proxy:user>AllAuthenticatedUsers</proxy:user>
      </proxy:users>
   </proxy:policy>
   ...
</proxy:proxy-rules>
Example: Enable support for basic authentication
This example shows you how you can enable support for basic authentication by setting the basic-auth-support attribute for a policy:
<proxy-rules
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.1">
   <proxy:mapping contextpath="/proxy/*" />
   <proxy:policy url="*" acf="none" basic-auth-support="true">
      <proxy:actions>
         <proxy:method>GET</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy-rules>
In this example the proxy forwards the basic authentication related HTTP status and error codes and the required headers to the target host and then back to the client. For example, the error code can be 401 Authorization Required, and the header can be the authorization header.

Parent
The proxy-config.xml file
Access policies
Context path mappings
IP filtering
General configuration parameters

+
Search Tips | Advanced Search