+

Search Tips   |   Advanced Search

Examples of AJAX proxy configurations


The following two examples show sample proxy-config.xml file that we can use as templates to define our own configurations. We can use these samples as a base to write our own AJAX proxy configuration


Example: Generic proxy configuration to access multiple target hosts

We can use the following configuration 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 elementso 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.2">
   <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 previous example, 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 baso 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.2">
   <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 we 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.2">
   <proxy:mapping contextpath="/proxy/*" url="*" />
   <proxy:mapping contextpath="/myproxy/*" url="*" >
      <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 previous sample configuration, 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 following sample configuration 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.2">
   <proxy:mapping contextpath="/proxy/*" url="*" />
   <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 us 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.2">
   ...
   <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 we 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.2">
   <proxy:mapping contextpath="/proxy/*" url="*" />
   <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
Related:
Access policies
Context path mappings
IP filtering
General configuration parameters