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.xmthat 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. Example of full directory location: 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
Customize the global proxy configuration using the AJAX proxy configuration.ear
To update the global proxy configuration, copy the original file proxy-config.xml from the location, modify it as required, and run 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.namewhere dir_path/your_updated_proxy_file.name is the complete path of the 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 on that property are under the same mapping elements 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 addressethat 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 using dynamic policy entries
Additional to updating the AJAX proxy configuration enterprise application, we can also customize the effective global AJAX proxy configuration 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 is 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.
We can specify the individual attribute values to be used for replacing the url replacement variable 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 the choicthat 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/*, we 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 LTPA token based single sign-on domain.
Parent: AJAX proxy configuration
Related:
community pages