Configuring ajax proxy in websphere portal8.0

Ajax :- Using Ajax we can do asynchronous call to server and get chunks of data from server and refresh only particular part in the web page. Ajax has a limitation we can perform operations under same domain only cross domain calls wont be working.

Ajax-proxy :-  Ibm has come up with a new concept called proxy if we configure this we can enable cross domain ajax calls for particular domains.

Enabling ajaxproxy :-  All configurations are done in proxy-config.xml location of file is mentioned below.
C:\IBM\WebSphere\wp_profile\config\cells\WIN-RANE51IRK16Cell\applications\AJAX Proxy Configuration.ear\deployments\AJAX Proxy Configuration\wp.proxy.config.war\WEB-INF\proxy-config.xml :- Make of copy of it and start modifying it to add your custom domain ajax call

Step 1 (Main elements in proxy-config.xml ):-
<policy url="https://www.google.co.in/" acf="none">
<actions>
<method>GET</method>
<method>HEAD</method>
<method>POST</method>
<method>PUT</method>
<method>DELETE</method>
</actions>
<cookies>
<cookie>LTPA</cookie>
<cookie>LTPA2</cookie>
<cookie>LtpaToken</cookie>
<cookie>LtpaToken2</cookie>
<cookie>JSESSIONID</cookie>
</cookies>
<headers>
<header>User-Agent</header>
<header>Accept-Language</header>
<header>Authorization*</header>
<header>Content*</header>
</headers>
                <mime-types>
<mime-type>text/xml*</mime-type>
<mime-type>application/xml*</mime-type>
<mime-type>application/atom+xml*</mime-type>
<mime-type>application/rss+xml*</mime-type>
<mime-type>application/octet-stream*</mime-type>
</mime-types>
</policy>

policy

The policy element is the most important element in the proxy configuration. Use the policy element to define an access policy for a specific URL pattern. A proxy configuration can contain multiple policy definitions. If no policy is specified at all, all incoming requests are denied. For more details about policies, refer to the section about access policies.

mapping

Use the mapping element to map incoming requests to a target URL, based on their context path. Therefore each mapping element needs to specify a contextpath attribute and optionally aurl attribute. Mapping elements can optionally declare policy elements that represent mapping specific access policies. For more details about how to use mapping elements refer to the topic about Context path mappings.

ipfilter

Use ipfilter elements to define one or several IP filtering rules. You can use IP filtering rules to either grant or deny access to a particular IP address or to a set of addresses. For more details about IP filtering rules, refer to the topic about IP filtering.

meta-data

Use the meta-data element to specify general configuration properties of the proxy, for example. HTTP-related parameters. Each meta-data element must have a name subelement and avalue subelement. To get a list of configuration parameters that are available in the portal, refer to the section about general configuration parameters. When you use an XML schema version earlier than Version 1.2, meta-data elements apply only directly under a mapping or a proxy-rules section. Starting with XML schema Version 1.2, selected meta-data elements can also be used within policies. The topic General configuration parameters provides more details on this.

actions

This element is mandatory. Use it to define the list of HTTP methods that can be used to access resources in the target domain. These are GET, HEAD, POST, PUT, DELETE. The proxy denies requests that use HTTP methods that are not on this list. Specify each HTTP method by using a separate method element.

headers

This element is optional. Use it to define the list of header names that you want the proxy to forward to the target domain. The header names an include wildcard characters. If you specify no header names for the policy, the proxy will by default forward headers that match the following name expressions: Cache-Control, Pragma, User-Agent, Accept*, and Content*. Specify each header name by using a separate header element.
Note: The value Cookies is not allowed. Use the cookies element to specify the cookie forwarding behavior for the policy instead. 

mime-types

This element is optional. Use it to specify the list of accepted mime types. The mime types refer to the response that the proxy receives from the target server. If there is at least one mime type specified, the proxy accepts only responses with a Content-Type response header that matches one of the specified mime types. If no mime type is specified, the proxy accepts all responses. Each mime type must be specified using a separate mime-type element. Using wildcard characters when specifying mime types can be useful, as servers might append the character encoding to the mime type. For example, if you specify text/html*, the proxy also accepts responses with Content-Type: text/html; charset=utf-8.

cookies

This element is optional. Use it to define a list of cookie names that identify the cookies that you want the proxy to forward to the target domain. In order to forward cookies, the proxy filters the value of the cookie header according to the defined cookie names. If no cookie names are specified, the proxy forwards no cookies. Specify each cookie name by using a separate cookieelement.
WebSphere® Portal Version 8.0 with APAR PM68149 and later versions support the renaming of LTPA cookies. To dynamically resolve the ltpa token names, use the place holders{$token.ltpa.name} and {$token.ltpa2.name}, respectively.

users

This element is optional. If you specify AllAuthenticatedUsers, the proxy verifies that the request was sent by an authenticated user. Otherwise the proxy rejects the request. Other user groups are not supported at this time.

