HAL 9K

Video donde revisamos algunos conceptos y modo de funcionamiento de OAUTH 2.0.

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!!! ;)

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 l as 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.

Y luego de un largo rato volvemos por acá con una historia basada en hechos reales, sobre una conversación muy didáctica que tuve con un amigo: -Mr. Bladi, he escuchado que Ud. se opone, es más desprecia, al uso de las clases Utilitarias y los métodos estáticos en la programación orientada a objetos (OOP). -Ciertamente. No aconsejo su uso y lo considero una mala práctica, algo ofensivo en la OOP. -Pero si no podemos usar clases utilitarias y métodos estáticos, ¿Cuáles opciones Tenemos? -Tenemos unas cuantas opciones. Pero antes un poco de contexto. Las clases utilitarias, esas que están repletas de métodos estáticos, no son objetos reales, son un recurso totalmente procedimental y rompen el principio de encapsulamiento en la OOP. Peor aún, las clases utilitarias con su torrente de métodos estáticos, son muy difíciles de testear en las pruebas automáticas.  TODO MÉTODO ESTÁTICO, E INCLUSO LOS PRIVADOS, SON CANDIDATOS PARA UNA NUEVA CLASE, es decir son elegibles ...