Xnoccio

Al volver a utilizar un proyecto Java EE que invocaba a un servicio web mediante Axis, y que funcionaba correctamente en Windows, me he encontrado con un error bastante extraño que al invocar decía:

java.util.regex.PatternSyntaxException: Dangling meta character ‘*’ near index 0 *.local

Al principio pensaba que podría deberse a que la JVM no estuviese captando la configuración de salida por el proxy de la oficina, pero advertí que el error se daba tanto saliendo a través del proxy, como puenteándolo.

Pues bien, con un poco de Google, me encontré la solución.  Resulta que Tomcat dentro de Eclipse recupera la configuración de red de Leopard, y por defecto la variable nonProxyHosts (Omitir ajustes proxy para estos servidores y dominios) tiene el siguiente valor:

*.local, 169.254/16

Que no le gusta nada a Axis2 (se quejaba del *.local)… así que la cambiamos, eliminando esos valores. Para ello, nos vamos a Preferencias del Sistema -> Red -> Avanzado -> Proxies.

Y reiniciando el Tomcat, funcionó correctamente. Viva interné.

Los señores de Alcakon han tenido a bien introducirnos en la lista de “Professional OpenCms solution providers in Europe“… Con nosotros ya somos 9 las empresas españolas que desarrollan sobre OpenCms recogidas en el listado: Adequa (Barcelona), Consoltic (Málaga), Drago Solutions (Madrid), Encamina (Valencia), GPM Factoría Internet (Salamanca), inxtenso (Barcelona), Open Sistemas (Madrid), openTrends (Barcelona) y Viavansi (Sevilla). Eso sí, como está por orden alfabético, salimos los últimos del listado de proveedores :-D

Enhorabuena a mis compañeros del departamento de Desarrollo de OpenCms.

He venido observando que hay una codificación INE de 6 dígitos en lugar de los 5 dígitos tradicionales. Por ejemplo, donde Sevilla solía tener un código INE 41091, ahora tiene un nuevo código 410917. Este código es el mismo que el anterior, más un dígito adicional que a priori parece ser un dígito de control.

Estos códigos nuevos se pueden descargar en formato Excel de la URL:

http://www.ine.es/daco/daco42/codmun/codmun08/08codmunmapa.htm

Parece ser que la codificación es la anterior, con la adición de un sexto dígito de control, como se menciona en esta dirección (”el último es un dígito de control que, asignado mediante una regla de cálculo, permite la detección de errores de grabación y modificación”).

Sin embargo, no he sido capaz de encontrar ninguna referencia a cómo se realiza este cálculo. En anexos de algunos documentos he encontrado referencias a un cálculo basado en un módulo 11, pero he comprobado que ésta no es la vía correcta.

Posibilidades:

• El dígito se calcula mediante una fórmula arcana guardada en secreto por alquimistas que perduran desde la época de la piedra filosofal.
• Es más fácil, pero no está en Google.
• Está en Google, pero no sé buscar.
• Es un número aleatorio para jorobar, realmente es una nueva codificación y punto, a guardarla en base de datos. Lo que pusieron mencionando una “regla de cálculo” era para despistar.

Se acepta ayuda. Gracias!

http://descargas.orange.es/descargas/version/eclipse-sdk/3_1_2/

La descripción es brutal:

“Programa muy útil para los aficionados a la astronomía. Se trata de contemplar un eclipse y aprender de que manera se produce.
Consta de trece fotografías de la trayectoria, las cuales nos irá enseñando poco a poco, con una breve expliación de cada una de las fases.”

Se ve que lo han probado mucho… ahora bien, el crack que se inventó lo de las trece fotografías de la trayectoria se merece un homenaje X-D

Como saben hasta las hormiguitas del campo, el pasado día 11 de julio se puso a la venta en España el famosísimo iPhone 3G de Apple, en exclusiva para la operadora Movistar.

Existe una gran cantidad de blogs que ya han dado suficiente información sobre sus características, pros y contras, detractores y admiradores…

Por mi parte, pudiendo reconocer fallos graves y con la inmensa desgracia de tener que irme a Movistar (y para más inri esas condiciones casi de esclavitud), he de reconocer que estoy muerto de ganas de comprármelo, pero no lo tengo. ¿Por qué? Pues porque, aunque todos los días llamo y en las tiendas hasta me reconocen la voz, es casi imposible encontrar un sitio (al menos aquí en Sevilla) con disponibilidad del gadget.

Desconozco dónde estará el problema. Supongo que será de origen (Apple) , aunque probablemente también haya habido una terrible falta de previsión de Movistar, totalmente inexplicable por otro lado, cuando tenían más de 200.000 interesados inscritos en la web destinado al iPhone (entre los que estaba yo).

