Archivos de la Categoria ‘Uncategorized’

GWT con REST

Junio 15th, 2010

Con este ejemplo, se muestra una forma de usar la nueva clase CellTable, que viene en GWT 2.1 para crear una interfaz de usuario sobre los servicios REST que se explicaron en este post.
Para ver como queda la cosa sin tener que instalar nada, se puede acceder a los servicios REST a través de aquí, y a la interfaz de usuario a través de aquí.

Si se utiliza Firefox existe un Addon, JSONView, que hace más amigable el trato con información en formato JSON.

Para ver el ejemplo en local habría que ejecutar desde el directorio raíz del archivo descomprimido:
grails run-app
Y acceder a través de:
http://localhost:8080/GrailsRestExample/gwt/index

Si se desea generar el archivo war para proceder a su instalación en un contenedor J2EE, habría que ejecutar desde el directorio raíz del archivo descomprimido el comando:
grails war
Y proceder a su instalación como cualquier aplicación web Java. Las aplicaciones Grails son aplicaciones web Java.

REST con Grails

Junio 12th, 2010

Para ejecutar el ejemplo hay que tener instalado Grails 1.3.1, descargarse el ejemplo , descomprimir el archivo y ejecutar en el directorio raíz del mismo:
grails run-app

No lo he complicado mucho para que el que quiera arrancar con Grails y REST se lie lo menos posible.
La aplicación consta de tres recursos, Usuario, Voto y Asunto. Se puede probar usando el programa rest-client o el Addon de Firefox ‘Poster’.

Recurso ‘Usuario’

  • Si se quieren consultar los usuarios se debe hacer una petición

GET http://localhost:8080/GrailsRestExample/users?max=20&offset=2

Donde max es el número máximo de resultados devueltos (por defecto 20) y offset es el índice a partir del que se desea obtener el primer resultado (por defecto 0)

  • Para obtener la información de un usuario concreto:

GET http://localhost:8080/GrailsRestExample/users/${idUsuario}

  • Para borrar un usuario se debe hacer una petición:

DELETE http://localhost:8080/GrailsRestExample/users/${idUsuario}

  • Para actualizar un usuario existente habría que hacer una petición:

PUT http://localhost:8080/GrailsRestExample/users/${idUsuario}
Enviando una representación JSON del usuario que se desee crear con las siguientes características:
{"username":"username", "email":"email@gruposp2p.org", "dateOfBird":"01-02-2003","enabled":"true"}

  • Para crear un nuevo usuario habría que hacer una petición

POST http://localhost:8080/GrailsRestExample/users
Enviando una representación JSON del usuario que se desee crear con las siguientes características:
{"username":"username", "email":"email@gruposp2p.org", "dateOfBird":"01-02-2003","enabled":"true"}

Recurso ‘Asunto’

  • Si se quieren consultar los Asuntos dados de alta en el sistema se debe hacer una petición

GET http://localhost:8080/GrailsRestExample/subjects?max=20&offset=2
Donde max es el número máximo de resultados devueltos(por defecto 20) y offset es el índice a partir del que se desea obtener el primer resultado (por defecto 0)

  • Para obtener la información de un asunto concreto:

GET http://localhost:8080/GrailsRestExample/subjects/${idSubject}

  • Para actualizar un asunto existente habría que hacer una petición:

PUT http://localhost:8080/GrailsRestExample/subjects/${idSubject}
Enviando una representación JSON del asunto que se desee crear que tenga siguientes características:
{"content":"Contenido del asunto 40","name":"Nombre del asunto40"}

  • Para borrar un asunto:

DELETE http://localhost:8080/GrailsRestExample/subjects/${idSubject}

Recursos ‘Asuntos’ asociados a un determinado recurso ‘Usuario’

  • Para obtener todos los asuntos generados por un usuario concreto

GET http://localhost:8080/GrailsRestExample/users/${idUsuario}/subjects/

  • Para generar un nuevo asunto asociado al usuario ${idUsuario} habría que hacer una petición

POST http://localhost:8080/GrailsRestExample/users/${idUsuario}/subjects/
Enviando una representación JSON del asunto que se desee crear con las siguientes características:
{"content":"Contenido del asunto 40","name":"Nombre del asunto40"}

Recurso ‘Voto’

  • Si se quieren consultar todos los Votos dados de alta en el sistema se debería hacer una petición

