Java 1.4, los certificados, y la p…

Ayer estuve una hora tratando de que la herramienta keytool de java 1.4 importe un certificado. Sí, ya sé que esa versión es obsoleta, pero en este caso no hay otra opción. El tema es que luego de miles de pruebas no había forma de que reconociera el certificado como X.509 (aunque realmente fuera así).

Pues bien, importé el certificado en Java 1.5 y ningún drama, entonces armé un nuevo certificado de prueba con una clave de menor longitud y… bingo! la versión 1.4.2 no acepta longitudes de clave mayores a 2048, como era de esperarse debido a restricciones de exportación.

Pero yo quiero mi certificado con clave de 4096 bits! Googleando un poco encontré un hermoso documento donde unos buenos muchachos rusos explican cómo habilitar la utilización de claves de mayor longitud.

Para ello:

  1. Suponiendo que el JRE se encuentra en /usr/lib/j2se/1.4/jre/
  2. Descargar e instalar el jar de BouncyCastle CryptoProvider en $JRE/lib/ext
  3. Descargar e instalar los archivos de la Unlimited Strength Jurisdiction Policy 1.4.2 en $JRE/lib/security
  4. Modificar el archivo $JRE/lib/security/java.securityestableciendo los proveedores de seguridad como sigue:
    security.provider.1=sun.security.provider.Sun
    security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
    security.provider.3=com.sun.net.ssl.internal.ssl.Provider
    security.provider.4=com.sun.rsajca.Provider
    security.provider.5=com.sun.crypto.provider.SunJCE
    security.provider.6=sun.security.jgss.SunProvider

    El de BouncyCastle debe ser el segundo.

Y con eso debería alcanzar para poder utilizar certificados con clave de 4096 bits. O eso espero…
Bueno los dejo por ahora así como algo. Saludos!

PHPTAL: un lenguaje de plantillas para PHP basado en ZPT

Estos días estuve trabajando bastante en Python, Zope y Plone, un conjunto de tecnologías que me parecen atractivas y muy versátiles, y en el transcurso del aprendizaje natural encontré las Zope Page Templates (ZPT), que es un lenguaje para creación de plantillas diferente a los normales, pues en vez de crear tags HTML nuevas, añade atributos a las etiquetas existentes.

Según el Zope Book, “el objetivo de las Page Templates es permitir a los diseñadores y programadores trabajar en conjunto fácilmente. Un diseñador puede utilizar un editor HTML visual (el clásico WYSIWYG como Dreamweaver, NVU o Front*cofff*Page) para crear una plantilla, que luego el programador puede editar para hacerla parte de una aplicación. Si es necesario, el diseñador puede volver a cargar la plantilla en su editor visual y hacer cambios en la estructura y apariencia. Tomando ciertos recaudos, el trabajo de edición se puede realizar sin dificultades y no interfiere con la aplicación.

“Las Page Templates apuntan a lograr este objetivo adoptando tres principios:

  1. Permitir la creación y modificación de las páginas con herramientas visuales.
  2. Lo que ve es muy similar a lo que obtiene (WYSIVSTWYG).
  3. Mantiene el código fuera de las plantillas, salvo la lógica estructural.

Una Page Template es como un modelo de la página que generará. En particular *es HTML válido* (e incluso *XHTML válido*!)

Redondeando, quiere decir que nuestro editor visual no hará desastres con la plantilla, como suele ocurrir con otros lenguajes de plantillas, ya que no hay etiquetas extrañas sino atributos en nuevos las etiquetas actuales (y sólo dos namespaces opcionales).

Como me pareció muy cómodo me puse a buscar si en PHP había algo similar, y efectivamente unos buenos muchachos han portado esta idea creando el PHP Template Attribute Language (PHPTAL) que es una implementación de ZPT para PHP . En resúmen, es una librería de generación de plantillas XML/XHTML para PHP.

PHPTAL actualmente va por la versión 1.1.8 y se distribuye como standalone o empaquetado para PEAR. En la introducción hay un ejemplo muy ilustrativo de como funciona la herramienta.

Algunas ventajas:

  • impone mayor separación entre lógica y presentación,
  • advierte si se olvidó de cerrar alguna etiqueta HTML o si la página está malformada,
  • ya no es necesario utilizar htmlentities,
  • las plantillas quedan limpias y legibles,
  • permite insertar texto de ejemplo para previsualizar la plantilla sin necesidad de ejecutarla con PHP,
  • se integra bastante bien con editores visuales,
  • permite la abstracción de datos con un sistema similar a xpath.