Step 2 (Modify proxy-config.xml ):- We need to add policy as mentioned above for google. Like that we can add as many as we can. After modifying the copied version of proxy-config.xml we need to run a configuration task to update the proxy-config.xml

ConfigEngine. bat  checkin-wp-proxy-config
      -DProxyConfigFileName=dir_path/your_updated_proxy_file.name
      -DWasUserId=admin_user_id -DWasPassword=admin_password


Replace the parameter values as follows:
dir_path/your_updated_proxy_file.name is the complete path of your modified wp.proxy.config.xml file.
admin_password is the IBM® WebSphere® Application Server user ID.
admin_password is the password for the WebSphere Application Server user ID.

Step 3 :- Restart the server or start and stop the proxy application in was server.

Step 4 :- Now we need to construct a url for our server in combination with proxy url to perform a ajax proxy operation. The proxy can be addressed via URLs that comply with the REST-based URL format given here.

This format is as follows:
<protocol>://<portal-domain>/<proxyurl>/<protocol>/<host>%3a<port>/<url>?<query>

The proxy URL carries the target URL in its path information part. Depending on the context path mapping in the proxy configuration, the target URL can be an absolute or relative URL.

Examples: Refer to the following sample proxy URLs. They show how you can load a URL via the proxy depending on the context path mapping in the proxy configuration.

URL: http://www.ibm.com/developerworks/news/dw_dwtp.rss
Context path mapping (from proxy-config.xml): <mapping contextpath="/proxy" url="*"/>
Proxy URL: http://myportal.com:10040/wps/proxy/http/www.ibm.com/developerworks/news/dw_dwtp.rss

Google ajax proxy :- http://localhost:10039/wps/proxy/http/www.google.co.in/

Final proxy-config.xml :- 

<?xml version="1.0" encoding="UTF-8"?>
<proxy-rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.2">
<mapping contextpath="/proxy" url="*"/>
    <mapping contextpath="/myproxy" url="*"/>
    <mapping contextpath="/common_proxy" url="*"/>
    <mapping contextpath="/cmis_proxy" url="*" />
<policy url="https://www.google.co.in/" acf="none">
<actions>
<method>GET</method>
<method>HEAD</method>
<method>POST</method>
<method>PUT</method>
<method>DELETE</method>
</actions>
<cookies>
<cookie>LTPA</cookie>
<cookie>LTPA2</cookie>
<cookie>LtpaToken</cookie>
<cookie>LtpaToken2</cookie>
<cookie>JSESSIONID</cookie>
</cookies>
<headers>
<header>User-Agent</header>
<header>Accept-Language</header>
<header>Authorization*</header>
<header>Content*</header>
</headers>
</policy>

<policy url="http://www.ibm.com/*" acf="none">
<actions>
<method>GET</method>
</actions>
</policy>
<policy url="http://www-03.ibm.com/*" acf="none">
<actions>
<method>GET</method>
</actions>
</policy>
<policy url="http://www.redbooks.ibm.com/*" acf="none">
<actions>
<method>GET</method>
</actions>
</policy>
<policy url="{$default_ltpa_policy}" acf="none">
<actions>
<method>GET</method>
<method>HEAD</method>
</actions>
<cookies>
<cookie>LtpaToken</cookie>
<cookie>LtpaToken2</cookie>
</cookies>
</policy>
<policy url="{$default_policy}" acf="none">
<actions>
<method>GET</method>
<method>HEAD</method>
</actions>
</policy>
<policy url="{$federated_documents_policy}" acf="none" basic-auth-support="true">
<actions>
<method>GET</method>
<method>HEAD</method>
<method>POST</method>
<method>DELETE</method>
<method>PUT</method>
</actions>
<cookies>
<cookie>LtpaToken</cookie>
<cookie>LtpaToken2</cookie>
</cookies>
<headers>
<header>User-Agent</header>
<header>Accept*</header>
<header>Content*</header>
<header>Authorization*</header>
<header>X-Method-Override</header>
<header>Set-Cookie</header>
<header>If-Modified-Since</header>
<header>If-None-Match</header>
<header>X-Server</header>
<header>X-Update-Nonce</header>
<header>X-Requested-With</header>
<header>com.ibm.lotus.openajax.virtualhost</header>
<header>com.ibm.lotus.openajax.virtualport</header>
</headers>
<meta-data>
            <name>forward-credentials-from-vault</name>
            <value>true</value>
        </meta-data>
</policy>
    <policy url="{$ibm_connections_policy}" acf="none" basic-auth-support="true">
