El problema viene cuando utilizamos una gran cantidad de plantillas xhtml personalizadas y necesitamos gestionarlas de manera externa a la aplicación y almacenarlas por ejemplo en un repositorio externo: BD, gestor documental, ftp, en disco, etc.

Por defecto, el render de Seam permite generar renderizados de vistas (views) que están contenidas dentro de la propia aplicación. Un ejemplo:

renderer.render("/pdf/templatePdf.xhtml");

La anterior linea intentará generar el renderizado a partir de un resource en la propia aplicación, es decir, el archivo templatePdf.xhtml debe estar físicamente en el webapps de la aplicación.

¿Y qué ocurre si tenemos un templatePdf.xhtml externo, quizás en un repositorio o lo queremos generar dinámicamente?

Lo que tenemos que hacer es implementar un cargador de resources que controle cuándo queremos renderizar una vista normal o una vista en un repositorio externo.

Esta distinción se hará a nivel de URL, es decir, cuando queramos renderizar una vista normal nos bastaría con:

renderer.render("/pdf/templatePdf.xhtml")

mientras que para renderizar vistas externas podríamos poner algo como:

renderer.render("CUSTOM-/pdf/templatePdf.xhtml")

es decir, anteponemos un prefijo, por ejemplo “CUSTOM-”.

Ahora nos toca decirle al cargador de resources que cuando se solicite un recurso con el prefijo “CUSTOM-” lo trate de manera especial, cargándolo por ejemplo de un repositorio de plantillas, de un FTP, generándolas nosotros dinámicamente o lo que necesitéis. Aquí os pongo la implementación de la clase:

import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLConnection;
import java.net.URLStreamHandler;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.jboss.seam.ScopeType;
import org.jboss.seam.annotations.Name;
import org.jboss.seam.annotations.Scope;
import org.jboss.seam.contexts.ServletLifecycle;
import org.jboss.seam.core.ResourceLoader;
import org.jboss.seam.util.Resources;

@Name("org.jboss.seam.core.resourceLoader")
@Scope(ScopeType.STATELESS)
public class CustomResourceLoader extends ResourceLoader {

    public static final String TEMPLATE_PREFIX = "CUSTOM-";

    @Override
    public URL getResource(final String resource) {
        URL url = null;
        if (resource.startsWith(TEMPLATE_PREFIX)) {
            final String uriViewId = resource.substring(TEMPLATE_PREFIX.length());
            try {
                url = new URL("internal", "", 0, uriViewId, getHandler(uriViewId));
            } catch (final MalformedURLException e) {
                if (log.isErrorEnabled()) {
                    log.error("Unable to build the URL", e);
                }
            }
        } else {
            url = Resources.getResource(resource, ServletLifecycle.getServletContext());
        }
        return url;
    }

    // @return Our own implementation of an URLStreamHandler to get the template
    //         from the content repository.
    private static URLStreamHandler getHandler(final String uriViewId) {
        return new URLStreamHandler() {
            private final String uuid = uriViewId;

            @Override
            protected URLConnection openConnection(final URL url) throws IOException {
                return new URLConnection(url) {

                    @Override
                    public void connect() throws IOException {
                        // Gets not called in this case
                    }

                    @Override
                    public InputStream getInputStream() throws IOException {
                        initHandler();
                        try {
                            // Cargamos el contenido de la plantilla .xhtml
                            byte [] content = ....... ;
                            final InputStream input = new ByteArrayInputStream(content);
                            return input;
                        } catch (final Exception e) {
                            throw new IOException(e.getMessage(), e);
                        }
                    }

                    private void initHandler() {
                        log.debug("Init Handler");
                    }
                };
            }
        };
    }

    /**
     * Sistema de Logs
    */
    protected static transient Log log = LogFactory.getFactory().getInstance(CustomResourceLoader.class);

}

Quizás el equipo de desarrollo de Seam Framework propongo otro tipo de soluciones en el futuro para estos casos, pero por ahora, tenemos que hacer un poco de magia.

Como no podría ser de otra forma, vamos a hacer uso del servicio de autenticación de la plataforma Viafirma, sirviéndonos de su cliente de autenticación, apoyándonos en su espectacular matriz de compatibilidad, además mantendremos el acceso por usuario/contraseña habitual de XWiki. Para realizar esta integración nos hemos basado principalmente en la documentación que podemos encontrar en las páginas oficiales de ambas plataformas, por un lado tenemos a Viafirma y por otro lado la web para desarrolladores de XWiki Development Zone

Primero una idea de lo que queremos hacer:

Dentro del formulario de login de XWiki, pondremos un enlace a una url dentro del propio XWiki que sea de la forma:
http://xwikiserver/.../viafirma.login

Esta URL será capturada dentro de la XWiki por un Filter que enviará al usuario automáticamente a Viafirma, que será el encargado de pedir el certificado digital al usuario y analizarlo (validarlo), tras esto enviará al usuario nuevamente a la XWiki (Viafirma coloca en la Session de esta petición el resultado de la validación del Certificado y será XWiki el encargado de tratar ese resultado) con una url con la forma:

http://xwikiserver/.../viafirmaAuthentication

