CRE Proxy Configuration
For communication, the Common Rendering Engine (CRE) proxy leverages two proxy configuration files: the external proxy configuration proxy-opensocial-config.pl file and the internal proxy configuration proxy-opensocial-internal-config.tpl file.
Purpose
- The external proxy configuration, which is used to communicate between gadgets and external servers, is the proxy-opensocial-config.tpl file located in the LotusConnections-config directory. It is hidden by default and can be overridden by creating a proxy-opensocial-config.tpl file . The file can be customized to meet your needs. Also, by default this proxy sends all cookies passed to it via the browser, so if you want to limit that, you must create the proxy config file. For more information about the external proxy, refer to Configuring the AJAX proxy.
- The internal proxy configuration is leveraged for internal server-to-server communication by
Shindig/CRE. This file is hidden by default but can overridden by placing a
proxy-opensocial-internal-config.xml
file into the LotusConnections-config directory. Rarely, if ever, would you have to modify this file, but if setting changes are found to be needed during performance testing, these changes should be included into the default file.
The external Proxy configuration: proxy-opensocial-config.tpl
For the external proxy configuration, CRE has been extended to read the proxy-opensocial-config.tpl file. This file works with the extension of gadget-specific proxy constructs. These gadget specific constructs are ignored by the standard Connections proxy, but utilized by the CRE proxy. The companion fileproxy-config.dynamic
controls which of those endpoints the gadget is permitted to
make outbound requests to, while the proxy-opensocial-config.tpl file controls
the characteristics (headers/cookies/and so on) of your gadget's communication to that
endpoint.Gadget-specific proxy constructs
- managed-headers
- Purpose: Provides a set of headers that will be specially rewritten
and passed to the gadget. The proxy helps to ensure that these headers
are as follows:
Placement is as a peer of //policy/headers
Content contains <managed-header> element. This element contains a text node that specifies the 'header' that is to be managed.
For example:<proxy:actions> ... </proxy:actions> <proxy:headers /> <proxy:managed-headers> <proxy:managed-header>X-LConn-Auth</proxy:managed-header> <proxy:managed-headers> ... <proxy:policy>
- managed-cookies
- Purpose: Provides a set of headers that will be specially rewritten and passed to the specific gadget. The cookie rewriting ensures that multiple gadgets loaded in the same domain do not overwrite cookie values for each other. The proxy then handles rewriting the cookie back to its original form.
The Internal Proxy Config: proxy-opensocial-internal-config.tpl file
Typically you should not have to modify this file. For performance testing however, the ability to modify the file can be extremely useful if modifications need to be made. In order to override the default configuration, paste the following sample into a file calledproxy-opensocial-internal-config.tpl
in the
LotusConnections-config directory. The following is a sample proxy-opensocial-internal-config.tpl
file:<?xml version="1.0" encoding="UTF-8"?>
<proxy:config id="proxy-opensocial-internal-config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.0">
<proxy:proxy-rules>
<proxy:mapping contextpath="/*" />
<proxy:policy url="*" acf="none" basic-auth-support="true" auth-support="true">
<proxy:actions>
<proxy:method>GET</proxy:method>
<proxy:method>POST</proxy:method>
<proxy:method>PUT</proxy:method>
<proxy:method>DELETE</proxy:method>
</proxy:actions>
<proxy:headers>
<proxy:header>*</proxy:header>
<proxy:header>Authorization</proxy:header>
</proxy:headers>
<proxy:cookies>
<proxy:cookie>DomAuthSessId</proxy:cookie>
<proxy:cookie>LtpaToken</proxy:cookie>
<proxy:cookie>LtpaToken2</proxy:cookie>
<proxy:cookie>Shimmer</proxy:cookie>
<proxy:cookie>ShimmerS</proxy:cookie>
<proxy:cookie>JSESSIONID</proxy:cookie>
</proxy:cookies>
</proxy:policy>
<proxy:meta-data>
<proxy:name>socket-timeout</proxy:name>
<proxy:value>30000</proxy:value>
</proxy:meta-data>
<proxy:meta-data>
<proxy:name>connection-timeout</proxy:name>
<proxy:value>30000</proxy:value>
</proxy:meta-data>
<proxy:meta-data>
<proxy:name>retries</proxy:name>
<proxy:value>2</proxy:value>
</proxy:meta-data>
<proxy:meta-data>
<proxy:name>max-connections-per-host</proxy:name>
<proxy:value>100</proxy:value>
</proxy:meta-data>
<proxy:meta-data>
<proxy:name>max-total-connections</proxy:name>
<proxy:value>200</proxy:value>
</proxy:meta-data>
<proxy:meta-data>
<proxy:name>unsigned_ssl_certificate_support</proxy:name>
<proxy:value>true</proxy:value>
</proxy:meta-data>
</proxy:proxy-rules>
</proxy:config