El caso es que la indignación y las quejas crecen entre los potenciales clientes, pero ¿y en Movistar?

Simplemente basta echar unas cuentas. Más del 50% de esos 200.000 interesados eran, como yo, de otras compañías dispuestos a ejercer su derecho a la portabilidad. Es decir, por cada día que pasa sin conseguir su iPhone, Movistar deja de recibir su fracción del contrato que firmaría nuevo. Dado que el mínimo es de 24€/mes (15 para datos y 9 para voz), y lo más normal será un mínimo de  35€ (los 15 de datos y 20 de mínimo de voz), pues haciendo la cuenta de la vieja Movistar pierde un euro por cada día que está haciendo esperar a un usuario por su iPhone, si este usuario es de otra compañía. Si el usuario es de Movistar, al menos pierde lo correspondiente al plan de datos, de 15€/mes como mínimo… es decir, como mínimo, 0,5€ por día que pasa.

Viendo los problemas de distribución que hay ahora mismo, en nada de tiempo que pase la broma le está saliendo a Telefónica Móviles por varios millones de euros.

Además, Movistar se arriesga a perder al cliente que, presa del desánimo, puede acabar gastándose el dinero en un HTC Touch Diamond, por ejemplo, con un compromiso de permanencia en su compañía.

En definitiva,  yo como usuario estoy indignado, pero si fuese de la dirección de Movistar… estaría a) avergonzado, y b) indignadísimo, por las pérdidas diarias que este desastre les tiene que estar generando.

Resulta curioso cómo la tecnología va y vuelve por los mismos caminos. Partimos de máquinas con poquísima capacidad de cálculo y aplicaciones cliente- servidor, que cedían la mayor parte del esfuerzo de cálculo a una máquina central. Despúes evolucionamos hacia clientes ricos, aplicaciones web, RIA… y en paralelo el mercado se vuelve a plantear utilizar thin clients para los usuarios (como las Sun Ray), aplicaciones en modo ASP nuevamente centralizadas en un servidor…

En el desarrollo web estamos viviendo algo similar. Al principio los esfuerzos por la falta de estándares y la batalla entre IE y Netscape nos traía locos, obligándonos a distinguir qué navegador estaba rendeando la página mediante Javascript. La ausencia de CSS y la maquetación con tablas  hacía que apenas unos pocas combinaciones de sistemas operativos / resoluciones / navegadores daban resultados aceptables. La aparición de los estándares (con la siempre inquietante sombra de IE acechando) nos ayudó a evolucionar. Por otro lado, se podia aceptar como un estándar de mercado que las resoluciones de 640×480 ó 800×600 iban desapareciendo…

Pues véase en la figura una foto de salón que cada vez va a ser más frecuente: la misma página web visualizada en un televisor Full HD de altísima resolución, en un UMPC (en este caso, un Airis Kira) con un monitor de 7 pulgadas y una resolución de apenas 800×480, y en un Ipod Touch con una resolución de 480×320… ¿Alguien puede jurar que la resolución “óptima” es una concreta? En definitiva, deberíamos ir haciendo un rápido rollback de nuestras ideas previas sobre navegadores, resoluciones, sistemas operativos, etc. ¿Acaso alguien duda de que la web 3.0, si algún día la imagina alguien del todo, no será navegada por cualquier tipo de dispositivo móvil?

Es cierto que la adopción de estándares y CSS nos va a ayudar bastante en este tipo de tareas; a priori, una web con HTML bien marcado y unas buenas dosis de CSS puede ser navegada por un gran espectro de dispositivos. Sin embargo, la tecnología es un camino de ida y vuelta, y a nadie le debería de extrañar que en poco tiempo volvamos a tratar de detectar el sistema operativo / navegador cliente*, y personalizarle la interfaz…

Namasté y buena suerte.

*  Y como muestra, un botón: minid ha publicado un framework de desarrollo de aplicaciones para iPhone, basado en xhtml y CSS3 que puede rendear el navegador Safari del iPhone. Gracias a esto, podemos desarrollar aplicaciones web con una apariencia fiel de aplicativo de escritorio iPhone. Así que una misma aplicación web, distinguiendo el cliente, podría ser rendeada específicamente para iPhone. Si teneis uno, o un iPod Touch, probadlo que está bastante interesante.

En las listas de AccesoWeb de SIDAR mantuvimos en 2005 una interesante discusión sobre la compatibilidad entre los puntos de verificación de accesibilidad de WAI y la firma electrónica, que requiere realizar procesos en cliente con tecnologías obviamente ejecutadas en cliente (Javascript + Applet Java o Active X). En tres años ha habido realmente poca evolución a este respecto, y considero que la discusión se puede mantener vigente.