GET http://localhost:8080/GrailsRestExample/votes?max=20&offset=2
Donde max es el número máximo de resultados devueltos (por defecto 20) y offset es el índice a partir del que se desea obtener el primer resultado (por defecto 0)

  • Si se quiere consultar un voto concreto

GET http://localhost:8080/GrailsRestExample/votes/${idVote}

  • Si se quiere modificar un voto habrá que hacer una petición

PUT  http://localhost:8080/GrailsRestExample/votes/${idVote}
Enviando una representación JSON del asunto que se desee crear que tenga siguientes características:
{"value":"valor del voto www"}

  • Para eliminar un voto:

DELETE http://localhost:8080/GrailsRestExample/votes/${idVote}

Votos asociados a un determinado usuario

  • Para obtener todos los votos generados por el usuario ${idUsuario}

GET http://localhost:8080/GrailsRestExample/users/${idUsuario}/votes/

  • Para generar un nuevo voto sobre el asunto ${idSubject} asociado al usuario ${idUsuario} habría que hacer una petición

POST http://localhost:8080/GrailsRestExample/users/${idUsuario}/subjects/${idSubject}
Con una representación JSON del voto que tuviera las siguientes características:
{"value":"valor del voto www"}

Votos asociados a un determinado asunto
GET http://localhost:8080/GrailsRestExample/subjects/{idSubject}/votes

Votos asociados a un determinado asunto y a un determinado usuario
GET http://localhost:8080/GrailsRestExample/users/${idUsuario}/subjects/{idSubject}/votes

En el siguiente artículo explicaré cómo usar las nueva clase TableCell que viene con GWT 2.1 utilizando los datos disponibles en estos servicios REST, la aplicación de acceso para Android la dejaré para el final de esta serie.

Es importante quedarse con los siguientes puntos:

  • Existen formas de securizar los recursos.
  • El desarrollo está hecho en Grails, pero utilizando principios REST pueden crearse servicios, independientes de lenguaje de programación y plataforma, accesibles a través de Internet.
  • Gracias a esta técnica se separa completamente la interfaz de usuario del servicio.
  • Si se desea que dos partes intercambien información a través de Internet la mejor forma de conseguirlo es empezando definiendo las interfaces REST de los recursos que se desean compartir.

Twitteando en caliente

Junio 10th, 2010

He escrito un Tweet que parece que no ha sentado bien a alguna gente. Lo explicaré un poco para que se entienda.
Comiendo he visto una noticia en la que se decía que había que tener mucho cuidado con la información que se daba porque con el simple número de NIF ya podían enmarronarte haciendo compras y cosas así. Como si no fuera fácil conseguir números de NIF. Evidentemente no daban nombres de nada ni concretaban, un FUD en toda regla.

El Tweet lo he soltado en caliente indignado y decía ‘Sobre temas de robo de identidad, vale que no lo sepa una persona normal, pero que un profesional no sepa lo que es OCSP señala el nivel’, algo que fuera de contexto se puede malinterpretar.

La cosa más explicada debería quedar mas o menos así, si se hacen trámites con firma electrónica las aplicaciones que hagan uso de esas firmas pueden comprobar en tiempo real si los certificados asociados son válidos. En caso de pérdida o robo la información se actualiza una vez se ha denunciado la pérdida. Alguien dedicado a la gestión de identidades electrónicas debe saber eso.

Cuidado con lo que instalas

Mayo 14th, 2010

Los programas informáticos no son como los libros ni como las películas, no son productos ‘pasivos’, son activos, y están instalados en los dispositivos que te acompañan, gestionan las empresas y están en nuestros dormitorios con cámaras incorporadas. Si no se tiene cuidado con lo que se instala, se pueden acabar ejecutando programas que hagan cosas que realmente no quieres que hagan, esa es sólo otra razón más por la que algunos defendemos el software libre.
Que una persona, voluntariamente, elija instalar programas que no sabe lo que llevan dentro es algo a lo que nadie puede objetar nada, lo malo, es que aunque no quieras, se den las circunstancias para que te veas en la obligación de tener instalado en tus dispositivos ‘cajas negras’, eso, en un escenario en el que cada vez tenemos mas dispositivos a nuestro alrededor, y si no se está poniendo el ‘cazo’, es una aberración que no se le debería de ocurrir ni al que asó la manteca.
Desde el punto de vista de ‘producto’ un programa informático se parece mucho mas a un yogur que a un libro, es algo sobre lo que se deberían hacer inspecciones de seguridad.