<actions>
<method>GET</method>
<method>HEAD</method>
<method>POST</method>
<method>PUT</method>
<method>DELETE</method>
</actions>
<cookies>
<cookie>LTPA</cookie>
<cookie>LTPA2</cookie>
<cookie>LtpaToken</cookie>
<cookie>LtpaToken2</cookie>
<cookie>JSESSIONID</cookie>
<cookie>PD-H-SESSION-ID</cookie>
<cookie>PD-S-SESSION-ID</cookie>
<cookie>SMSESSION</cookie>
</cookies>
<headers>
<header>User-Agent</header>
<header>Accept-Language</header>
<header>Authorization*</header>
<header>Content*</header>
</headers>
        <meta-data>
            <name>forward-credentials-from-vault</name>
            <value>true</value>
        </meta-data>
</policy>
    <policy url="{$resource_manager_policy}" acf="none" basic-auth-support="true">
<actions>
<method>GET</method>
<method>PUT</method>
<method>HEAD</method>
</actions>
<headers>
          <header>User-Agent</header>
          <header>Content*</header>
          <header>Accept*</header>
          <header>Pragma</header>
</headers>
<mime-types>
<mime-type>text/xml*</mime-type>
<mime-type>application/xml*</mime-type>
<mime-type>application/atom+xml*</mime-type>
<mime-type>application/rss+xml*</mime-type>
<mime-type>application/octet-stream*</mime-type>
</mime-types>
        <meta-data>
            <name>forward-credentials-from-vault</name>
            <value>true</value>
        </meta-data>
</policy>
<meta-data>
<name>socket-timeout</name>
<value>10000</value>
</meta-data>
<meta-data>
<name>retries</name>
<value>2</value>
</meta-data>
<meta-data>
<name>max-connections-per-host</name>
<value>5</value>
</meta-data>
<meta-data>
<name>max-total-connections</name>
<value>100</value>
</meta-data>
</proxy-rules>

The proxy returns its response with one of the following status codes:
200 OK

This code indicates that the request was accepted by the proxy and that the target server returned a response with a status code 200. This means that the request complied with one of the access policies that you specified in the proxy configuration.

400 Bad Request

The proxy returns this code if the syntax of the request was incorrect.

403 Forbidden

The proxy returns this code in either of the following two cases:

• The request was not accepted by the proxy, that is the proxy found no matching access policy that grants access to the target server.
• Basic authentication failed. 

404 Not found

This code indicates that the proxy accepted the request, but the target server either returned status code 404 itself or a different 4xx error code.

302 Found

This code indicates that the authentication was successful.

Step 6 (optional if using in theme. Still it works if below is not configured):- To use ajax proxy in portlet

The easiest way to create proxy URLs in a portlet is to register the AJAX proxy servlet in the web.xml file of the portlet. This allows you to create the base proxy URL by using the portlet API, whereas you append the target URL according to the URL format specified in the section about the URL format. The class name of the proxy servlet iscom.ibm.wps.proxy.servlet.ProxyServlet. For more details refer to the sample web.xml file.

If you want the proxy to be able to access resources that require authentication, specify a second servlet mapping that is associated with a security constraint. In the sample, only authenticated users can access proxy URLs that match the URL pattern /myproxy/*. 

Note: You must associate the user roles that you specify in the web.xml file with the user roles of the portal server. You can do this by creating the corresponding role mappings for the respective application in the WebSphere® Integrated Solutions Console.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" ...>

   ...

   <servlet>

      <servlet-name>ProxyServlet</servlet-name>

      <servlet-class>com.ibm.wps.proxy.servlet.ProxyServlet</servlet-class>

   </servlet>

   ...

   <servlet-mapping>

      <servlet-name>ProxyServlet</servlet-name>

      <url-pattern>/proxy/*</url-pattern>

   </servlet-mapping>

   <servlet-mapping>

      <servlet-name>ProxyServlet</servlet-name>

      <url-pattern>/myproxy/*</url-pattern>

   </servlet-mapping>

   ...

   <security-constraint id="SecurityConstraint_1">

      <web-resource-collection id="WebResourceCollection_1">

         <web-resource-name/>

         <url-pattern>/myproxy/*</url-pattern>

         <http-method>GET</http-method>

         <http-method>POST</http-method>

         <http-method>PUT</http-method>

         <http-method>HEAD</http-method>

      </web-resource-collection>

      <auth-constraint id="AuthConstraint_1">

         <description>only for authenticated</description>

         <role-name>All Role</role-name>

      </auth-constraint>

   </security-constraint>

   ...

   <security-role id="SecurityRole_1">

      <description>Everyone</description>

      <role-name>Everyone Role</role-name>

   </security-role>

   <security-role id="SecurityRole_2">

      <description>All authenticated users</description>

      <role-name>All Role</role-name>

   </security-role>

</web-app>

Registering the proxy servlet in the Web deployment descriptor of a portlet does not imply that the portlet is based on an application specific configuration. If no proxy-config.xml file is provided with the portlet, the proxy servlet uses the global proxy configuration instead. The only constraint that you need to consider is that for each servlet mapping, a corresponding context path mapping must exist in the proxy configuration. This can be either in the global or in the application specific configuration. For details on how to configure the AJAX proxy refer to the section about AJAX proxy configuration.