HAL 9K

Siguiendo con la onda de seguridad, autenticación y autorización, hoy vamos a hablar de uno de los elementos que ya hemos mencionado como parte de estos mecanismos, los ya famosos Json Web Token o JWT, el cual es un String que cumple con el estándar RFC 7519 para transmitir información con la identidad y claims de un usuario de forma segura entre un cliente/servidor. Dicha información puede ser verificada y confiable porque está firmada digitalmente.

En nuestro capítulo anterior  vimos cómo implementar Proof Of Key en el lado del servidor usando OAUTH 2.0 con SpringBoot. Hoy corresponde enfocarnos en ese concepto del lado del cliente. En esta oportunidad vamos a desarrollar una aplicación que interactúe con el servidor o proveedor de OAUTH tras demostrar que está en posesión de la clave privada relacionada con la clave pública que se nos provee en el JWT correspondiente.
Al igual que la anterior, esta publicación va a hacer uso de Java 8, Maven, Spring Web, Spring Security y Nimbus JOSE + JWT.

Hace rato que OAUTH 2.0 viene estando presente en el escenario de seguridad en IT. El post que hoy nos ocupa tiene como propósito mostrar un ejemplo funcional del esquema Prueba de posesión de clave, del ingles Proof Of Possession (POP) of key usando Spring Boot.
Este ejemplo usa como base el código presentado en el maravilloso libro, OAUTH 2.0 Cookbook, la diferencia es que este SI FUNCIONA!!! ;)

Ese era el "slogan" o frase motivacional de nuestra  gerencia de desarrollo en INSISTO.

Como podrán apreciar, mi gerencia tenía fama de ser áspera, directa, dura, elitista y dictatorial. No apta para pusilánimes. La gerencia "Hitler" le decían. De hecho, cuando alguien se quejaba de sus condiciones de trabajo o de sus tareas, era enviado a pasar unos meses bajo mi tutela en la gerencia de desarrollos, para que la víctima persona supiera cuan feliz y fácil era su vida y no lo sabía.

Eran tiempos mas honestos.

Es mucho el artículo, publicación y blogs de , ¿supuestos?, entendidos en el tema que hablan sobre, o exponen el problema con, el uso o más bien ABUSO de los Getters y Setters en la programación orientada a objetos (OOP).

Es este un tema recurrente y para nada nuevo, no señor, de hecho viene dando vueltas en el entorno de desarrollos OOP desde hace un buen rato. Pero....

¿Cuál es el gran problema con usar getters y setters?

No, este no es un artículo sobre política, sigue siendo sobre programación orientada a objectos (OOP), específicamente sobre métodos públicos y propiedades privadas, de allí el título.

Todo surge por un comentario que me hizo un querido amigo al leer mi publicación sobre las reglas pigbar de programación. El me comentó:

"Mr. Bladi, entiendo sus reglas acerca de que las propiedades deban ser privadas por aquello del encapsulamiento, ¿pero que todos los métodos deban ser públicos? eso me cuesta entenderlo, eso implica que no existen métodos privados, y yo debo saber lo que un objeto hace sin preocuparme del cómo, por lo que esos métodos privados pueden ser útiles."

Uno de los grandes errores de la programación orientada a objetos (OOP) con Java ha sido la existencia de las referencias a NULL.
Esta es la causa del popular y formidable error “java.lang.NullpointerException”. Toda una embrarrada.
La existencia de este tipo de referencia es la causa de muchos dolores de cabeza, de muchísimo código innecesario y defensivo, de muchas malas prácticas y de una pésima filosofía de desarrollo.