A pesar de que sigue usándose ampliamente el usuario ya la contraseña (y su ‘glorificación’, el certificado digital), lo cierto es que hay formas más intersantes de dar acceso a recursos. En An Illustrated Guide to OAuth and OpenID Connect hablan de estos mecanismos que permiten dar acceso a recursos sin tener que difundir o utilizar todo el rato el usuario y la contraseña. El usuario atento habrá visto cómo necesita, a veces, autorizar el uso de un recurso (en Google, Twitter, Facebook y otras redes sociales) que es justamente eso: OAuth nos permite identificarnos ante un servicio para dar permiso a otro (o a una aplicación que se conecta al mismo) con el objetivo de poder realizar determinadas acciones). Por eso nos avisan de cosas como que la aplicación podrá leer, modificar o lo que sea que va a hacer. Además de liberarnos de tener que poner nuestra clave y contraseña en esos sitios y aplicaciones (las ponemos directamente en el servicio en cuestión), nos permite una gestión más eficaz:

• Si cambiamos la contraseña no será necesario (al menos no siempre) reintroducirla en todas las aplicaiones.
• Si queremos revisar/modificar o cancelar quién puede acceder a nuestra información lo podremos hacer en el sitio del servicio y no en el del que hace uso de ello.

En esa entrada se hace una muestra gráfica de cómo funciona el mecanismo y me pareció interesante para compartirla aquí.

OAuth está diseñado para la autorización, esto es, dar acceso a datos y características. En algunos casos puede ser necesario, además, proporcionar información sobre el usuario (identidad). En esto entra en juego OpenID, donde se puede compartir esta información. Y también hay una demostración gráfica de las capacidades y el funcionamiento.

Interesante.

2020-04-14: Actualización. El enlace estaba mal, corregido.

Otro artículo sobre el funcionamiento de herramientas que utilizamos. En How Unix Works: Become a Better Software Engineer un resumen sobre el funcionamiento del sistema operativo Unix.

Empieza con la filosofía:

• Escribir programas que hacen una cosa y la hacen bien.
• Escribir programas que trabajan bien juntos (sin salida extra, sin interactividad).
• Escribir programas para manejar flujos de texto, que es un interfaz universal.

Let’s start at the core - the philosophy behind Unix.

Write programs that do one thing and do it well. Write programs to work together. (no extra output, don’t insist on interactive input) Write programs to handle text streams, because that is a universal interface.

Luego habla de procesos, ficheros, el sistema de ficheros y un buen resumen del sistema en general.

Un artículo sobre las interioridades de git Git from the inside out.

Describe fundamentalmente la estructura de grafo que subyace la conocida herramienta Git y las consecuencias que esto tienen en como funciona.

The essay focuses on the graph structure that underpins Git and the way the properties of this graph dictate Git’s behavior.

Para ello se basa en el funcionamiento de distintas instrucciones, y se apoya en ello para comentar estas interioridades.

The text is structured as a series of Git commands run on a single project. At intervals, there are observations about the graph data structure that Git is built on. These observations illustrate a property of the graph and the behavior that this property produces.

Para conservar.

El día que consiga que vuelvan a funcionar las categorías y las etiquetas se podrá ver cómo hemos hablado bastantes veces de aleatoriedad. Traemos hoy aquí Random Numbers From Outer Space donde hablan del tema desde otra perspectiva.

Siempre decimos lo importantes que son los números aleatorios en seguridad y en este caso hablan de usar la radiación de fondo. Se usa un detector de muones, que son partículas subatómicas más pesadas.

Muons are subatomic particles that are like electrons, but much heavier, and are created when pions enter the atmosphere and undergo radioactive decay. The Geiger-Müller tube, mainstay of Geiger counters the world over, detects these incoming muons and uses them to generate the number.

Curioso.

La promesa de la nube (ajena) es ahorro en costes (no tener que adquirir, instalar, ni mantener infraestructura). No obstante, eso no significa que no haya costes que haya que vigilar y tratar de mejorar. De eso nos habla Three ways to reduce the costs of your HTTP(S) API on AWS.

Empiezan hablando de sus medidas: reciben, almacenan y procesan eventos relacionados con juegos de 1200 millones de jugadores en cerca de 90,000 juegos.

Here at GameAnalytics, we receive, store and process game events from 1.2 billion monthly players in nearly 90,000 games.

Esto se traduce en alrededor de cinco mil millones de peticiones diarias, cada una de ellas con dos o tres eventos de unos pocos kilobytes.

We get approximately five billion requests per day, each typically containing two or three events for a total of a few kilobytes.

Y eso tiene un coste, claro:

So what would you guess is the greatest cost associated with running this system on AWS, with a fleet of EC2 instances behind a load balancer?

La mayoría, datos que van hacia afuera:

We wouldn’t have guessed that the greatest part of the cost is for data transfer out. Data transfer in from the Internet is free, while data transfer to the Internet is charged between 5 and 9 cents per gigabyte.

Los trucos son sencillos, en algunos casos:

• Reducir las cabeceras HTTP, para bajar de 333 bytes a 109

Sending 109 bytes instead of 333 means saving $56 per day, or a bit over $1,500 per month.

• Reducir la negociación del TLS, basado en la recuperación de sesiones TLS.

That leaves reducing the number of handshakes required by reducing the number of connections that the clients need to establish. […] This reduced data transfer costs by an additional 8%.

• Verificar los certificados, que típicamente también son demasiado grandes. Sobre todo si hay una cadena de confianza para establecer la validez del nuestro.

So given that the clients establish approximately two billion connections per day, we’d expect to save four terabytes of outgoing data every day. The actual savings were closer to three terabytes, but this still reduced data transfer costs for a typical day by almost $200.

Una lectura interesante.