El Request de esta URL será capturado por un Servlet que extiende al ViafirmaClientServlet, que nos proporciona el cliente de Viafirma, capturando de sesión el UsuarioGenericoViafirma que se ha obtenido. Este usuario aún no es un “usuario XWiki”. Este mismo Servlet se encargará de capturar la dirección a la que el usuario inicialmente quería acceder en XWiki y lo redirigirá allí de nuevo, siempre y cuando los resultados de Viafirma hayan sido válidos.

Por otro lado, extenderemos la clase XWikiAuthServiceImpl que implementa el servicio básico de autenticación de XWiki, introduciendo la posibilidad de realizar el Login en XWiki a partir de un UsuarioGenericoViafirma que tenemos en Sesión, para esto usaremos el API nativo de XWiki.

Por simplicidad para este ejemplo he adoptado la siguiente política de logado: dada una persona con NIF 12345678Z, su “Usuario XWiki” correspondiente será XWiki.12345678Z, es decir, debe existir un usuario dado de alta en XWiki cuyo Login coincida con el DNI de la persona. Cuando tengamos un UsuarioGenericoViafirma, consultamos su NIF y le preguntamos la XWiki a través de su API si existe usuario con ese Login. ¿Podría hacerse de forma más elaborada? Por supuesto, en vez de buscar un usuario con Login igual al Nif, podríamos haber definido una propiedad nueva para los Usuarios XWiki y para usarlo con este propósito, cuando lo hagáis no dudéis en poner vuestros comentarios al final de este post.

La secuencia de llamadas entre todos estos componentes lo podemos ver aquí:

Vamos a ir explicando paso a paso cómo hacer todo esto:
Paso 1.- Modificación del formulario de Login

Debemos editar el fichero templates/login.vm e introduciremos la redirección al servlet. Os propongo dos opciones, un enlace dentro de formulario ya existente y un formulario nuevo (para nuestro ejemplo funcionarán los dos):

...
<form>
...
#template("viafirmaLink.vm") <-Hiperenlace: opcion A
...
</form>
#template("viafirmaForm.vm") <- Formulario: opción B
...

Posteriormente copiaremos los ficheros viafirmaLink.vm y viafirmaForm.vm dentro del directorio templates.
Contenido de viafirmaLink.vm:

<div style="margin: 1em;">
 <a href="viafirma.login">ACCESO CON CERTIFICADO DIGITAL</a>
 <br/>
</div>

Contenido de viafirmaForm.vm:

<form id="loginFormViafirma" action="viafirma.login" method="post">
 <div>
 <fieldset>
 <legend>Certificado Digital</legend>
 <div><span><input type="submit" value="VIAFIRMA"/></span></div>
 </div>
</form>

Vemos que las dos opciones propuesta envian al usuario a la URL http://xwikiserver/…/viafirma.login .

Paso 2.- Implementación de un Filter, que será el encargado de capturar las peticiones a …/viafirma.login y enviar al usuario hacia Viafirma para que se autentique:

package org.viafirma.xwiki;
public class AuthenticationFilter implements Filter { ... }

Paso 3.- Implementación de un Servlet que recogerá de vuelta el resultado ofrecido por parte de Viafirma tras el análisis del certificado, capturando las peticiones a …/viafirmaAuthentication y coloque en sesión al usuario UsuarioGenericoViafirma:

package org.viafirma.xwiki;
public class AuthenticationServlet extends ViafirmaClientServlet implements Serializable { ... }

Paso 4.- Implementaremos un mecanismo usando otro Filter, para que Viafirma use una CSS definida por nosotros mismos. Viafirma “pide” por defecto una CSS llamada viafirmaStyle.css. En este ejemplo hemos optado por que XWiki sirva el CSS que usará Viafirma, aunque quizás lo más conveniente sea colocar este CSS en un servidor externo, por ejemplo un Apache, pero de todos modos vamos a hacerdo a modo de ejemplo. Bastaría con colocar una regla en Apache (por ejemplo) para que las peticiones al archivo viafirmaStyle.css no pasen a la XWiki, esto os lo dejo a vosotros.

Paso5.- Extenderemos el Servicio de Autenticación de XWiki, que sustituirá a la que tiene por defecto esta plataforma:

package org.viafirma.xwiki;
public class ViafirmaAuthImpl extends XWikiAuthServiceImpl implements  Serializable { ... }

Posteriormente, deberemos modificar el fichero xwiki.cfg de XWiki añadiendo o modificando:

xwiki.authentication.authclass=org.viafirma.xwiki.ViafirmaAuthImpl

Paso 6.- Configuraremos el web.xml de XWiki para dar de alta estos Filters y Servlets que hemos creado, adaptando los valores de los parámetros a nuestro entorno (url de Viafirma y ruta al css):