Por qué son importantes los micropagos

Abril 27th, 2010
Hay muchos escenario de este mundo donde se pasa verdaderas necesidades por falta de medios para resolver sus problemas y hay otros sitios en los que se tienen ganas de ayudar pero no se encuentran los canales por los que poder enfocar esa ayuda.
Mediante Internet se presenta una oportunidad como no ha existido hasta la fecha para poder encauzar esas voluntades.
Los principales problemas son:
  • La ausencia de una cultura de micropagos y depósitos que faciliten flujos monetarios transparentes.
  • La monitorización en tiempo real del destino de los medios. Que se sepa donde ha ido y donde esta yendo hasta el último céntimo para que no haya lugar a la mas ligera suspicacia. Con Internet es posible.
Eso sólo se puede conseguir con líderes hábiles y con programas informáticos, no son opciones excluyentes aunque mientras que los líderes ‘te quitan’ el poder para su uso, los programas te dan el poder a ti … en vista de los resultados obtenidos hasta la fecha he decidido apostar una temporada ‘full-time’ por los programas.
No digo que sea la piedra filosofal ni la solución a todos los problemas del planeta, pero se emplean esfuerzos en otro tipo de cosas que para mi son mucho menos importantes y entiendo que incluso puede que sean necesarias, no seré el que las juzgue. El desarrollo de este tipo de programas en principio es algo que no debería molestar a nadie.

Configuración de un cliente OpenID con Spring Security y Grails

Abril 26th, 2010
Para este artículo se ha utilizado la versión 1.3.0.RC2 de Grails, OpenId4Java y la versión 3.0.2 de Spring Security. Como entorno de desarrollo estoy usando SpringSource Tool Suite.
Aunque Grails dispone de una serie de plugins para las configuraciones de seguridad de las aplicaciones, quiero mantener durante un tiempo los vínculos con el mundo J2EE tradicional por si por lo que sea hay que ‘reenfocar’ de forma rápida algún proyecto. Por eso por lo pronto prefiero usar Spring Security a la manera tradicional Java. La integración de Grails con Java es tan buena que permite hacer este tipo de cosas sin problemas. Esta técnica la aprendí en este artículo:

    Para crear la aplicación ejecutar desde la consola de comandos:

> grails create-app ClienteOpenID
Se puede ejecutar la aplicación para ver que todo va bien:
> cd ClienteOpenID
> grails run-app

    Instalar la plantilla web.xml

> grails install-templates
Este comando crea el archivo src/templates/war/web.xml que se debe editar para añadir después del último filtro:
<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

Y

<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Instalar las librerías

Una vez descargadas las librerías arriba indicadas al comienzo del artículo copiar en el directorio lib del proyecto Grails:

  • spring-security-config-3.0.2.RELEASE.jar, spring-security-core-3.0.2.RELEASE.jar y spring-security-web-3.0.2.RELEASE.jar de Spring Security.
  • las librerías openid4java-full-0.9.5.jar, commons-httpclient-3.0.1.jar, xercesImpl-2.9.1.jar, y nekohtml-1.9.7.jar que se pueden encontrar en la distribución del archivo openid4java.

Configuración del filtro de seguridad

Existen dos formas de configurar el filtro. Bien declarando los beans en grails-app/conf/spring/resources.groovy o declarándolos en grails-app/conf/spring/resources.xml, si se hace editando resources.xml:
<beans xmlns:sec="http://www.springframework.org/schema/security"
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:context="http://www.springframework.org/schema/context"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
              http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd
              http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">

	<sec:http>
        <sec:intercept-url pattern="/secure/**" access="ROLE_BUYER"/>
        <sec:intercept-url pattern="/login*" filters="none"/>
        <sec:logout/>
        <sec:openid-login login-page="/login" authentication-failure-url="/login?login_error=true">
            <sec:attribute-exchange>
                <sec:openid-attribute name="email" type="http://schema.openid.net/contact/email" required="true" count="2"/>
                <sec:openid-attribute name="transaction" type="" />
            </sec:attribute-exchange>
        </sec:openid-login>
    </sec:http>

    <sec:authentication-manager>
	<sec:authentication-provider user-service-ref="springSecurityUserDetailsService"/>
    </sec:authentication-manager>