Sobre la firma electrónica 

No confundamos firma electrónica con autenticación con certificado. Podemos acceder (login) a una aplicación web con nuestro certificado, y que sea accesible. En lo que se refiere a la firma electrónica en una aplicación web, hay sin embargo una serie de conceptos claros. El proceso técnico es más o menos como el que sigue (ahorrando varios pasos para no hacer un post tipo Biblia):

1. El usuario introduce los datos que debe firmar. Esto puede ser de muchas formas; rellenar un formulario HTML, adjuntar un fichero, etc.
2. El navegador del usuario debe generar un resumen (digest) con un algoritmo hash (tipo MD5 o SHA-1) de la información a firmar.
3. El navegador debe utilizar la clave privada del certificado digital del cliente para encriptar esta información. Esta encriptación es simétrica; lo que se encripta con la clave privada podrá ser desencriptada con la clave pública, y sólo con esta. Para realizar esta operación, el navegador debe consultar de alguna forma el almacén de certificados del cliente, hacerle escoger el certificado con el que quiere firmar, y utilizar la clave privada almacenada en el certificado escogido para encriptar ese hash. Ya tenemos la firma: es el hash encriptado.
4. El navegador envía al servidor de firma todos los datos necesarios: el hash encriptado y la clave pública del certificado digital del cliente. Ahora éste lo almacena con el formato que se considere más oportuno. En cualquier momento se puede verificar la validez de esa firma con una sencilla operación: desencriptando la firma con la clave pública del certificado, y comparándola con el resultado de realizar el hash Almacenar el documento original con su firma (el hash encriptado). De esta forma, si algún día se quiere comprobar que lo que introdujo el usuario (el documento original) no ha sido modificado maliciosamente (lo que le confiere validez legal), se puede realizar una sencilla operación de comprobación de firma, consistente en desencriptar la firma con la clave pública del certificado digital, obteniendo el hash, y aplicando el algoritmo de hash sobre el documento original. Si ambos hash coinciden, la firma es válida.

El problema es que los pasos 2 y 3 deben realizarse en cliente, es decir, en el navegador. Esto se totalmente necesario y obligatorio; precisamente, uno de los puntos clave para mantener la seguridad del proceso se basa en que la clave privada del certificado del cliente nunca sale de la máquina del cliente. Hay un número finito de tecnologías para ejecutar esto en un navegador web: lo más normal son applets Java (como el conocido OpenOCES, que utilizamos en Viafirma y que usan otras plataformas como la de Safelayer) o clientes Active X, invocados desde Javascript. De hecho, éste es uno de los puntos claves para que un trámite telemático sea lo más universal y usable posible: la calidad del componente cliente. Por ejemplo, la semana pasada tardé dos horas, experimentos en 3 máquinas diferentes (ya varios navegadores en cada una, aunque con Opera o Safari no llegas muy lejos) y un buen número de reinstalaciones de componentes para conseguir cambiar a mi mujer de médico de cabecera, debido a la infame calidad de los applets Java de firma de la plataforma @Firma. Si a mí me costó tanto, no quiero imaginar qué le ocurrirá a un usuario de a pie. El mayor problema es que funciona muy mal con el JRE Java 6, pero debería tenerse en cuenta que, salvo que se configure de forma diferente, el JRE se autoactualiza automáticamente, con lo que a estas alturas hasta el panadero de la esquina tiene instalado Java 6 en su máquina.

Sobre la accesibilidad web 

En lo que se refiere a la accesibilidad web, las pautas WAI te exigen que para acceder a tu contenido web no sea imprescindible el uso de applets o javascript. En concreto, la pauta 6.3 dice que “Asegúrese de que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible”.

Según esta pauta entendemos que no podemos tener una calificación AA de accesibilidad si utilizamos javascript y applets, ya que deberíamos tener una página alternativa. El problema es que no podemos tener una página alternativa ya que la operación que realizamos no se puede realizar de otra forma de forma legal.

Sobre las Administraciones Públicas 

Por último, las Administraciones Públicas exigen por regla general que sus portales web, incluyendo sus oficinas virtuales, alcancen un nivel AA de accesibilidad, esto es, cumplan todos los puntos de verificación de prioridad 1 y 2.

