Global proxy configuration

Global proxy configuration

The portal also provides a global proxy configuration. By default it applies to all applications that use the AJAX proxy.
Alternatively, applications can also provide their own proxy configuration. For details refer to the following topic about application specific proxy configurations.
The global proxy configuration of the portal is located in a separate enterprise application that is deployed during the portal installation. The corresponding enterprise application archive is named AJAX Proxy Configuration.ear. The file proxy-config.xml that represents the global configuration is located in the WAR file wp.config.proxy.war. That file is part of the EAR file and located in the WEB-INF directory.

Customize the global proxy configuration by using the AJAX proxy configuration.ear
To update the global proxy configuration, copy the original file proxy-config.xml from the location given above, modify it as required, and run the configuration task checkin-wp-proxy-config by the following syntax:
Cluster note: In a clustered environment, run this task on the primary node.
ConfigEngine. [bat|sh] checkin-wp-proxy-config -DProxyConfigFileName=dir_path/your_updated_proxy_file.name
where dir_path/your_updated_proxy_file.name is the complete path of modified wp.proxy.config.xml file.
This imports the global proxy configuration into a property in the WP ConfigService Resource Environment Provider (REP) with the name proxy.config.file . To make the changes effective after running the task you do not need to restart the entire portal server, but only the enterprise application.
The following rules apply:

For equal element settings: If there is a property proxy.config.file in the REP and if the settings of that property are under the same mapping element, that is under the same context path and URL if present, then these settings overrule the element settings from the default proxy-config.xml file.
For individual policy or IP address element settings in the configuration:

A policy in the REP overrules a policy of the same URL pattern from the default file.

An IP address configuration in an ipfilter element in the REP also overrules settings for the same IP address from the default file.
Consequently policies and IP addresses that are only in the default file but not in the REP have no relevance. To be effective, they need to be in the REP as well.

For different policy elements: Policy elements under the same mapping with a different URL pattern from the REP and the default file complement one another so that both are valid.
Refer to the following two examples.
Example of overwriting a policy:
proxy-config.xml file
 
<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:policy url="*" acf="none">
      <proxy:actions>
         <proxy:method>GET</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy:proxy-rules>
 
- RES ENV PROV (REP)
 
<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:policy url="*" acf="none">
      <proxy:actions>
         <proxy:method>PUT</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy:proxy-rules>
 
- resulting config (REP overrules config file)
 
<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:policy url="*" acf="none">
      <proxy:actions>
         <proxy:method>PUT</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy:proxy-rules>
Example of additive policies:
proxy-config.xml file
 
<?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" />   PUT
   <proxy:policy url="http://mycompany.com:8081/knowledgebase/abstracts/*" acf="none">
      <proxy:actions>
         <proxy:method>GET</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy:proxy-rules>
 
- RES ENV PROV (REP)
 
<?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/products/*" acf="none">
      <proxy:actions>
         <proxy:method>PUT</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy:proxy-rules>
 
- resulting config (REP overrules config file)
 
<?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:actions>
   </proxy:policy>
   <proxy:policy url="http://mycompany.com:8081/knowledgebase/products/*" acf="none">
      <proxy:actions>
         <proxy:method>PUT</proxy:method>
      </proxy:actions>
   </proxy:policy>
</proxy:proxy-rules>
Customize the global proxy configuration by using dynamic policy entries
Additional to updating the AJAX proxy configuration enterprise application, you can also customize the effective global AJAX proxy configuration by using the portal WP ConfigService Resource Environment Provider (REP). You do this by matching the values in the WP ConfigService REP with so called dynamic policy entries in the global proxy configuration file. For details about how to do this refer to the topics about the Portal configuration properties and Setting service configuration properties.
A dynamic policy entry differs from a non-dynamic policy entry in that it uses replacement variables instead of URL patterns in the policy element url attribute. A policy element url attribute is considered to be a replacement variable definition if the attribute value starts with the string {$ and ends with the string }. For example, a policy entry url attribute value of {$my.custom.url.target} defines a dynamic policy replacement variable named my.custom.url.target.
You can specify the individual attribute values that you want to be used for replacing the url replacement variable by using corresponding entries in the WP ConfigService REP. The matching is done based on the following custom property naming scheme:
wp.proxy.config.urlreplacement.variable_name.suffix
wp.proxy.config.urlreplacement
This prefix identifies the property to define a dynamic policy replacement value.

variable_name
This variable identifies the target dynamic policy element in the global proxy configuration file.

suffix
This suffix represents a string of choice that makes the key unique within all replacement keys that refer to the same dynamic policy replacement variable, if there is more than one.
Example: The default global proxy-config.xml file contains the following dynamic policy entry:
<proxy:policy url="{$default_policy}" acf="none">
   <proxy:actions>
      <proxy:method>GET</proxy:method>
      <proxy:method>HEAD</proxy:method>
   </proxy:actions>
</proxy:policy>
To attach this policy to outbound requests to URLs that match one of the URL patterns http://www.some.server.com/* or http://some.other.server.com/*, you can add the following two custom properties to the WP ConfigService resource environment provider:
wp.proxy.config.urlreplacement.default_policy.1=http://www.some.server.com/*
wp.proxy.config.urlreplacement.default_policy.2=http://some.other.server.com/*
Default global proxy configuration
The default global proxy configuration file allows plain HTTP GET requests to the following URL patterns:

http://www-03.ibm.com/*

http://www.redbooks.ibm.com/*
Furthermore, there are two dynamic policies defined in the default global proxy configuration file:
default_policy
This policy allows plain HTTP GET and HEAD requests.

default_ltpa_policy
This policy allows authenticated HTTP GET and HEAD requests within the WebSphere LTPA token based single sign-on domain.

Parent
AJAX proxy configuration
Minor change Minor change dynamic policy entries strt with {$ - not {\$ Submitted by Sarah Vessels on Feb 6, 2012 3:33:24 PM
Re: Global proxy configuration
Found proxy-config.xml in C:\IBM\WebSphere\wp_profile\config\cells\MY_NODE_NAME\applications\AJAX Proxy Configuration.ear\deployments\AJAX Proxy Configuration\wp.proxy.config.war\WEB-INF Submitted by Konrad Wulf on Feb 2, 2011 6:09:50 AM
Re: Global proxy configuration: wp7
There is a known bug with the interpretation of dynamic policies in custom global proxy configurations in Portal 7.0.0. Should you intend to apply a custom configuration via "ConfigEngine checkin-wp-proxy-config" and you are on 7.0.0, make sure you apply APAR PM31323 first.

+
Search Tips | Advanced Search