</beans>
Con Spring Security se puede especificar en el archivo de configuración el tipo de información que se va a intercambiar con el proveedor del servicio OpenID. Si el proveedor ofrece esos servicios responderá con la información oportuna. En este caso intercambiaremos el correo del usuario que se quiera identificar, y un campo transaction en el que irá la información del micropago .
En el archivo se puede ver que para autentificar se utiliza el bean springSecurityUserDetailsService, este bean es un servicio que implementa la interfaz UserDetailsService que devuelve al autentificador una instancia de UserDetails. La instancia de UserDetails es una clase de dominio, la clase User, que implementa dicha interfaz.
Para generar mediante Scaffolding una aplicación para la gestión de una determinada clase de dominio, en este caso User:
>grails generate-all User
Y decir a todo que si.
Para probar la aplicación se vuelve a ejecutar:
>grails run-app
Y se introduce en la base de datos un usuario que tenga como propiedad Username el valor del identificador OpenID que quieras probar en la aplicación y como authority ROLE_USER. Para ello acceder mediante el navegador a http://localhost:8080/ClienteOpenID/ pulsar sobre UserController, e introducir un usuario.
El proyecto completo con todas las librerías se puede descargar desde aquí.
Para importarlo desde SpringSource Tool Suite:
File > Import > Existing projects into Workspace
Del código se deduce que vengo del mundo Java :-) . Hay varias cosas que con Groovy quedarían mucho mas elegantes, pero no hace falta saber utilizar Grails al 100% para poder ir sacándole poco a poco todas las ventajas que ofrece, de momento me siento más seguro sin dejar del todo el mundillo J2EE.
En próximos artículos explicaré como implementar el servidor OpenID que, en este caso, servirá para hacer transacciones utilizando como mecanismo de identificación el DNI electrónico.

Usuarios como observadores o como protagonistas

Marzo 29th, 2010
Aplicaciones en las que el usuario es un observador: aquellas en las que el usuario simplemente se dedica a observar/comentar una información.
Aplicaciones en las que el usuario es protagonista: aquellas en las que la interactuación con la aplicación tiene un impacto claro sobre algún asunto concreto.
Uno de los retos del momento consiste en crear aplicaciones que hagan al usuario protagonista directo, sin delegaciones, de cada vez más procesos de toma de decisión … seguro que así se acaba para siempre con las crisis.

OAuth y Administraciones Públicas

Marzo 23rd, 2010
Oauth es un estándard abierto para el control de la privacidad de los datos. Si un usuario tiene información personal almacenada en un determinado sitio web , OAuth proporciona un mecanismo para que pueda  autorizar a ese sitio web a compartir datos con otro sitio web. También hace posible ese intercambio de información sin que sea necesario que el sitio que usa los datos sepa nada de la identidad del usuario. Resuelve el problema de la forma más elegante posible, compartiendo los datos sólo si el usuario da su permiso.
¿Cómo podrían aprovecharse los usuarios de las Administraciones Públicas de OAuth?
Por ejemplo, si la Agencia Tributaria necesitase para la tramitación de un determinado servicio online de información gestionada por la Seguridad Social el problema se podría solucionar recreando este escenario:
• Poniendo la seguridad social los servicios de información requeridos en red protegidos con OAuth (la identificación del usuario para su aprobación se podría hacer con el DNI electrónico)
• Creando la Agencia Tributaria el servicio online que al necesitar los datos de la seguridad Social redireccionase al usuario para que este diera su aprobación.
OAuth también podría usarse como pasarela de pagos para automatizar y estandarizar el pago de tasas.
Esto sería un paso más a la oficina sin papel y al ahorro en muchos conceptos.

Revueltas sociales