Pero también exigen que para que una operación telemática sea legal, se haga utilizando firma electrónica que, como hemos visto, tiene problemas insalvables de accesibilidad porque hoy por hoy no es posible firmar sin ejecutar lógica de cliente que no todos los navegadores o dispositivos de usuario tienen por qué soportar. Por ello, la alternativa legal que podemos dar a nuestra web con firma electrónica es que el usuario se vaya a la institución físicamente.

¿No es un contrasentido? Se piden dos cosas incompatibles entre sí.

Una conclusión: quedarse en medio.

Bajo mi punto de vista, no debemos olvidar que las pautas WAI se refieren al acceso al contenido. Una Oficina Virtual está mucho más cerca de una aplicación web que de un portal, por lo que debe plantearse si las pautas aplican con la misma restrictividad. En todo caso, siempre se puede tratar de que toda la web sea accesible realmente, y sacar la zona dotada de firma electrónica de la declaración de accesibilidad. Y esperar a que la tecnología avance para superar estos escollos.

O al menos yo. Si no, probablemente no me habría estado un buen rato riéndome al ver estos super recortes de código:

usuario.setUsuario(usuario.getUsuario());

if(!usuario.getClaveusuario().equals(usuario.getClaveusuario())) {
addErrorGlobal("ERROR_PASSWORD");
}


Leo con algo de sorpresa la siguiente noticia, que viene a decir que Telefónica ha tenido una ¿novedosa? idea, montando una empresa que sirva de tercero de confianza en transacciones electrónicas. Concretamente, citando al diario El País, Telefónica sabe del hueco de negocio en las transacciones electrónicas basadas en tecnologías de firma digital, por lo que “ha decidido crear una división denominada Mediador de Confianza, que permitirá validar los certificados electrónicos, autentificar las transacciones electrónicas, tanto por Internet como por móvil, y llevar un servicio de custodia de los documentos electrónicos”.

Esto desde luego no es ninguna sorpresa. Siguiendo un modelo tal vez inspirado en Tractis, Telefónica aprovecha su innegable renombre para erigirse en tercero de confianza en transmisiones electrónicas seguras. Supongo que habrán optado por un modelo de negocio de abstraer la lógica a las empresas (hay que tener en cuenta el fuerte posicionamiento de Telefónica en el mercado de PYMEs), proveyéndoles de soluciones sencillas que solucionen problemas complejos como estos.

Sin embargo, lo que me sorprende sobremanera es lo siguiente; vuelvo a citar al diario “El País”: “La operadora lleva trabajando más de un año en el proyecto, con una inversión de más de 400 millones de euros…”.

¿400 millones de euros? Repaso un poco proyectos por orden de coste decreciente, la importante cantidad que costó CERES, lo que le ha costado a la Junta de Andalucía la creación de @Firma, lo que nos ha costado hacer Viafirma (tener a un crack como Félix ayuda, claro)… pero, ¿400 millones de euros?

Divagando un poco, supongo que habrán comprado 100 o 200 servidores Windows, 300 Linux y 400 Sun (hay probar Solaris, Aix o HP UX, para ver si van bien), y estarán comparando. Supongo que hay dos o tres nuevos turistas espaciales. También supongo que estarán programando en ensamblador, que siempre es más seguro, y a ser posible de espaldas y a la luz de las velas en noches de luna llena. Los algoritmos de encriptación existentes no les valdrán, estarán creando los suyos propios basándose en la lectura de las vías tomistas. No estarán programando con las manos, que cada cual se imagine otra parte del cuerpo con la que se pueda realizar pulsaciones de teclado (bueno, tal vez estén programando a boli e intentando escanearlo con un OCR).

Corcho, pero todavía me sobran euros para darme la vuelta al mundo :-)

En todo caso, divagando, he llegado a la conclusión. Telefónica, para el siguiente presupuesto, nosotros te lo hacemos por la mitad de lo que te digan ;-)

Pocos de nuestros lectores sabrán que dentro de VIAVANSI tenemos a un blogger ex-semi-profesional… Juan G. Hurtado, aka Armonia.

Juan tenía Armonia, un blog muy técnico muy dedicado a la Web y sobre todo a la capa de cliente (estándares), con una cantidad terrible de visitas. Le hizo bastante conocido en la blogosfera 2.0 hispana, le hacían entrevistas, salía en revistas internacionales… Su blog fue su CV y su reclamo para entrar en VIAVANSI. Ahora es el señor Semántico, nuestro crack de capa de cliente y uno de los secretos de que a nuestros clientes les guste la interfaz de nuestras aplicaciones. Sin embargo, por desgracia, un buen día se hartó y dejó de escribir.

Por eso, como opinan otros muchos internautas, señor armonía: ¡vuelva a escribir! *

*Y si escribes en xnoccio, pues mejor :-)