Algunas desventajas:

  • es una dependencia de la aplicación,
  • hay que aprenderse los atributos,
  • hay que producir XHTML límpio (aunque esto no sería una desventaja).

Para mayor información les dejo el enlace a la guía de referencia de PHPTAL.

Un sencillo método para el desarrollo de sistemas web

Trevor Turton publicó recientemente en su blog un artículo titulado Use Cases on Steroids en el cual discurre sobre un posible método para encarar el desarrollo de software y no salir herido en el intento. Me tomo el atrevimiento de traducir informalmente una parte del texto de su autoría que resume el procedimiento:

  • Durante la fase de elicitación de requerimientos, los desarrolladores trabajan junto al cliente (como organización) para identificar los elementos debajo enumerados. Los desarrolladores representarán estos elementos en una herramienta de modelado acordada y consultarán al cliente para verificar que esto se ha realizado con precisión (esta parte del modelo es simple de controlar por no-especialistas) :
    • Los actores que juegan un rol en el sistema.
    • Una lista jerárquica de las acciones principales que estos actores ejecutarán.
    • Modelos de cada panel requerido para soportar las acciones identificadas; en HTML, si fuera un sistema basado en el navegador.
    • Casos de uso que describen en palabras las diversas acciones identificadas; en HTML si es un sistema basado en web, con enlaces a los paneles modelo.
    • Un modelo de datos que contiene todos los elementos de datos identificados en las acciones y paneles.
  • Durante la fase de diseño:
    • Los usuarios pueden manejarse a través de los casos de uso, viendo los paneles modelo en cada paso del proceso, pudiendo validarlos o corregirlos.
    • Los desarrolladores refinan el modelo de datos según las formas normales, produciendo un diseño de base de datos.
    • Los diseñadores incorporan al modelo las clases, atributos y métodos que serán necesarios para implementar el sistema.
  • Durante la fase de programación:
    • Los desarrolladores engrosan el modelo con el código requerido para implementar el sistema.
    • Los desarrolladores crean la base de datos y las clases requeridas para administrar los datos en ellas.
    • Puede añadirse lógica estándar sencilla a los paneles para propagar los datos ingresadas por los usuarios a los paneles subsecuentes.
    • Otros miembros del equipo de desarrollo refinan el estilo visual de los paneles modelos a fin de que los usuarios los sientan adecuados.
    • Se toman capturas de los paneles clave, que serán firmadas por los propietarios del sistema quienes acordarán que es el estilo visual que requieren.
    • El equipo de desarrollo debe asegurarse que el estilo acordado sea aplicado uniformemente a todos los paneles, preferentemente mediante hojas de estilo.
    • Los propietarios del sistema prueban y firman (o critican) los paneles modificados para asegurar que poseen la funcionalidad y apariencia requerida.
  • Durante la fase de prueba:
    • A medida que se implementan las distintas partes del sistema, se incorpora a los paneles modelo correspondientes la lógica embebida, según sea necesario.
    • Los casos de uso se convierten ahora en scripts de prueba. Los usuarios los utilizarán como guía para evaluar metódicamente el sistema, sólo que ahora la navegación entre paneles se realizará a través de lógica del software en el sistema de prueba, en vez de hacer clics en los enlaces en el caso de uso (aunque los enlaces de los casos de uso pueden utilizarse para navegar los paneles de software apropiados donde ésto tenga sentido, p.ej. donde no se requiere entrada desde un panel anterior).
    • La navegación entre secciones del sistema que no han sido desarrolladas aún puede realizarse a través de los casos de uso, de forma que los usuarios pueden evaluar los componentes en un contexto plausible, en vez ser en forma aislada.
    • Podría implementarse a través de hojas de estilo un esquema de colores convenido para distinguir los paneles en funcionamiento de los paneles en desarrollo.

En realidad no es nada nuevo, muchos de nosotros hemos optado por una metodología similar al desarrollar un sistema web. Lo bueno es que el muchacho se tomó el tiempo de documentarlo y darnos unos muy buenos consejos. So… Thank you very much, Trevor!

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress