Odiar a algien es darle demasiada importancia
:)

Eres un experto en Java ?

La respuesta a esa pregunta es un "lo dudo mucho". Al hilo de una entrada anterior sobre lo necesario de la formación continua en nuestra profesión, he encontrado esta entrada (en inglés, no recuerdo dónde lo vi y ni siquiera si ya lo publiqué) donde nos muestra un mapa de conocimientos de Java

Dentro de toda esta maraña de concoimientos, yo me he "especializado" en J2EE que como puedes ver es una pequeña rama dentro del conjunto.

Y como apuntaba en la entrada mencionada sobre formación continua, no sólo hay que saber Java : hay que saber utilzar frameworks sobre Java, otros lenguajes de programación, un IDE, servidores de aplicaciones, bases de datos, control de versiones y otros conceptos de ingeniería del software. Todo ello en constante evolución.

Por si eres alguien que está empezando : tranquilo, paso a paso, que si Lycka sabe todo esto cualquiera puede.

Si eres alguien que lleva tanto tiempo como yo… ánimo!

Evitar el acceso a recursos web

filterchain.gifPreguntaba Manu en [Struts] – Input y Forwards de un Action cómo se puede evitar con un filtro el acceso a todos los recursos que no sean acciones en nuestra aplicación.

Es posible que queramos limitar el acceso vía web a los recursos de nuestras aplicaciones, como por ejemplo a nuestras imágenes o páginas JSP. Típicamente será por razones de seguridad o auditoría. 

Una posible solución a la pregunta de Manu podría ser implementar un filtro (una clase que extienda de javax.servlet.Filter) que se invoque en todas las peticiones al servidor (o en las peticiones que queramos filtrar). En nuestra aplicación se declararía en nuestro fichero web.xml: 

<filter>

      <filter-name>FiltroRecursos</filter-name>

      <display-name>Filtrado de los recursos permitidos vía web</display-name>

      <description>Filtrado de los recursos permitidos vía web</description>

      <filter-class>es.lycka.bonita.seguridad.FiltroRecursos</filter-class>

</filter>

<filter-mapping>

      <filter-name>FiltroRecursos</filter-name>

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

</filter-mapping>

En el método doFilter de nuestro filtro (es.lycka.bonita.seguridad.FiltroRecursos) podemos saber qué recurso se está solicitando, utilizando el método request.getRequestURI(). De esta forma podemos permitir su acceso o denegarlo redirigiendo a una página de error. El criterio será el que nos interese, como por ejemplo que el recurso no esté en una lista de recursos válidos, o que su extensión no se acepte.

Despliegue de una nueva Aplicación Web

Podemos desplegar una aplicación web en un servidor de aplicaciones, ya sea una nueva aplicación web o una modificación de una existente, de dos formas diferentes:

  1. Copiar los archivos bajo $TOMCAT_HOME/webapps .
  2. Subir un fichero .war (Web ARchive). Cuando no tenemos privilegios para manejar ficheros en el servidor, subiremos un fichero WAR. El servidor de aplicaciones creará un directorio en $TOMCAT_HOME/webapps. Su nombre será el mismo del archivo WAR.

El servidor de aplicaciones, TOMCAT en nuestro caso, tomará por defecto el nombre del directorio que cuelga de $TOMCAT_HOME/webapps como nombre de la aplicación web y como nombre del contexto de la aplicación (se utilizará para formar la URL que acceda a nuestra aplicación).

Una vez desplegada la aplicación, ¿debemos reiniciar el servidor de aplicaciones?.

Primero debemos tener en cuenta que únicamente es necesario reiniciar el servidor de aplicaciones entero cuando modificamos las librerías del servidor (comunes para todas las aplicaciones). Cuando los cambios afectan a una única aplicación y el servidor de aplicaciones es compartido por varias aplicaciones y varios equipos de trabajo (típicamente en los entornos de preproducción y producción), es recomendable utilizar la consola de administración del servidor de aplicaciones para reiniciar ÚNICAMENTE la aplicación web que hemos desplegado, para no afectar a los demás equipos y apliaciones.

Es necesario reiniciar la aplicación web siempre que se realicen cambios en la parte java (ficheros CLASS o librerías). Los cambios realizados en la parte web (incluidos los ficheros JSP) no afectan al servidor de aplicaciones (los ficheros JSP son compilados en tiempo de ejecución), por lo que no es necesario reiniciarlo.

WAR – estructura de directorios de una aplicación web

Los ficheros .war (Web ARchives) son los archivos que contienen una aplicación web, y no son más que los archivos de la aplicación web estructurado según el formato de las especficaciones de sun.

Esta estructura de directorios la podemos consultar en el capítulo 9.5 del documento Especificaciones Servlets 2.4 Sun de las especificaciones 2.4. Expondré un posible ejemplo, en negrita lo que es obligatorio:

