+

Search Tips   |   Advanced Search

Configure the AJAX proxy for a specific application


Overview

The AJAX proxy configuration for all of the Connections applications is defined in proxy-config.tpl. To specify different AJAX proxy settings for a specific application only, we create a new, application-specific version of proxy-config.tpl.

This task is not typically required. Only perform it to display information from an external service within Connections, for example, to enable feeds from external sites,. We can define a custom proxy configuration for the Activities, Communities, Home page, Profiles, and Search applications, but not the other Connections applications.

By default, the Connections AJAX proxy is configured to allow cookies, headers or mime types, and all HTTP actions to be exchanged among the Connections applications. To change the traffic allowed from non-IBM Connections services, we must explicitly configure it


Configure the AJAX proxy for a specific application

  1. Make a a copy of proy-config.tpl...

      cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/cell/LotusConnections-config
      cp proxy-config.tpl proxy-app-config.tpl

    ...where app be activities, communities, homepage, profiles, or search.

  2. Check out the copied configuration file...

      cd app_server_root/profiles/Dmgr01/bin
      ./wsadmin.sh -lang jython -user wasadmin -password admin_password
      execfile("py_file_name")

    ...where py_file_name is one of the following...

    • activitiesAdmin.py
    • communitiesAdmin.py
    • homepageAdmin.py
    • profilesAdmin.py
    • searchAdmin.py

  3. Check out configuration service for the application...

    To determine cell name:

  4. Edit /tmp/proxy-app-config.tpl

    • To explicitly refuse all traffic from a specific site:

        <proxy:policy url="malicious.site.com" acf="none">
        
            <proxy:actions/>
            <proxy:headers/>
            <proxy:cookies/>
        
        </proxy:policy>

    • To allow a particular service on the network to display a custom widget:

        <proxy:policy url="http://my.network.com/widget/*" acf="none">
        
            <proxy:actions>
                <proxy:method>GET</proxy:method>
            </proxy:actions>
        
            <proxy:headers>
              <proxy:header>User-Agent</proxy:header>
              <proxy:header>Accept.*</proxy:header>
              <proxy:header>Content.*</proxy:header>
              <proxy:header>Authorization.*</proxy:header>
              <proxy:header>If-.*</proxy:header>
              <proxy:header>Pragma</proxy:header>
              <proxy:header>Cache-Control</proxy:header>
            </proxy:headers>
        
            <proxy:cookies>
                <proxy:cookie>JSESSIONID</proxy:cookie>
            </proxy:cookies>
        
        </proxy:policy>

    • If a service requires authentication, to allow basic authentication requests, add a basic-auth-support="true" attribute to the <proxy:policy> element:

        <proxy:policy url="http://my.network.com/service/*" 
                      acf="none" 
                      basic-auth-support="true">
                      ...
        
        </proxy:policy>
      If this attribute is not added, when an unauthenticated request is sent to a service that requires authentication, the service does not display the basic authentication dialog, but returns an HTTP 403 status code instead.

    • To allow a particular service to run on the network, and to pass cookies for LTPA tokens to the applications:

        <proxy:policy url="http://my.network.com/service/*" acf="none">
        
            <proxy:actions>
                <proxy:method>GET</proxy:method>
            </proxy:actions>
        
            <proxy:headers>
              <proxy:header>User-Agent</proxy:header>
              <proxy:header>Accept.*</proxy:header>
              <proxy:header>Content.*</proxy:header>
              <proxy:header>Authorization.*</proxy:header>
              <proxy:header>If-.*</proxy:header>
              <proxy:header>Pragma</proxy:header>
              <proxy:header>Cache-Control</proxy:header>
            </proxy:headers>
        
            <proxy:cookies>
              <proxy:cookie>JSESSIONID</proxy:cookie>
              <proxy:cookie>LtpaToken</proxy:cookie>
              <proxy:cookie>LtpaToken2</proxy:cookie>
            </proxy:cookies>
        
        </proxy:policy>

      Specify the headers using regular expressions. If no cookies are specified, the proxy will pass all of them. To prevent it from passing any cookies, specify <proxy:cookies/>.

    • To allow a particular service to run on the network configured with SSO, and to pass cookies for LTPA tokens and TAM or Siteminder to the service, use the following <proxy:cookies> pattern:

        <proxy:policy 
             url=" http://my.network.com/service/*"
             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>content-type</proxy:header>
                 <proxy:header>accept-encoding</proxy:header>
                 <proxy:header>uit</proxy:header>
                 <proxy:header>pst</proxy:header>
                 <proxy:header>User-Agent</proxy:header>
                 <proxy:header>Accept.*</proxy:header>
                 <proxy:header>Content.*</proxy:header>
                 <proxy:header>Authorization.*</proxy:header>
                 <proxy:header>X-Method-Override</proxy:header>
                 <proxy:header>If-.*</proxy:header>
                 <proxy:header>Pragma</proxy:header>
                 <proxy:header>Cache-Control</proxy:header>
                 <proxy:header>X-Update-Nonce</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>iwaSSL</proxy:cookie>
                 <proxy:cookie>iwaSSL2</proxy:cookie>
                 <proxy:cookie>JSESSIONID</proxy:cookie>
                 <proxy:cookie>has</proxy:cookie>
                 <proxy:cookie>PD-H-SESSION-ID</proxy:cookie><!-- TAM -->
                 <proxy:cookie>PD-S-SESSION-ID</proxy:cookie><!-- TAM -->
                 <proxy:cookie>SMIDENTITY</proxy:cookie><!-- SiteMinder -->
                 <proxy:cookie>SMSESSION</proxy:cookie><!-- SiteMinder -->
             </proxy:cookies>
        
         </proxy:policy>

    • The following policy allows GET requests to be passed to any web address.

      To allow your users to have access to all web sites, remove the comments from around this policy. For example, users who add a feed to a community will see a 403 error where the feed results should be displayed unless you perform this step. Be sure the policy is listed as the last policy in the configuration file.

        
        <!--proxy:policy url="*" acf="none"> 
        
            <proxy:actions>
              <proxy:method>GET</proxy:method>
        
            </proxy:actions>
            <proxy:headers/>
            <proxy:cookies/>
        
        </proxy:policy-->

      Do not enable this policy on internet-facing deployments because it can allow unauthorized access to internal servers.

  5. Specify values for proxy:meta-data properties. For example:
      <proxy:meta-data>
        <proxy:name>maxconcurrentconnections</proxy:name>
        <proxy:value>20</proxy:value>
      </proxy:meta-data> 

    For example...

      circular_redirects Circular redirects are allowed. true or false. Setting true supports using a proxy for a site that redirects to the same URL, but with different parameters. Such a change is not recognized as a new URL. Default is true.
      connection-timeout Amount of time before an attempt to connect to a host times out. Milliseconds. The default is 60,000, which is 1 minute.
      max_circular_redirects Maximum number of times a circular redirect is allowed before the proxy rejects it. Integer. Default is 100.
      maxconnectionsperhost Maximum number of simultaneous connections between the proxy and a given host. Integer. Default is 5.
      maxtotalconnections Maximum number of simultaneous connections between the proxy and all of the hosts together. Integer. Default is 10.
      socket-timeout Amount of time before an attempt to use a socket times out. Milliseconds. The default is 60,000, which is 1 minute.
      unsigned_ssl_certificate_support Support self-signed SSL certificates. This property accepts a Boolean value of true or false specified in lower-case letters. Default is true. Change to false when the system is ready for production.

    Add any custom configurations before these proxy:meta-data elements.

    The purpose of the following three settings is to prevent the proxy from consuming all available container threads while it waits for a response from a target host that is slow or is not responding.

      maxconcurrentconnections Limit the number of threads that can be active in the proxy at any one time. When the limit is reached, all subsequent threads immediately return with a HTTP 504 Gateway Timeout error. If the value is 0, no limit is set. The default setting is 10, which is used if the value is missing or not valid.
      suspend-url-timeout-interval Minimum amount of time, in milliseconds, that a host is on the suspend list. A host is placed on the suspend list when the host times out. When a host is on the suspend list, the proxy rejects all requests to that host and returns a HTTP 504 Gateway Timeout error for that host. After the timeout interval expires, the host remains on the suspend list, but the next request is accepted. If the request succeeds, the host is removed from the suspend list. If the request does not succeed, the host remains on the suspend list and the timeout interval is renewed. The maximum value is 120000 (2 minutes). A value of 0 disables the timeout interval feature. Default is 2000, which is used if the value is missing or not valid.
      clean-url-timeout-interval Maximum amount of time, in milliseconds, that a host is on the suspend list. The minimum value is 180000 (30 minutes). Default is 14400000, which is used if the value is missing or not valid.

  6. Save and close the file.

  7. Check in the file...

  8. Restart the WAS hosting IBM Connections.


What to do next

To make subsequent changes to the application-specific proxy template file, repeat steps 2 through 9 to check out the file, make your updates, and check the file back in again.


Parent topic:
Configure the AJAX proxy