...
 <filter>
 <filter-name>ViafirmaLoginFilter</filter-name>
 <filter-class>org.viafirma.xwiki.AuthenticationFilter</filter-class>
 <init-param>
 <param-name>VIAFIRMA_URL</param-name>
 <param-value>http://viafirma.viavansi.com/viafirma</param-value>
 </init-param>
 <init-param>
 <param-name>VIAFIRMA_WS</param-name>
 <param-value>http://viafirma.viavansi.com/viafirma</param-value>
 </init-param>
 </filter>
 <filter>
 <filter-name>ViafirmaStyleFilter</filter-name>
 <filter-class>org.viafirma.xwiki.ViafirmaStyleFilter</filter-class>
 <init-param>
 <param-name>PATH_CSS</param-name>
 <param-value>D:/xwiki/skins/colibri/colibri.css</param-value>
 </init-param>
 </filter>

 <filter-mapping>
 <filter-name>ViafirmaLoginFilter</filter-name>
 <url-pattern>*.login</url-pattern>
 </filter-mapping>
 <filter-mapping>
 <filter-name>ViafirmaStyleFilter</filter-name>
 <url-pattern>*.css</url-pattern>
 </filter-mapping>
 ...
 <!-- Servlet de Autenticación de Viafirma-->
 <servlet>
 <servlet-name>viafirmaAuthentication</servlet-name>
 <servlet-class>org.viafirma.xwiki.AuthenticationServlet</servlet-class>
 </servlet>
 <servlet-mapping>
 <servlet-name>viafirmaAuthentication</servlet-name>
 <url-pattern>/viafirmaAuthentication/*</url-pattern>
 </servlet-mapping>

Finalmente tendremos esto:

Teneis el proyecto mavenizado y todos los fuentes usados en este ejemplo aquí:

Para integrar este ejemplo en XWiki, sólo es necesario:

1. Empaquetar las clases generadas en un .jar y copiarlo en el WEB-INF/lib de XWiki, también deberá copiar en esa carpeta todas las librerías dependientes.
2. Realizar las modificaciones anteriormente indicadas en el formulario de Login.
3. Copiar los archivos .vm a la ruta indicada anteriormente.
4. Modificar y configurar el web.xml de XWiki.

Aquí os dejo unas capturas de pantalla para demostraros que todo esto funciona correctamente

Formulario para logarnos:

Finalmente, vemos que XWiki nos ha logado correctamente:

Selección del Certificado Digital en Viafirma, vereis que tiene el CSS que queremos (obviamente ese CSS se puede mejorar) :

Finalmente veremos que ya estamos logados en XWiki (enhorabuena !!) :

Esto nos da por pensar en próximos capítulos: ¿publicación de contenidos firmados digitalmente? Quién sabe…

Un Saludo.

En él se recogen una serie de directrices que pretenden ser un conjunFto de normas o pautas a los que las Administraciones Públicas han de ajustarse con el objetivo de permitir y favorecer  la interoperabilidad entre los distintos sistemas de información dentro de la propia Administración.

Podeis ver una introducción AQUI

Y de forma más extendida en el B.O.E.

Este Real Decreto no abandona una visión distribuida de los diferentes sistemas de información, donde cada Administración puede dar respuesta a determinados problemas que sólo surgen dentro de un ámbito muy concreto. Pero por otro lado puede ser muy útil para evitar la reinvención de la rueda, es decir, de soluciones que pueden ser aplicadas en distintas situaciones, algo muy común a día de hoy quizás por desconocimiento, quizás por “desorganización” dentro de la propia Administración.

Este texto apuesta claramente por una publicación vía electrónica de todos los servicios de la Admón. de forma organizada a través de Inventarios, gestionados por las Administraciones locales pero a su vez que se integren dentro de un Inventario a nivel Nacional, sin olvidar en ningún momento el aspecto Semántico de los diferentes servicios.

Se hace un guiño a favor del uso de estándares abiertos y de herramientas genéricas, pero a su vez, se puntualiza que se puedan usar otros con la finalidad de favorecer el acceso al ciudadano y el no estancamiento tecnológico.

La Firma y Certificados Electrónicos se ha convertido en una herramienta muy útil y funcional, y como no podía ser de otra forma encontramos un amplio apartado dedicado a esto aplicado a la relación entre sistemas consumidores y publicadores de los distintos servicios.

Sobre los Documentos Electrónicos, se hace referencia al almacenamiento y disponibilidad de dicho documento, siempre bajo unas reglas de seguridad sin pasar por alto la famosa LOPD, siguiendo las principios de integridad, autenticidad, confidencialidad, etc. Se habla también de los formatos en que ha de almacenarse los documentos y de la digitalización de los documentos en soporte papel.

Sin duda, vemos que éste es un texto bastante genérico y más que ser una enumeración de normas/estándares concretos, algo que sería cuanto menos utópico si hablamos a nivel nacional,  se trata de una apuesta y declaración de intenciones bastante condundente.

Después de haberle dedicado unos minutos a este texto y cuál sería su implicación a nivel autonómico, más concretamente en Andalucía, sin duda alguna se me viene a la cabeza una palabra: PLATINA. Desde hace algún tiempo la Administración Andaluza ya viene observando la problemática de tener un batiburrillo de servicios muchas veces difícil de conectar entre si y viene apostando por esa plataforma como “anillo único para unirlos a todos”.

Sin duda, la interoperabilidad entre sistemas,  es un tema que quizás al inicio de los tiempos no se veía tan necesario, pero si no hemos abordado ya a día de hoy: ¡vamos tarde!

supongo que todos conoceis la fabulosa funcionalidad que tiene Redmine respecto al acceso a un sistema de control de versiones de código fuente, como el caso que nos ocupa: Subversion. Permite consultar las diferentes revisiones, mostrando los distintos comentarios de cada revisión, permite acceder a la estructura en árbol de directorios, etc…

En la situación que os quiero comentar teníamos una instalación de Redmine totalmente funcional, con la conexión a Subversion funcionando a las mil maravillas, vía https. Sin embargo de un día para otro dentro de la pestaña “Repositorio” del proyecto dejamos de ver la estructura de carpetas y ya no se actualizan la información acerca de las sucesivas revisiones que se iban generando en el repositorio, pero sí se veían otras revisiones anteriores.

El primer paso fue mirar en el log de Redmine y se comprobó que se estaba generando un error bastante “inquietante”:

Error parsing svn output: #<REXML::ParseException: No close tag for /lists/list>
…./jruby/lib/ruby/1.8/rexml/parsers/treeparser.rb:27:in `parse’
…./jruby/lib/ruby/1.8/rexml/document.rb:204:in `build’
………………….
………………….

Tras esto, nos conectamos con un cliente subversion y comprobamos que el repositorio estaba totalmente operativo y las revisiones se estaban generando correctamente (incluso con los respectivos comentarios): ¿qué podrá estar pasando? (si quereis ir directo a la solución sólo id al final del post xD)

Como suele ser muy habitual investigamos acerca de la conexión https que se establece con Subversión, ya que en este caso Subversion se sirve vía https. Pues bien, nos dimos cuenta que el certificado del servidor (el que sirve Subversion)  estaba caducado: ¡¡ Eureka !!

Para solucionar esto simplemente actualizamos el certificado del servidor Subversion y volvimos a intentar de nuevo consultar la pestaña Repositorio de Redmine, pero no… sigue el mismo problema, no se actualizan las revisiones.

Tras poner nuestras neuronas a trabajar nos dimos cuenta que no habíamos introducido el nuevo certificado como “confiable” para Redmine… muy bien, pero ¿cómo hacer esto? Para explicar esto voy a comentar cómo Redmine se conecta con Subversion y obtiene toda esa metainformación que muestra (esto lo podemos ver en el código fuente de Subversion.rb correspondiente al adaptador de Subversion que tiene Redmine):

Redmine no hace más que ejecutar la orden “svn –xml list <url_repositorio>” y esto devuelve (o debería) un XML con toda la información, algo tan simple como eso ¿cómo puede dar problemas?

Nos disponemos a ejecutar esa misma orden de forma manual desde la máquina donde tenemos instalado Subversion y ¡sorpresa!: no nos retorna un XML correcto. A continuación, ejecutamos un simple comando de listado “svn list <url_repositorio>” y obtenemos un mensaje de aviso, preguntándonos si deseamos rechazar / aceptar de forma permanente o temporal el certificado de https://servidorSubversion . Por supuesto lo aceptamos de forma permanente (pulsando ‘P’)  y a continuación nos pidela contraseña del usuario logado en el sistema y usuario/contraseña de acceso a Subversion.

A partir de ahí todo debería funcionar, pero no: hay un pequeño detalle más. Debemos repetir el paso anterior ejecutando el comando “svn”con el mismo usuario que hace correr el servicio de Redmine. Parece que el cliente svn tiene un almacen de certificados “confiables” distinto para cada usuario que lo ejecuta.

Una vez hecho todo esto nuestro Redmine se conecta perfectamente con Subversion y obtiene toda la información actualizada.

SOLUCION.- A continuación os resumo la solución con un par de pasos que se deben seguir, espero que os resulten útiles.

1. Ejecutar por consola el comando “svn list <url_subversion>” en la máquina en que corre Redmine y con el mismo usuario que hace correr el servicio.
2. En el diálogo que se muestra: aceptar el certificado como confiable de manera permanente (‘P’) e introducir los uusuarios/contraseñas que se solicitan.
3. Ejecutar por consola el comando “svn –xml list <url_subversion>” y comprobar ahora que sí nos devuelve un XML con todos los metadatos.
4. Comprobar que Redmine nos muestra ahora los datos correctos.

Versión de Redmine utilizada: Redmine 0.8.0.stable

Personalmente creo que este tipo de “errores” se deberían reportar de forma automática por parte de Redmine (mostrando una información más intuitiva) y es de esperar que en futuras versiones tomen en cuenta todos las numerosas incidencias que podeis ver en el bugtracker del proyecto Redmine respecto a este error.

Un Saludo a todos.
Namaste y buena suerte.

esta vez os escribo para comentaros un quebradero de cabeza más que me ha dado Windows Vista e iTunes (con Quicktime), un par de problemas:

1) Cada vez que arranco el iTunes, se vuelve a reinstalar.

2) Se produce un error de ActiveX al abrir el Quick Time Player: Error 46

Para el primero de los problemas, la solución fue un poco drástica: eliminar el acceso directo del iTunes que tenemos en el Escritorio y crear un nuevo acceso directo al iTunes.exe que tenemos en nuestra carpeta de “%Program Files%/iTunes”, lo colocamos en nuestro Escritorio y aquí no ha pasado nada

Para solucionar el segundo error ya tenemos que hacer un par de cosillas más.

Primero os comento cuál es la causa de este error:
Parece ser que al instalar QuickTime Player las claves introducidas en el registro  de Windows Vista no adquieren permisos de acceso correctos. Exactamente lo que ocurre es que nuestro usuario (sea Administrador o no) no tiene acceso ni siquiera de lectura a dichas claves.

Esto os lo cuento yo y queda muy bonito ¿verdad?, pero ¿cómo podeis comprobar esto vosotros mismos?
Pues descárguense el programa Process Monitor  de Microsoft. Tras instalarlo y dejar abierta la aplicación, intenten abrir QTPlayer y miren los errores que se muestran en el Proces Monitor producen al intentar abrir el QuickTime Player, seguro les aparecerá “ACCESS DENIED” a distintas claves del registro (podeis filtrar las lineas que se muestran).

Pues bien, parece que tenemos claro ahora cuál es el problema, ¿cómo “repcuperar” los permisos de lectura sobre dichas claves?

Si hacemos lo típico, ejecutar “regedit” e intentar modificar los permisos manualmente veremos que no tenemos autorización para realizar estos cambios en esas claves afectadas. ¡Vaya chasco!

Bien, busquemos otra forma de modificar estos permisos. Usemos ahora otro programa de Microsoft llamado SubInACL: esta es una herramienta de administración, para modificar y consultar distintos parámetros del sistema como claves del registro, servicios, etc., pero vamos al grano.

Con este programa tenemos ahora que modificar los permisos asignados a estas claves que no pudimos modificar con “regedit.exe” .

Una vez descargado e instalado, debemos copiar el script que contiene Script.zip y descomprimir el .cmd en la carpeta”%Program Files%\Windows Resource Kits\Tools“, que es donde se debe haber instalado SubInACL.
Este script es parecido a otros que aparecen en algunos foros, pero este en concreto contiene algunas correcciones realizadas por mi y adaptado a Windows Vista en Español, no en Inglés. Recomiendo hacer una copia de seguridad del registro antes de ejecutar nada, siempre es conveniente trabajar sobre seguro.

A continuación, abramos una terminal de consola (Inicio / Ejecutar / cmd.exe para los no iniciados) y vayamos a la carpeta donde copiamos el script. Ejecutemos en la consola “resetSpanish.cmd” y veamos en el log mostrado que no salgan errores:

Done:        X, Modified        X, Failed        0, Syntax errors        0

lo importante es que “Failed”  y “Syntax errors” salgan a cero.

Este script hay que lanzarlo con un usuario Administrador y recomiendo desactivar el sistema de protección de cuentas de que dispone Windows Vista (Panel de Control / Cuentas de Usuario / Activar o desactivar el control de cuentas de usuario),
una vez lanzado el script podeis volverlo a activar.

Una vez hecho esto, podremos abrir “QuickTime Player” sin obtener el dichoso error 46.

Y recordad: siempre tenemos una alternativa en LINUX …

Namasté.

Al final tendremos algo parecido a esto, introduciendo una nueva entrada en la lista de plugins:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<phase>process-sources</phase>
<goals>
<goal>wsimport</goal>
</goals>
</execution>
</executions>
<configuration>
……
</configuration>
<dependencies>
… lista de dependencias del plugin …
</dependencies>
</plugin>

Para el caso que nos ocupa, vamos a suponer que tenemos un WSDL (Web Services Description Language) desplegado en un servidor que requiere Usuario y Contraseña, ¿cómo podemos indicarle a este plugin la URL al fichero descriptor del servicio web? ¿cómo le indicamos el usuario y contraseña?
Pues todo esto se hace en la sección “configuration“.
Tenemos mucha documentación disponible la web relacionada con wsimport.

Un sabio amigo mío se quejaba una vez en clase de programación, diciendo que la programación era como empanar filetes, y que no le podían enseñar a hacer filetes empanados si antes no se había comido ninguno. Pues bien, siguiendo esta corriente filosófica os pongo un ejemplo y os comento después las secciones que nos afectan:
<configuration>
<wsdlUrls>
<wsdlUrl>[http/https]://[servidor1]:[puerto1]/[rutaAlDescriptor1]?wsdl</wsdlUrl>
<wsdlUrl>[http/https]://[servidor2]:[puerto2]/[rutaAlDescriptor2]?wsdl</wsdlUrl>
</wsdlUrls>
<packageName>mipaquete.ws.client</packageName>
<sourceDestDir>${basedir}/src/main/java</sourceDestDir>
<verbose>true</verbose>
<extension>true</extension>
<xadditionalHeaders>true</xadditionalHeaders>
<xdebug>true</xdebug>
<xauthFile>${basedir}/src/site/resources/auth.conf</xauthFile>
</configuration>

En primer lugar definimos una lista de URL a los distintos ficheros descriptores y posteriormente el paquete en el que generarán las clases consumidoras del servicio web.
Otro parámetro importante en el caso que nos ocupa es “xauthFile”. Este parámetro le indica al plugin una ruta a un fichero, en dicho fichero se almacena el Usuario/Contraseña de acceso a la lista de wsld’s anterior.

Este fichero debe contener una serie de lineas de la siguiente manera:
[http/https]://[usuario]:[contraseña]@[servidor]:[puerto]/[rutaAlDescriptor]?wsdl

Tantas líneas como se requieran según las URL’s indicadas en “wsdlUrls”.

Pues bien, si generamos a continuación las clases, nuestro plugin le pedirá a los servidores los distintos wslds’s y se autenticará correctamente usando el fichero auth.conf.

¿Hemos acabado ya?
Pues hemos hecho la mitad, por ahora lo que tenemos es una serie de clases que pueden consumir los distintos servicios web.

Pregunta, ¿Se volverá a requerir Usuario/Contraseña cuando se invoque a unos de estos métodos clientes del servicio web?
Pues sí.

¿Y se supone que ese usuario y contraseña lo coge del fichero de autenticación anterior?
Pues no, este fichero sólo nos ha servido para generar las clases clientes, nada más.

Entonces, un segundo paso es introducir un sistema de autenticación dentro de nuestro cliente, ¡vamos a ello!

Una de las posibles opciones es generar una clase de autenticación, que extienda de “java.net.Authenticator”.
Su implementación es bastante simple, os pongo un ejemplo:


import java.net.Authenticator;
import java.net.PasswordAuthentication;

public class MiAutenticador extends Authenticator {
static final String user = “miNombreDeUsuario”; // Login
static final String pass = “miContraseña”; // Password

public PasswordAuthentication getPasswordAuthentication() {
return (new PasswordAuthentication(user, pass.toCharArray()));
}
}

Creo que no merece más comentarios, sólo indicar que los atributos “user” y “pass” deberían leerse de un fichero de propiedades por ejemplo, pero de ninguna manera deberían estar a fuego en nuestro código.

Ahora que tenemos nuestra clase de autenticación ¿cómo “conectarla” en nuestras clases clientes?
Pues bien, lo que debemos hacer es indicar que deseamos usar este “Autenticador” justo antes de la llamada al
webService que requiere dicha autenticación, algo como:

........
Authenticator.setDefault(new MiAutenticador());
API_webService.metodo(params);
........


Esto se puede implementar de manera elegante usando el patrón de Diseño Decorador (Decorator Pattern ), de manera que por defecto se “decore” los distintos métodos del api webService con nuestro autenticador.

Pues nada más, espero haber sido claro.

Gracias, namasté y buena suerte.

Una de estas inquietantes relaciones es la que podemos observar en el logo de la Corporación Dharma con la iconografía de una corriente filosófica oriental conocida como “Bagua”, pero como digo, ya hay mucho contenido en la red acerca de esto.

Después de todo esto lo que quiero es contaros cómo podemos hacer más atractiva, para nosotros los Lostadictos, la imagen con la que se inicia el IDE de Eclipse, es bien simple.

En la carpeta donde tenemos instalado/desplegado nuestro Eclipse tenemos que irnos a:

plugins\org.eclipse.platform_3.3.2.R33x_v20071022

aunque dependiendo de nuestra versión puede ser distinta.

En cualquier caso lo que tenemos que hacer es sustituir el archivo splash.bmp, que es el que se usa durante el inicio de Eclipse y poner en su lugar este otro:

Así cada vez que tengamos que arrancar el IDE se nos vendrá a la mente todos los personales que habitan en la Isla: Benjamin Linus, Jhon Lock, Jack Shephard… la Corporación Dharma…

Muchas gracias, namaste y buena suerte.

Estaba desarrollando una aplicación web (jsf, seam, etc.), en unos de las páginas se generaba un listado en el que se muestra datos sobre una serie de documentos.

Existe la posibilidad de descargar estos documentos, que no son más que archivos pdfs, a través de una aplicación cliente que a su vez se despliega con Java Web Start con JNLP en la misma aplicación web.
El problema es el siguiente:

El usuario X a través de la aplicación ve el listado, pero el JNLP no comparte la misma sesión que el navegador, luego no podemos acceder a dicho listado, ya que se trata de un objeto visible en el conexto Sesión.
Una primera solución consistiría en pasar los distintos identificadores de los documentos listados al JNLP a través de parámetros en la URL. Pero existe el problema de que el listado sea demasiado largo y la URL resultante sea demasiado larga, problema con caracteres no aptos para una URL, etc.  Podemos jugárnosla, optar por esta “solución” y rezar para que nunca se produzca esa situación… no mola, sigamos pensando y busquemos otra solución.
Posteriormente podemos pensar en identificar el listado y mantener los elementos relacionados en una caché. Caché que no se alojará a nivel de Sesión, sino en el conexto de la Aplicación (ServletContext), para que esté visible desde todas las sesiones (usuario web y usuario jnlp).

Pero, ¿cómo implementamos esta caché?
Usemos un simple HashMap:

El primer usuario entra, hace un listado, se introduce en la caché el listado.
El mismo usuario genera otro listado, se introduce en la caché.
Entra otro usuario, lo mismo, un nuevo elemento a la caché.
Trás introducir cinco mil elementos en la caché vemos que la aplicación ya no puede más y dice ‘¡¡ hasta aquí hemos llegado !!’.
¿Qué ha pasado? Pues que la caché ha almacenado muchísimos listados y se ha ‘comido’ muchísima memoria.

¿Cómo podríamos solucionarlo? Establezcamos un tamaño máximo de cacheo, lo que nos llevará a proponer una determinada política de reemplazo (aleatoria, LRU, LFU, FIfo). Demasiadas cosas para pensar, y teniendo en cuenta las leyes de Murphy ‘Si algo puede fallar, fallará’, así que mejor sigo investigando otra forma de implementar la caché.

Y ¿se podría implementar la caché de tal forma que el recolector de basura de Java vaya borrando sus elementos cuando se esté consumiento demasiada memoria? Esto nos lleva al concepto de “Referencia débil”.

Recordemos los tipos de referencias en Java: Fuertes, débiles, blandas y fantasma. En la práctica las débiles y las blandas son tratadas igual por la Máquina Virtual Java (no sigo explicando esto porque no es el objetivo de este post).

Cuando el recolector de basura se ejecuta y va recorriendo los distintos objetos, si estos objetos son apuntados por referencias débiles se eliminan, tal y como suena, esto no ocurre con las referencias fuertes.
¿Cómo podemos aprovechar esto en nuestra caché? Pues a través de la clase WeakHashMap (véase java.util.WeakHashMap). Esta clase implementa java.util.Map, pero las keys se almacenan como objetos con referencias débiles. Con esto se dejará la responsabilidad de vaciar la caché al recolector de basura.
Pues nada más, con esto hemos conseguido implementar una caché visible desde las distintas sesiones en una aplicación y gestionada por el Recolector de Basura.

A continuación os pongo un pequeño código de ejemplo para que podais ver la diferencia de funcionamiento entre un HashMap y un WeakHashMap.

import java.util.HashMap;
import java.util.Map;
import java.util.WeakHashMap;

public class Prueba {
	public static void main(String[] args) {
		Map map = new HashMap();
		Map weakMap = new WeakHashMap();
		imprime("map", map);
		imprime("weakMap", weakMap);
		for (int i = 0; i < 50; i++) {
			System.out.println("=======================n=======================");
			System.out.println("Insertando: " + i);
			System.out.println("Insertando: " + i + "_key");
			map.put("" + i, "" + i);
			map.put("" + i + "_key", "" + i);
			weakMap.put("" + i, "" + i);
			weakMap.put("" + i + "_key", "" + i);
			imprime("map", map);
			imprime("weakMap", weakMap);
			if (map.keySet().size() != weakMap.keySet().size()) {
				System.out.println("DISTINTO TAMAÑO !!!");
			}
			System.out.println("Eliminando: " + i);
			map.remove("" + i);
			weakMap.remove("" + i);
			imprime("map", map);
			imprime("weakMap", weakMap);
		}
	}

	private static void imprime(String texto, Map map) {
		System.out.println("n-----------" + texto + "-----------");
		System.out.println("Size: " + map.keySet().size());
		System.out.println("Map:" + map);
		System.out.println("------------------------------n");
	}
}

Por cierto, quien quiera seguir investigando las referencias débiles puede probar con la clase java.lang.ref.WeakReference.

Saludos.

Básicamente a la Autenticación le corresponde la tarea de ver quién es el usuario y a la Autorización le corresponde permitir o no el acceso a las distintas zonas de una aplicación web a partir, por ejemplo, de su perfil en la aplicación.

En este post me centraré en la Autorización, ya que Jboss Seam tiene mucho que decir al respecto, y os muestro una posible implementación para controlar el acceso de un usuario a una “zona” determinada de una aplicación.

Supongamos una aplicación con dos zonas, una zona de administración y una zona de acceso a usuarios. Para la primera zona (http://<aplicacion>/admin) se necesita que el usuario posea el rol “admin”, mientras que para la segunda(http://<aplicacion>/usuario) el rol “usuario”, nos centraremos en la primera, la segunda os la dejo como ejercicio…
También supongamos que tenemos un objeto “authenticator” que implementa los distintos métodos que requiere Seam respectos a la autenticación.
Normalmente, cuando un usuario entra en la aplicación sin haberse logado Seam lanza la excepción “NotLoggedInException” y posteriormente se redirige al usuario a la correspondiente pantalla para logarse. Este comportamiento se controla mediante el archivo “pages.xml”:
<exception class=”org.jboss.seam.security.NotLoggedInException“>
<redirect view-id=”/index.xhtml“>
<message>Usted debe estar logado para acceder a esta página.</message>
</redirect>
</exception>

Tras introducir los datos para el login (usuario y contraseña, certificado digital, etc.), el método “returnTo” del “autenticator” nos redirige a la zona adecuada, según observemos el rol que tiene asignado el usuario, esto lo podemos indicar en el fichero “components.xml”:
<event type=”org.jboss.seam.postAuthenticate“>
<action execute=”#{authenticator.returnTo}“/>
</event>

Una primera propuesta (adelanto que no es la definitiva), para controlar el acceso a la zona “admin” podríamos definir en el pages.xml lo siguiente:

<page  view-id=”/admin/*” login-required=”true”>
<restrict>#{s:hasRole(‘admin’)}</restrict>
</page>

<exception class=”org.jboss.seam.security.AuthorizationException“>
<end-conversation/>
<redirect view-id=”/index.xhtml“>
<message>Usted no posee los privilegios suficientes para acceder a esta zona.</message>
</redirect>
</exception>

Que en Castellano significa: para las peticiones a “/admin/*” comprueba que el usuario tiene el rol “admin”. Cuando no lo tenga se lanzará la correpondiente excepción “AuthorizationException” y se le redirigirá a “/index.xhtml” mostrándose el mensaje “Usted no posee los privilegios suficientes para acceder a esta zona.”

Quizás si no vamos más allá podamos pensar que tenemos todo controlado, pero ahora imaginemos la siguiente situación:

1) Un usuario entra en la aplicación, se va a la página de Login (por el NotLoggedInException capturado) y se loga correctamente, sin rol “admin” por lo que no debería tener acceso a /admin, de hecho el “return True” le redirige a la zona pública.
2) El usuario que se cree un piratilla escribe a fuego en la barra de direcciones del navegador “/admin” y le da al botón de Enter…

¿Qué pasará?
Lo esperado es que si el usuario pide “manualmente” en /admin tras logarse y obtener únicamente el rol “usuario”, la aplicación genera un AuthorizationException y se le redirigirá a /index.xhtml (pantalla inicial de bienvenida)…
Hazlo y comprobarás que no… el usuario tiene acceso a la zona de administración.

¿Y porqué? Pues una de las causas que he leído en el foro de jboss es que “esa excepción no se trata en la fase de render del JSF” y entonces no tiene el comportamiento que se indica en el pages.xml. Quizás no haya que buscar más porqués y proponer otra solución.
Una segunda propuesta, bastante atractiva aunque después propondré otra ligeramente más refinada, trata de que la aplicación capture correctamente la excepción AuthorizationException, nos redirija al index.xhtml y no suponga tener que redefinir arquitectura de ningún tipo… allá va:
Deberemos crear un nuevo “Controller” como este, especialmente dedicado a controlar el acceso a la zona de administración, quizás se podría usar cualquier controller ya existente, pero así queda más limpito nuestro código (vease “asignación de responsabilidades”):
@Name(“authorizationAdminController”)
@Scope(CONVERSATION)
@Restrict(“#{s:hasRole(‘admin’)}”)
public class AuthorizationAdminController extends ControllerJsfApplication {
public void forceCheckAdminAuthorization(){}
}

Vemos que queda un controller práctiamente vacío.
Debido a @Restrict sólo podrán “invocar” a este controller los Identities(usuarios logados) con rol “admin”.

Ahora modificamos nuestro pages.xml de la siguiente forma:
Donde antes teníamos:
<page  view-id=”/admin/*” login-required=”true”>
<restrict>#{s:hasRole(‘admin’)}</restrict>
</page>

Ahora tenemos:
<page  view-id=”/admin/*” login-required=”true” action=”#authorizationAdminController.forceCheckAdminAuthorization}“>
</page>
Con lo que al hacer una petición a “/admin” se ejecutará el action ( authorizationAdminController.forceCheckAdminAuthorization ), el cual no podrá estar accesible si no se posee el rol “admin”, debido a la anotación @Restrict del controller. Si el identity no posee este rol se lanza AuthorizationException, igual que pasaba antes sin usar el controller, sólo que ahora esta excepción si se captura correctamente y se realiza la redirección indicada en el pages.xml.
También deberemos mantener:
<exception class=”org.jboss.seam.security.AuthorizationException”>
<end-conversation/>
<redirect view-id=”/index.xhtml”>
<message>Usted no posee los privilegios suficientes para acceder a esta zona.</message>
</redirect>
</exception>
Con esta modificación conseguimos proteger correctamente la zona “/admin”, un usuario que intente logarse y posteriormente entrar en “/admin”, esta vez se le mostrará el index.xhtml con el mensaje: “Usted no posee los privilegios suficientes para acceder a esta zona.”
Una tercera solución es simplemente un refinamiento de la segunda, y llegamos a ella a través de la pregunta:
Si tenemos 50 zonas de protegidas, ¿tendremos que implementar 50 Controller semejantes a “AuthorizationAdminController” pero con un @Restrict distinto?
Pues no, la solución está en no anotar el Controller con @Restrict, sino anotar el propio método, así podríamos tener un único controller y N métodos para comprobar distintas autorizaciones:

@Name(“authorizationAdminController”)
@Scope(CONVERSATION)
public class AuthorizationAdminController extends ControllerJsfApplication {

@Restrict(“#{s:hasRole(‘admin’)}”)
public void forceCheckAdminAuthorization(){}

@Restrict(“#{s:hasRole(‘usuario’)}”)
public void forceCheckUsuarioAuthorization(){}

………

@Restrict(“#{s:hasRole(‘XXXX’)}”)
public void forceCheckXXXXXXXAuthorization(){}

}

Indicando en el pages.xml el método “forceCheck X Authorization” que corresponde a cada zona las protegeremos convenientemente.

Pues con esto ha acabado lo que ha intentado ser una explicación.

Nunca olvidaré esta “primera vez” en que escribí en xnoccio, espero que hallais disfrutado tanto como yo.

Que la suerte os acompañe !!