/index.jsp
/WebContent/jsp/welcome.jsp
/WebContent/css/estilo.css
/WebContent/js/utils.js
/WebContent/img/welcome.jpg
/WEB-INF/web.xml
/WEB-INF/struts-config.xml
/WEB-INF/lib/struts.jar
/WEB-INF/src/com/empresa/proyecto/action/welcomeAction.java
/WEB-INF/classess/com/empresa/proyecto/action/welcomeAction.class

web.xml

Como todos los ficheros xml de configuración, este archivo contiene una DTD (como por ejemplo ésta 2.2) que describe el contenido ordenado del fichero xml, y la descripción de las propiedades que va a utilizar. Este es el fichero que contiene la configuración de la aplicación web que estemos desarrollando, y su contenido es el siguiente:

  • web-app, que es el elemento raíz del fichero xml.
  • icon, especifica la ruta para las imágenes asociadas a los iconos pequeño y grande que representan a la aplicación.
  • display-name, el nombre que representará a la aplicación dentro de las herramientas del servidor de aplicaciones, no es un nombre funcional.
  • description, texto descriptivo de la aplicación, que al igual que las dos anteriores propiedades, sólo es representativo.
  • context-param, nos permite configurar la inicialización del contexto de una servlet de nuestra aplicación web. Un ejemplo :

<context-param> <param-name>hostname</param-name> <param-value>localhost</param-value> <description> The name of the host on which recipned is running </description> </context-param>

  • servlet, declaramos la configuración de nuestras servlets. Un ejemplo típico es la configuración de la servlet para utilizar struts:

<servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> <load-on-startup>2</load-on-startup> </servlet>

  • servlet-mapping, relacionamos las servlets que hemos declarado con las url que van a escuchar. Por ejemplo para utilizar la servlet que hemos llamado anteriormente "action" cuando la url tiene la extensión ".do":

<servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping>

  • session-config, parámetros para configurar la sesión. El único, session-timeout que por defecto es 30 minutos.

<session-config> <session-timeout>30</session-timeout> </session-config>

  • mime-mapping, para declarar una relación entre las extensiones y los tipos mime.

<mime-mapping> <extension>doc</extension> <mime-type>application/vnd.ms-word</mime-type> </mime-mapping> <mime-mapping> <extension>dsp</extension> <mime-type>text/html</mime-type> </mime-mapping>

  • welcome-file-list, especifica los ficheros de bienvenida posibles.

<welcome-file-list> <welcome-file>index.jsp</welcome-file> <welcome-file>indexAdministracion.jsp</welcome-file> </welcome-file-list>

  • tag-lib, para describir librerías de etiquetas (tab libs!!!) de los ficheros JSP. Por ejemplo, las típicas utilizadas con struts:

<taglib> <taglib-uri>/tags/struts-bean</taglib-uri> <taglib-location>/WEB-INF/struts-bean.tld</taglib-location> </taglib>

  • error-page, para asociar errores HTML y excepciones lanzadas a páginas de error personalizadas para la aplicación:

<error-page> <error-code>404</error-code> <location>/notfound.jsp</location> </error-page> <error-page> <exception-type>java.lang.Throwable</exception-type> <location>/error.jsp</location> </error-page>

  • resource-ref, utilizado para declarar recursos externos que nuestra aplicación va a utilizar, como una conexión a una base de datos.

<resource-ref> <description>Conexion hacia Base de Datos SQL</description> <res-ref-name>jdbc/ConexionMySQL</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>

  • security-constraint, para proteger áreas de la aplicación (o la aplicación completa como en el ejemplo), asonciándolas a roles que deben tener los usuarios para poder acceder. Estos usuarios y roles son los declarados en TOMCAT_ROOT/conf/tomcat-users.xml. Es útil cuando queremos proteger sin desarrollar código.

<security-constraint> <web-resource-collection> <web-resource-name>Área protegida</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>intranet</role-name> </auth-constraint> </security-constraint>

  • login-config, para configurar el tipo de login que se requerirá al entrar en un área protegida previamente declarada. Dos valores posibles para los métodos de autenticación posibles son BASIC, FORM.

<login-config> <auth-method>BASIC</auth-method> <realm-name>Autentificación por formulario</realm-name> </login-config> <login-config> <auth-method>FORM</auth-method> <realm-name>default</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> </login-config>

  • security-role, para declarar los roles de usuarios de tomcat que se van a utilizar en la aplicación:

<security-role> <role-name>intranet</role-name> </security-role>

  • env-entry, declara una posible entrada al entorno (environment) de la aplicación.

<env-entry> <description>welcome message</description> <env-entry-name>greetings</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>Welcome to the Inventory Control System</env-entry-value> </env-entry>

  • ejb-ref, para declarar referencias a un enterprise bean:

<ejb-ref> <description>Cruise ship cabin</description> <ejb-ref-name>ejb/CabinHome</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <home>com.titan.cabin.CabinHome</home> <remote>com.titan.cabin.Cabin</remote> </ejb-ref>

[tags]web.xml[/tags] 

Comenta