Contendores del tomcat
2 Noviembre 2009 Context Container
El Context element representa una aplicación web, que se ejecuta en un host virtual. Cada aplicacion se basa en un archivo de aplicación (WAR), o un directorio que contiene los elementos descomprimidos.
Catalina decide que plicación que procesa una petición HTTP basándose en la URI comparandola con la ruta del contexto. Una vez que se seleciona el contexto, éste decidira el servlet para procesar la petición de acuerdo con los mapeos de los servlets definidos en el descriptor de la aplicación web (web.xml) que se encuentra en /WEB-INF/web.xml.
Se pueden definir tantos contextos como se quiera, teninedo en cuenta que cada contexto tiene que tener una ruta única, además, debe de existir un contexto con una ruta con una ruta cuya longitud sea cero. Este contexto es el contexto por defecto para los hosts virtuales y se usa para procesar todas las peticiones que no coinciden con ningún contexto.
A partir del Tomcat 5, no se recomienda poner elementos directamente en el server.xml. Esto es porque no es posible modificar la configuración del contexto en el fichero server.xml y recargar dicha configuración sin reiniciar el Tomcat.
Los contextos se pueden definir explicitamente en:
$CATALINA_HOME/conf/context.xml: La información del contexto se cargaran por todas las aplicaciones.
$CATALINA_HOME/conf/[enginename]/[hostname]/context.xml : La información del contexto se cargara por todas las aplicaciones en ese host virtual.
Engine Container
El Engine representa todo el proceso de peticiones asociados a un servicio del catalina en particular, recibe y procesa todas las peticiones de uno o más conectores devolciendo el response completo al conector para que se la devuelva al cliente.
Tiene que existir un engine dentro de un sericio, seguido de todos los conectores asociados al servicio.
Host Container
El elemento host representa un host virtual, que representa una asociación al dominio (por ejemplo “www.google.com”) con el servidor Catalina sobre el que se ejecuta. Para que funcione correctamente se tiene que registrar la DNS.
Para poder asociar mas de un dominio a un host se tiene que usan los alias. Se pueden asociar mas de un host a un Engine. Dentro del host se puede anidar los contextos de las aplicaciones web asociados al host virtual. Al menos uno de tiene que ser el defaultHost del Engine.
El Context element representa una aplicación web, que se ejecuta en un host virtual. Cada aplicacion se basa en un archivo de aplicación (WAR), o un directorio que contiene los elementos descomprimidos.
Catalina decide que plicación que procesa una petición HTTP basándose en la URI comparandola con la ruta del contexto. Una vez que se seleciona el contexto, éste decidira el servlet para procesar la petición de acuerdo con los mapeos de los servlets definidos en el descriptor de la aplicación web (web.xml) que se encuentra en /WEB-INF/web.xml.
Se pueden definir tantos contextos como se quiera, teninedo en cuenta que cada contexto tiene que tener una ruta única, además, debe de existir un contexto con una ruta con una ruta cuya longitud sea cero. Este contexto es el contexto por defecto para los hosts virtuales y se usa para procesar todas las peticiones que no coinciden con ningún contexto.
A partir del Tomcat 5, no se recomienda poner elementos directamente en el server.xml. Esto es porque no es posible modificar la configuración del contexto en el fichero server.xml y recargar dicha configuración sin reiniciar el Tomcat.
Los contextos se pueden definir explicitamente en:
$CATALINA_HOME/conf/context.xml: La información del contexto se cargaran por todas las aplicaciones.
$CATALINA_HOME/conf/[enginename]/[hostname]/context.xml : La información del contexto se cargara por todas las aplicaciones en ese host virtual.
Engine Container
El Engine representa todo el proceso de peticiones asociados a un servicio del catalina en particular, recibe y procesa todas las peticiones de uno o más conectores devolciendo el response completo al conector para que se la devuelva al cliente.
Tiene que existir un engine dentro de un sericio, seguido de todos los conectores asociados al servicio.
Host Container
El elemento host representa un host virtual, que representa una asociación al dominio (por ejemplo “www.google.com”) con el servidor Catalina sobre el que se ejecuta. Para que funcione correctamente se tiene que registrar la DNS.
Para poder asociar mas de un dominio a un host se tiene que usan los alias. Se pueden asociar mas de un host a un Engine. Dentro del host se puede anidar los contextos de las aplicaciones web asociados al host virtual. Al menos uno de tiene que ser el defaultHost del Engine.
Válvulas de Tomcat
2 Noviembre 2009 ¿Qué es una válvula del tomcat?
Las válvulas del tomcat son una técnología introducida a partir de Tomcat 4 que permite asociar una instacia de una clase Java al un contenedor Catalina.
Esta configuración permite que la clase asociada actue como un pre-procesador de las peticiones. Estas clases se llaman válvulas, y deben implementar la intefaz org.apache.catalina.Valve interface o extender la clase org.apache.catalina.valves.ValveBase. Las válvulas son propias de Tomcat y no pueden ser usadas en otros contenedores de servlet. Las válvulas disponibles son:
- Access Log
- Remote Address Filter
- Remote Host Filter
- Request Dumper
- Single Sign On
- Form Authenticator
Access Log Valve
La primera válvula por defecto del tomcat es Access Log Valve, que está implementada por la clase org.apache.catalina.valves.AccessLogValve. Crea ficheros de log para rastrear el acceso a la información de los clientes.
Alguna de la infomación que rastrea son clicks, actividad de la sesión del usuario, información de la autenticación del usuario entre otras. Esta válvula se puede asociar a un engine, host o context container del Tomcat.
Ejemplo de uso :
Este código indica que los logs se guardaran en el directorio /logs, con el prefijo “localhost_access_log.”, y con el sufijo “.txt”.
Remote Address Filter
El Remote Address filter lo implementa la clase org.apache.catalina.valves.RemoteAddrValve, permite comparar direcciones IP de los clientes que realizan la petición con una o varias expresiones regulares para prohibir o permitir el acceso. Esta válvula se puede asociar al Engine, Host, o Context container.
Ejemplo de uso:
Esta sentencia prohibe el acceso a todos los clientes cuya IP empiecen por 127.
Remote Host Filter
El Remote Host filter está implementado por org.apache.catalina.valves.RemoteHostValve es muy parecido al RemoteAddrValve, con la diferencia que te permite comparar al nombre del host en vez de la IP. Se puede asociar al Engine, Host, o Context container.
Ejemplo de uso:
Con esta sentencia prohibimos el acceso a todos los host con que incluyan en su nombre virtuas.
Request Dumper Valve
ElRequest Dumper valve lo implenta la clase org.apache.catalina.valves.RequestDumperValve es una herramienta de depuración que escribe en el log el detalle de cada petición realizada. Se puede asociar al Engine, Host, o Context container.
Ejemplo de uso:
Si accedemos a cualquier aplicación en localhost:8080 y accedemos al log, veremos unas cuantas entradas realizadas por el RequestDumperValve.
Single Sing On
Esta válvula se utiliza cuando queremos que los usuarios puedan identificarse en cualquier aplicacion en nuestro virtual host, y que su identidad sea reconocida por cualquier aplicación que esté en ese host.
Ejemplo de uso:
Form Authenticator Valve
Se añade automáticamente al Context cuando este se configura para usar autenticación mediante FORM.
Las válvulas del tomcat son una técnología introducida a partir de Tomcat 4 que permite asociar una instacia de una clase Java al un contenedor Catalina.
Esta configuración permite que la clase asociada actue como un pre-procesador de las peticiones. Estas clases se llaman válvulas, y deben implementar la intefaz org.apache.catalina.Valve interface o extender la clase org.apache.catalina.valves.ValveBase. Las válvulas son propias de Tomcat y no pueden ser usadas en otros contenedores de servlet. Las válvulas disponibles son:
- Access Log
- Remote Address Filter
- Remote Host Filter
- Request Dumper
- Single Sign On
- Form Authenticator
Access Log Valve
La primera válvula por defecto del tomcat es Access Log Valve, que está implementada por la clase org.apache.catalina.valves.AccessLogValve. Crea ficheros de log para rastrear el acceso a la información de los clientes.
Alguna de la infomación que rastrea son clicks, actividad de la sesión del usuario, información de la autenticación del usuario entre otras. Esta válvula se puede asociar a un engine, host o context container del Tomcat.
Ejemplo de uso :
1 | <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common"/> |
Remote Address Filter
El Remote Address filter lo implementa la clase org.apache.catalina.valves.RemoteAddrValve, permite comparar direcciones IP de los clientes que realizan la petición con una o varias expresiones regulares para prohibir o permitir el acceso. Esta válvula se puede asociar al Engine, Host, o Context container.
Ejemplo de uso:
1 | <Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="127.*"/> |
Remote Host Filter
El Remote Host filter está implementado por org.apache.catalina.valves.RemoteHostValve es muy parecido al RemoteAddrValve, con la diferencia que te permite comparar al nombre del host en vez de la IP. Se puede asociar al Engine, Host, o Context container.
Ejemplo de uso:
1 | <Valve className="org.apache.catalina.valves.RemoteHostValve" deny="virtuas*"/> |
Request Dumper Valve
ElRequest Dumper valve lo implenta la clase org.apache.catalina.valves.RequestDumperValve es una herramienta de depuración que escribe en el log el detalle de cada petición realizada. Se puede asociar al Engine, Host, o Context container.
Ejemplo de uso:
1 | <Valve className="org.apache.catalina.valves.RequestDumperValve"/> |
Single Sing On
Esta válvula se utiliza cuando queremos que los usuarios puedan identificarse en cualquier aplicacion en nuestro virtual host, y que su identidad sea reconocida por cualquier aplicación que esté en ese host.
Ejemplo de uso:
1 | <Valve className="org.apache.catalina.authenticator.SingleSignOn" /> |
Se añade automáticamente al Context cuando este se configura para usar autenticación mediante FORM.
Control de accesos por IP a Tomcat
9 Octubre 2009 Hace poco tuve que capar el acceso a una aplicación por IP, barajamos varias opciones y al final el personal de sistemas tomó una decisión. De todas formas me pareció muy interesante usar las valve o válvulas de Tomcat para hacerlo. Nunca lo había hecho, ni sabía que se podía hacer con el propio Tomcat, siempre había pensado en firewalls o apache, o cualquier otra cosa. La verdad es que nunca tuve que ver como se hacía hasta ahora.
Para hacerlo hay que hacer lo siguiente:
En el fichero server.xml, dentro del Host localhost, ponemos lo siguiente:
En este caso prohibimos el acceso a todas las direcciones IP que concuerden con 192.164.1.*, se pueden poner más si separamos las IPs con “,”. También se puede definir el parámetro “allow” que se usa de la misma forma, en este caso todas las IPs que no concuerden con nuestra expresión, no podrán tener acceso.
Para hacerlo hay que hacer lo siguiente:
En el fichero server.xml, dentro del Host localhost, ponemos lo siguiente:
1 | <Valve lassName="org.apache.catalina.valves.RemoteAddrValve" deny="192.164.1.*"> |
Vulnerabilidades en Tomcat
9 Octubre 2009 Se han encontrado varios dos fallos de seguridad en las siguientes versiones de tomcat:
Tomcat 4.1.0 al 4.1.37
Tomcat 5.5.0 al 5.5.26
Tomcat 6.0.0 al 6.0.16
Estas vulnerabilidades son:
1)En el RequestDispatcher la ruta de destino se normalizó antes de que la cadena de consulta se ha retirado. Por lo tanto si se pone un parámetro malicioso en la consulta se puede conseguir acceder a información restringida o información que se encuentre en el WEB-IND
Ejemplo:
Una página que tenga:
Por ejemplo:
<%@page contentType=”text/html”%>
Tomcat 4.1.0 al 4.1.37
Tomcat 5.5.0 al 5.5.26
Tomcat 6.0.0 al 6.0.16
Estas vulnerabilidades son:
1)En el RequestDispatcher la ruta de destino se normalizó antes de que la cadena de consulta se ha retirado. Por lo tanto si se pone un parámetro malicioso en la consulta se puede conseguir acceder a información restringida o información que se encuentre en el WEB-IND
Ejemplo:
Una página que tenga:
<%
pageContext.forward("/page2.jsp?somepar=someval&par="+request.getParamet
er("blah"));
%>
El hacker puede usar:
http://host/page.jsp?blah=/../WEB-INF/web.xml
2) HttpServletResponse.sendError () no es sólo aparece en la página de error, también se utiliza en el HTTP response. Esto puede incluir caracteres que son ilegales en las cabeceras HTTP. Con un esto se puede conseguir un ataque XSS, al inyectar contenido arbitrario en la respuesta HTTP.Por ejemplo:
<%@page contentType=”text/html”%>
<%
final String CRLF = "\u010D\u010A";
final String payload = CRLF + CRLF + "<script
type='text/javascript'>document.write('Hi, there!')</script><div style='display:none'>";
final String message = "Authorization is required to access " + payload;
response.sendError(403, message);
%>Comunicación entre contextos
9 Octubre 2009En uno de los proyectos en los que trabajo, tengo la necesidad de compartir variables entre dos contextos que se encuentran en el mismo Tomcat y descubrí el CrossContext que es un atributo de configuración de tomcat que sirve para que las diferentes aplicaciones en el servidor compartan el contexto.
Se tiene que modificar el fichero conf/server.xml del tomcat añadiendo las siguientes líneas dentro del tag <host>:
<Context path=”/miapiclicacion1″ debug=”0″ reloadable=”true” crossContext=”true” />
<Context path=”/miaplicicacion2″ debug=”0″ reloadable=”true” crossContext=”true” />
Con el “crossContext = true” indicamos a los dos proyectos que van a compartir información.
En uno de los proyectos en los que trabajo, tengo la necesidad de compartir variables entre dos contextos que se encuentran en el mismo Tomcat y descubrí el CrossContext que es un atributo de configuración de tomcat que sirve para que las diferentes aplicaciones en el servidor compartan el contexto.
Se tiene que modificar el fichero conf/server.xml del tomcat añadiendo las siguientes líneas dentro del tag <host>:
<Context path=”/miapiclicacion1″ debug=”0″ reloadable=”true” crossContext=”true” />
<Context path=”/miaplicicacion2″ debug=”0″ reloadable=”true” crossContext=”true” />
Con el “crossContext = true” indicamos a los dos proyectos que van a compartir información.
Ahora en una de las aplicaciones podemos poner algo así:
application.setAttribute(”variable”,”hola”);
En la otra ponemos
ServletContext sc = pageContext.getServletContext().getContext(”/miaplicacion2″); //inicializa el servlerContext con el nombre de la aplicación de la que queremos //obtener el contexto
out.println(sc.getAttribute(”variable”));
¿Cuál es la diferencia entre common/lib y shared/lib en Tomcat?
8 Octubre 2009 En common/lib están los archivos jar que se por las aplicaciones web y el propio servidor, mientras que en shared/lib tenemos las librerías que son accesibles sólo para las aplicaciones web.
El log de Tomcat
22 Enero 2009 Hoy he tenido un problema, me he dado cuenta de que mi log del tomcat era demasiado grande, 6 Gb; Lo cual me llamo la atención, ya que sabía, que por defecto el log de tomcat se define como “rotable” es decir, que se rotan los logs una vez al día. Miré si era problema de premisos y no, era problema de configuración. Así que desempolve mi libro de tomcat y lo configuré bien. De ahí, que hoy haya decidido explicar un poco este tema.
El siguiente fragmento de código es un ejemplo usando la entrada org.apache.catalina.valves.AccessLogValve:
Desde el Tomcat 4, existe un concepto que se conoce como “valve” que permite asociar una instancia de una clase java a un contenedor Catalina. De esta forma, asociando el nombre de la clase, podemos hacer que esta actue como un preprocesador de cada solicitud. Estas clases deben implementar la clase org.apache.catalina.Valve o extender la org.apache.catalina.valves.ValveBase clase. Tomcat viene configurado con cuatro válvulas:
- Access Log- Remote Address Filter
- Remote Host Filter
- Request Dumper
Me voy a centrar en la primera, la válvula del log o LogAccessValve, la clase es org.apache.catalina.valves.AccessLogValve. Cuya misión es crear archivos de log para seguir el seguimiento de la aplicación del servidor de aplicaciones o de la aplicación si deseamos usar este log y no uno propio para ello. Algunos de las seguimientos que hace esta válvula es hit counts, actividad de la sesión del usuario, la autenticación de los usuarios, entre otros.El siguiente fragmento de código es un ejemplo usando la entrada org.apache.catalina.valves.AccessLogValve:
<Valve className=”org.apache.catalina.valves.AccessLogValve” directory=”logs” prefix=”localhost_access_log.” suffix=”.txt” pattern=”common”/>
Este fragmento de código establece que los archivos de log se colocarán en la <CATALINA_HOME> /, con el sufijo localhost_access_log, con el sufijo txt.
El atributo que me dio a mi el quebradero de cabeza era rotable, que en mi caso estaba a false y con esto hay que tener mucho cuidado. Por defecto está a true.
Ampliar la memoria al tomcat
16 Diciembre 2008 Uno de los problemas más comunes que nos hemos encontrado todos alguna vez es que nuestro servidor de aplicaciones, en este caso, tomcat, se quede sin memoria (heap space), para ampliarlo tenemos que tener en cuenta los parámetros que tenemos que modificar, cómo modificarlos y dónde modificarlos. Para empezar vamos a hablar de las opciones:
set CATALINA_OPTS=”-Xms512m -Xmx512m” (Windows)
export CATALINA_OPTS=”-Xms512m -Xmx512m” (linux)
- Maximum heap size: Esto indica el tamaño máximo de la memoria que usara la máquina virtual de java (JVM). En la mayoría de los casos el valor que toma por defecto es 64MB. Para ampliar la memoria se utiliza el parámetro -Xmx, por ejemplo, -Xmx512m. Hay que tener en cuenta que la memoria que se le aplique debe ser consiederablemente menor a la cantidad de RAM del sistema, sino puede entrar en conflicto con otras aplicaciones. Nota: Si queremos saber la memoria de la que disponemos en Linux, ejecutar el comando top o free.
- Initial heap size: Indica el la memoria que se utiliza inicialmente y se configura de la siguiente usando el parámetro -Xms, por ejemplo, -Xms252m
- No poner m, M o g, G, teniendo en cuenta que es sensible a mayúsculas.
- Escribir mal la sentencia, no lleva espacios ni el símbolo “=”, la forma correcta es -Xmx512m.
- Poner el initial heap size mayor que el maximun heap size.
- Que se le haya asignado una memoría mayor que la real del sistema.
- Usar como la unidad mb cuando es m.
- Asignarle más memoria de la que la JVM piensa que va a ser necesaria.
- No expresar la cantidad como un número entero.
set CATALINA_OPTS=”-Xms512m -Xmx512m” (Windows)
export CATALINA_OPTS=”-Xms512m -Xmx512m” (linux)
No hay comentarios:
Publicar un comentario