El archivo proxy-config.xml define la política mediante la cual las peticiones URI pueden pasar a través del proxy y cómo se correlacionan las vías de acceso de contexto del cliente con el URI en un servidor.
Puede modificar el archivo proxy-config.xml con un editor de texto. Guarde este archivo en una ubicación en la vía de acceso de clases que pueda localizar el servidor proxy. Los cambios en el archivo proxy-config.xml no son dinámicos; reinicie el servlet para que se apliquen los cambios.
Suponga un archivo EAR (enterprise archive) de Java EE (JavaTM Platform, Enterprise Edition) que contiene la aplicación basada en Ajax. Se utiliza Dojo Toolkit para combinar el contenido que se origina en el otro servidor y proporciona la información de ubicación de cafés. El formato de datos se devuelve desde otro servidor como datos JSON (JavaScriptTM Object Notation). Combine los datos JSON devueltos con la aplicación basada en Ajax que está desarrollando, a menudo denominada mashup de lado del cliente.
Escriba las siguientes líneas de código:
GET http://www.myinformation.com/location/coffee HTTP/1.1Se devuelve el siguiente contenido JSON:
{ "locations":{ "location":[ { "id":"Jumpin Joes Example", "city":"Anywhere", "location":"Weston Pkwy", "address":"126 Weston Pkwy, Anywhere, NC 27513", "date":"May 2nd, 2008" }, { "id":"Coffee & Crepes Example", "city":"Anywhere", "location":"Crossroads Blvd", "address":"123 Crossroads Blvd, Anywhere, NC 27518", "date":"May 3rd, 2008" } ] } }
Utilizando el proxy Ajax, puede conseguir el servicio esté disponible añadiendo las siguientes líneas al archivo proxy-config.xml:
<?xml version="1.0" encoding="UTF-8"?> <proxy-rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:proxy="http://www.ibm.com/xmlns/prod/websphere/featurepack/v6.1/proxy-config" xsi:noNamespaceSchemaLocation="C:\temp\proxy-config.xsd"> <proxy:mapping contextpath="/location/coffee" url="http://www.myinformation.com"/> <proxy:policy url="*" acf="none"> <proxy:actions> <proxy:method>GET</proxy:method> </proxy:actions> </proxy:policy> </proxy-rules>
El vía de acceso de contexto anterior es la raíz de contexto del servicio al que se está accediendo. El URL es el URL raíz para el servicio. Como ejemplo, podría acceder al servicio directamente en un navegador utilizando http://www.myinformation.com/location/coffee
La vía de acceso para acceder al proxy en el código depende de cómo se haya desplegado el proxy Ajax. Suponga el fragmento de XML desde un web.xml que se pueda utilizar para el proxy Ajax:
<servlet-mapping> <servlet-name>ProxyServlet</servlet-name> <url-pattern>/proxymashup/*</url-pattern> </servlet-mapping>
var deferred = dojo.xhrGet( { url: "/proxy/proxymashup/location/coffee", timeout: 5000, handleAs : "text/json", headers: { "Content-Type":"text/html" }, } );
Los esquemas XML del archivo proxy-config.xml están ubicados en el directorio WEB-INF/ del archivo AjaxProxy.war. Los dos esquemas son proxy-config_1.0.1.xsd y proxy-config_1.0.xsd. El archivo proxy-config_1.0.1.xsd corresponde a la versión 1.0.1 y contiene características nuevas como el filtrado IP. Los usuarios pueden seguir utilizando las versiones anteriores del archivo proxy-config.xml que corresponden al archivo proxy-config_1.0.xsd.
<proxy:policy url="*" acf="none"> . . <proxy:mime-types> <proxy:mime-type>text/json</proxy:mime-type> </proxy:mime-types> . . </proxy:policy>
Si el servicio ha devuelto text/html, el proxy responde devolviendo una condición de error al cliente puesto que text/html no aparece como un tipo de contenido aceptable en el servidor. Si no se especifica <proxy:mime-types>, el comportamiento es permitir todos los tipos de contenido.
Para controlar el flujo de cookies, defina el nombre de cookie con permiso en el archivo proxy-config.xml. En el siguiente ejemplo se muestra cómo se puede configurar el proxy de forma que sólo pase cookies que tienen el nombre clave de cookie Session-Cookie-0.
<proxy:policy url="*" acf="none"> . . <proxy:cookies> <proxy:cookie>Session-Cookie-0</proxy:cookie> </proxy:cookies> . . </proxy:policy>
<proxy:policy url="*" acf="none"> . . <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>My-New-Header</proxy:header> <proxy:header>My-Other-New-Header</proxy:header> </proxy:headers> . . </proxy:policy>
Varios servicios pueden precisar una conexión de socket segura que utiliza SSL. Como aplicación Web, el proxy Ajax utiliza JSSE (JavaTM Secure Socket Extension) y recibe soporte completo del producto. Consulte la documentación WebSphere® correspondiente sobre el soporte de certificados SSL.
<proxy-meta-data> <proxy:name>unsigned_ssl_certificate_support</proxy:name> <proxy:value>true</proxy:value> </proxy-meta-data>
Cuando la opción unsigned_ssl_certificate_support está habilitada, el proxy Ajax acepta todos los certificados SSL. En la práctica, este valor se utiliza en entornos de desarrollo y no debe utilizarse en entornos de producción.
El proxy Ajax se puede ajustar con un número de parámetros.
El parámetro maxconnectionperhost es un valor global que especifica el número máximo de conexiones que se mantienen activas en una combinación de host o puerto. El valor predeterminado es 2. Incremente el valor si la aplicación accede a más de dos sitios remotos para obtener contenido.
<proxy:meta-data> <proxy:name>maxconnectionsperhost</proxy:name> <proxy:value>2</proxy:value> </proxy:meta-data>
El parámetro maxtotalconnections es el máximo de conexiones soportadas por el proxy. El valor predeterminado es 5. El valor que seleccione debe ser lo bastante alto para dar soporte al número de conexiones simultáneas que pueda recibir. En la práctica, tenga en cuenta cómo se ha configurado el contenedor Web y cuántas conexiones simultáneas soporta el contenedor.
<proxy:meta-data> <proxy:name>maxtotalconnections</proxy:name> <proxy:value>5</proxy:value> </proxy:meta-data>
El parámetro socket-timeout define el valor predeterminado de tiempo de espera de socket en milisegundos que espera a recibir datos una vez que se ha establecido una conexión. El valor predeterminado es un valor de tiempo de espera de 0 que se interpreta como un tiempo de espera infinito.
<proxy:meta-data> <proxy:name>socket-timeout</proxy:name> <proxy:value>5000</proxy:value> </proxy:meta-data>
El parámetro retries define el número de reintentos de socket que el proxy Ajax debe realizar antes de abandonar el establecimiento de conexión. El valor predeterminado es de dos reintentos.
<proxy:meta-data> <proxy:name>retries</proxy:name> <proxy:value>3</proxy:value> </proxy:meta-data>
El parámetro connection-timeout define el tiempo en milisegundos antes de establecer una conexión. Si no se especifica ningún valor, el valor predeterminado es 60000. Si se utiliza 0, el valor se interpreta como que no hay tiempo de espera.
<proxy:meta-data> <proxy:name>connection-timeout</proxy:name> <proxy:value>3000</proxy:value> </proxy:meta-data>
connection-pool-time define el tiempo en milisegundos antes de intentar una conexión. Este es el caso para todas las solicitudes posteriores después de superar maxtotalconnections. Si se utiliza 0, el valor se interpreta como que no hay tiempo de espera. 0 es también el valor predeterminado.
<proxy:meta-data> <proxy:name>connection-pool-timeout</proxy:name> <proxy:value>1000</proxy:value> </proxy:meta-data>
De forma predeterminada, el proxy Ajax sólo reenviará códigos de estado HTTP mayores o iguales a 200 y menores que 400. Los códigos de estado que queden fuera del rango cambian automáticamente a un error 404 de archivo no encontrado. La única excepción es el código 401 (no autorizado), que da lugar al error 403 (Prohibido) a menos que se haya habilitado el atributo basic-auth-support para esa petición determinada.
Puede reenviar los códigos HTTP mayores o iguales a 400 con un mensaje si establece el parámetro de metadatos forward-http-errors en el archivo proxy-config.xml
<proxy:meta-data> <proxy:name>forward-http-errors</proxy:name> <proxy:value>true</proxy:value> </proxy:meta-data>
El proxy Ajax se puede configurar para conectarse a otro proxy antes de acceder a la red. Es posible que sea necesaria la conexión a un proxy de paso a través si el proxy Ajax necesita atravesar un cortafuegos antes de acceder a la red. El proxy Ajax da soporte a la autenticación básica.
En el siguiente ejemplo se muestra la configuración de un cortafuegos de proxy ficticio. passthru_host es un parámetro necesario. Otros como passthru_type, passthru_username y passthru_password son parámetros opcionales. El parámetro passthru_type significa el tipo de autenticación utilizado. El tipo predeterminado es BASIC. De forma alternativa, también se puede utilizar DIGEST y NTLM. NTLM requiere los parámetros adicionales passthru_hostname y passthru_domain. Los parámetros passthru_port y passthru_realm también son opcionales. Si no se especifica un parámetro passthru_port, se utiliza el valor predeterminado del puerto 80. Si no se especifica un parámetro passthru_realm, se envían las credenciales para todos los intentos de autenticación. Especifique el parámetro passthru_realm en un entorno de producción para impedir que la información de nombre de usuario y contraseña esté presente para todas las peticiones de autenticación.
<proxy-meta-data> <proxy:name>passthru_type</proxy:name> <proxy:value>BASIC</proxy:value> </proxy-meta-data> <proxy-meta-data> <proxy:name>passthru_host</proxy:name> <proxy:value>9.17.237.132</proxy:value> </proxy-meta-data> <proxy-meta-data> <proxy:name>passthru_port</proxy:name> <proxy:value>3128</proxy:value> </proxy-meta-data> <proxy-meta-data> <proxy:name>passthru_realm</proxy:name> <proxy:value>MyRealm</proxy:value> </proxy-meta-data> <proxy-meta-data> <proxy:name>passthru_username</proxy:name> <proxy:value>username</proxy:value> </proxy-meta-data> <proxy-meta-data> <proxy:name>passthru_password</proxy:name> <proxy:value>password</proxy:value> </proxy-meta-data>
Para habilitar la autenticación básica, establezca el atributo basic-auth-support para una política en el archivo proxy-config.xml. Observe el ejemplo siguiente:
<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" basic-auth-support="true"> <proxy:actions> <proxy:method>GET</proxy:method> </proxy:actions> </proxy:policy> </proxy-rules>
En el ejemplo, el proxy Ajax volverá a reenviar el estado HTTP y la información de cabecera al servicio de destino y al cliente. Si no se establece el atributo basic-auth-support y el proxy Ajax recibe una petición 401, el proxy correlacionará la petición con una 403: código HTTP prohibido.
Nota: actualmente, el mecanismo de autenticación básica es el único método de autenticación HTTP que admite el proxy.
El filtrado IP del proxy Ajax permite incluir en la lista blanca o negra las direcciones IP con el fin de proteger los servicios a los que se conecte el proxy Ajax. La lista negra contiene las direcciones IP de servicios a las que los clientes no se pueden conectar mientras que la lista blanca contiene las direcciones IP de servicios a las que el proxy Ajax puede conectarse.
proxy:ipfilter define las direcciones IP que se van a filtrar. proxy:allow define la lista blanca de direcciones IP o el rango de direcciones. proxy:deny define una lista negra de direcciones IP o rango de direcciones.
Por ejemplo:<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:ipfilter> <proxy:deny>9.6.0.0/255.255.0.0</proxy:deny> <proxy:allow>9.6.1.0/255.255.255.0</proxy:allow> <proxy:deny>9.6.1.4</proxy:deny> </proxy:ipfilter> </proxy:mapping> <proxy:policy url="*" acf="none"> <proxy:actions> <proxy:method>GET</proxy:method> </proxy:actions> </proxy:policy> </proxy-rules>
CWXJX1000E: Una regla prohíbe la dirección IP de los hosts de destino especificados.
No obstante, el proxy Ajax permite el acceso a 9.6.1.5 o 9.6.1.120, pero deniega el acceso a 9.6.1.4.
En el siguiente ejemplo, primero se incluyen en una lista negra todas las direcciones IP y después se agregan intervalos de IP adicionales. En este ejemplo, el elemento de código siguiente bloquea todas las direcciones IP: *.*.*.*. Se admiten las direcciones IP en el intervalo de 98.137.80.1 a 98.137.254.
<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="/rss/economy" url="http://rss.news.yahoo.com"> <proxy:ipfilter> <proxy:deny>*.*.*.*</proxy:deny> <proxy:allow>98.137.80.0/255.255.255.0</proxy:allow> </proxy:ipfilter> </proxy:mapping> <proxy:policy url="*" acf="none"> <proxy:actions> <proxy:method>GET</proxy:method> </proxy:actions> </proxy:policy> </proxy-rules>
A medida que añade nuevas reglas de filtro, puede combinarlas de diversas formas, pero el proxy Ajax siempre las maneja en el orden en que se han definido. Esto significa que la última regla coincidente siempre estará en vigor, independientemente de cualquier regla de permiso o denegación de permiso que haya antes.