Marzo 17th, 2010
Acabo de leer una noticia en la que se comenta:
‘El director del Fondo Monetario Internacional, Dominique Strauss-Kahn, ha advertido hoy de que “el público está impaciente” ante las anunciadas reformas en el sistema financiero pero que no acaban de llegar. Durante una intervención ante la Eurocámara en Bruselas, el banquero francés ha afirmado que si los cambios se siguen retrasando, la expectación podría desembocar en “revueltas sociales”, por lo que ha animado en seguir adelante con las negociaciones en pos de un mayor control y supervisión que eviten que una recesión como la actual pueda repetirse.’
Tal y como está escrita la noticia parece que en esas reuniones sólo hay algo en lo que todos están de acuerdo, y es que deben crearse herramientas que proporcionen un mayor control y supervisión, el problema se da cuando deben decidir cómo se consigue eso, ¿cada uno suelta su discurso van pasando los días y no se consigue nada?
Los tiempos de los mensajeros a caballo intercambiando manuscritos entre bancos nacionales han pasado, la única forma de conseguir esas herramientas es creando sistemas informáticos abiertos que monitorizen los intercambios monetarios. El objetivo se conseguirá cuando se tengan esos sistemas, las reuniones deberían ser para la toma de requisitos y el seguimiento de avances. Habrá gente que diga, la cosa va más allá de un programa … ok, de acuerdo, pero mientras no se tenga el programa no se pondrá nada en marcha ni habrá ningún cambio.
No me puedo creer que no existan ya esos sistemas.

Micropagos III – Flujo de operaciones que se producen en una transacción

Marzo 3rd, 2010

Introducción

OAuth es un protocolo abierto que busca estandarizar la forma en la que las aplicaciones acceden a datos privados albergados en servicios remotos. Este documento explica como se puede utilizar OAuth para realizar transferencias de dinero a través Internet.

El documento se puede descargar desde aquí.

Flujo de operaciones

En el flujograma de ejemplo participan:

  • El banco, prestador del servicio.
  • La entidad/persona beneficiaria de las transacciones, consumidora del servicio.
  • El usuario que dispone de una cuenta en el banco prestador del servicio y autoriza al consumidor del servicio a realizar un cargo.

Premisas:

  • Para que una entidad/persona pueda ser consumidora de servicio debe primero abrirse una cuenta con los bancos prestadores del servicio con los que quiera colaborar.
  • El usuario debe disponer de una cuenta en alguno de los bancos que el consumidor del servicio le ofrezca.

El usuario está navegando en el portal de un consumidor de servicio y decide hacer click en alguno de los enlaces que facilitan un micropago. El consumidor del servicio le ofrece los canales de los que dispone para poder recibir el micropago:

Para que el consumidor de servicio pueda utilizar el Banco de Internet debe disponer de una cuenta en el mismo. Durante el procedimiento de alta de cuenta se le ha proporcionado una clave de consumidor y un secreto de consumidor con los que podrá iniciar los intercambios de información con el banco.

Después de que el usuario haya seleccionado un banco empieza el intercambio de información. El consumidor de servicio solicita del banco un token de petición, en este punto de la conversación ese token todavía no tiene nada que ver con el usuario.

Cuando el consumidor de servicio recibe el token de petición envía al usuario con el mismo a la página del banco en la que se debe autorizar la transacción indicándole la URL a la que tiene que devolver al usuario una vez haya terminado la operación.

Una vez en la página del banco OAuth requiere que los proveedores de servicio autentifiquen a los usuarios antes de preguntarles si garantizan la operación.

OAuth hace posible las transacciones sin que los consumidores del servicio tengan que manejar información sensible (ni la contraseña ni el número de tarjeta).

Después de haberse identificado correctamente. El banco informa al usuario del beneficiario y la cantidad de dinero de la transacción que debe autorizar. Se puede usar el mismo mecanismo para autorizar pagos periódicos.

Una vez autorizada la operación por el usuario, el token pasa a estado autorizado en el proveedor de servicio y se redirecciona al usuario a la página del consumidor del servicio que inició la conversación.


Mientras el usuario espera el consumidor de servicio intercambia con el proveedor del servicio (el banco) el token de petición autorizado por un token de acceso.

En terminología OAuth los tokens de petición son sólo válidos para obtener el consentimiento del usuario mientras que los tokens de acceso se utilizan para acceder a recursos protegidos. En el caso que trata este documento el token de acceso tiene el siguiente uso:

  • La primera vez que se acceder con un token de acceso se finaliza la transacción autorizada por el usuario.
  • La segunda y sucesivas veces que se utilize el token de acceso el banco devolverá un recibo.

Referencias:

Guía para principiantes del protocolo OAuth