devcito blog

Creación del Blog y Nuevo Diseño Git Sketchbook

2026-05-24T00:00:00+00:00

¡Hola a todos! Este es el primer artículo oficial de devcito blog.

He creado este blog con un propósito muy claro: dar visibilidad a las cosas que hago y desarrollo en mis proyectos personales. Para mí, es un espacio donde documentar mis avances, registrar soluciones a problemas reales de programación y mostrar los experimentos y proyectos que voy construyendo en mi día a día.

El Diseño: Git Sketchbook

Para este espacio quería un diseño limpio, que facilitara la lectura de código pero que mantuviera la esencia de una consola o entorno de desarrollo. Este diseño incluye:

Margen de Números de Línea: Un script dinámico calcula la altura de la página y renderiza números de línea en el lateral izquierdo, emulando un editor de código.
Cabecera Git: Muestra la ruta del proyecto (devcito / blog) y la rama activa actual (main).
Fondo de Cuadrícula: Un patrón de cuadrícula de fondo que simula una libreta física de bocetos para desarrolladores.

¿Qué verás por aquí?

Principalmente compartiré el progreso y la arquitectura de mis proyectos personales, retos superados en CSS/JS, configuraciones de terminal y desarrollo de software práctico.

¡Gracias por pasar y seguir el progreso!

Cómo funciona el algoritmo de colores de Armonic Themes

2026-05-09T00:00:00+00:00

Una mirada técnica a cómo generar paletas que siempre se ven bien, en claro y en oscuro.

El problema de las paletas “aleatorias”

Generar colores al azar es fácil. Generar colores al azar que se vean bien juntos es otro asunto completamente diferente.

La mayoría de los generadores de temas eligen cada color de forma independiente: un rojo por aquí, un azul por allá, un verde que nadie pidió. El resultado suele ser una paleta caótica donde los colores pelean entre sí en lugar de complementarse.

Armonic Themes resuelve esto con un principio fundamentalmente distinto.

El principio fundamental: un solo hue lo gobierna todo

En lugar de elegir cada color de manera independiente, el algoritmo parte de un único Hue base (un ángulo en la rueda de color, entre 0° y 360°) y deriva todos los demás colores a partir de él usando relaciones matemáticas establecidas.

Hue base aleatorio (0–360°)
        │
        ▼
┌─────────────────────┐
│ Estrategia de       │  → define secondaryHue y accentHue
│ armonía (al azar)   │
└─────────────────────┘
        │
        ▼
Todos los colores de la paleta

Esto garantiza que, sin importar qué número salga, los colores siempre tendrán una relación armónica entre sí.

Las estrategias de armonía

El algoritmo incluye 9 estrategias de armonía, elegidas al azar en cada generación:

Análoga: Hues vecinos (±18°–55°) → Suave, elegante, “de diseñador”
Análoga amplia: Vecinos más lejanos (±55°–160°) → Sofisticada, con más tensión
Complementaria: Hue opuesto (+180°) → Alto contraste, energética
Triádica: 3 hues a 120° entre sí → Rica, colorida, balanceada
Split-complementaria: Vecinos del opuesto (+150° y +210°) → Contraste sin ser agresiva
Doble-split: Ambos lados del opuesto (±150°) → Vibrante y simétrica
Tetrádica: Cuadrado en la rueda (90° y 270°) → Máxima variedad de hues
Monocromática: Mismo hue con mínima variación (±12°–18°) → Elegancia pura, una sola familia
Caótica: Hues completamente libres → Máxima sorpresa, sin reglas

Por ejemplo, si el hue base es 220° (azul):

Análoga → secondary ≈ 195°, accent ≈ 245°
Complementaria → accent ≈ 40° (naranja)
Triádica → secondary ≈ 340° (magenta), accent ≈ 100° (verde)

Los Moods: la personalidad de cada paleta

La estrategia de armonía controla qué hues se usan. Pero el mood controla la saturación y luminosidad de cada color, que es lo que le da el “carácter” a la paleta.

El algoritmo define 17 moods, cada uno con rangos precisos de [min, max] para saturación (S) y luminosidad (L):

`- bold → primaryS: [52-82%], primaryL: [38-60%] — Firme, seguro

soft → primaryS: [28-58%], primaryL: [52-74%] — Suave, amable
vibrant → primaryS: [74-100%], primaryL: [44-64%] — Eléctrico, vivo
pastel → primaryS: [38-72%], primaryL: [68-87%] — Dulce, delicado
neon → primaryS: [88-100%], primaryL: [52-68%] — Extremo, digital
jewel → primaryS: [62-92%], primaryL: [22-42%] — Esmeralda, zafiro, rubí
mono → primaryS: [4-18%], primaryL: [18-52%] — Casi escala de grises
midnight → primaryS: [48-82%], primaryL: [48-72%] — Nocturno, intenso
corporate → primaryS: [22-52%], primaryL: [26-50%] — Profesional, sobrio
… y más`

La combinación de estrategia de armonía + mood produce miles de paletas visualmente coherentes sin intervención manual.

La micro-variación: el toque de aleatoriedad controlada

Para que dos paletas con el mismo mood y estrategia no sean idénticas, el algoritmo aplica un multiplicador global de saturación y luminosidad en cada generación:

const satTwist = rand(0.72, 1.32);  // Amplifica o reduce TODA la saturación
const litTwist = rand(0.92, 1.08);  // Pequeña variación de luminosidad global

Un satTwist de 1.32 hace que todos los colores sean un 32% más saturados que lo normal para ese mood. Uno de 0.72 los apaga. Esto produce una variedad enorme dentro de la misma “familia” de paletas.

Accesibilidad automática: WCAG sin esfuerzo

Uno de los detalles más cuidados del algoritmo es que nunca hay que definir manualmente el color del texto. Cada foreground se calcula automáticamente usando la fórmula de luminancia relativa de las directrices WCAG 2.1:

Luminancia relativa = 0.2126·R + 0.7152·G + 0.0722·B

Si la luminancia del fondo supera 0.179 (umbral perceptual donde el ojo empieza a ver el color como “claro”), el texto se vuelve oscuro. Si está por debajo, se vuelve claro. Ambas variantes tienen un tinte sutil del hue base o secundario para que no sean un gris muerto:

// Fondo claro → texto oscuro teñido
{ h: darkTintHue, s: rand(15, 45), l: rand(2, 12) }

// Fondo oscuro → texto claro teñido  
{ h: lightTintHue, s: rand(5, 25), l: rand(92, 98) }

El resultado es que todo texto generado cumple contraste legible de manera automática, y aun así los textos tienen personalidad cromática propia.

Cómo funciona el modo oscuro

Aquí está la magia. En lugar de “invertir” los colores o usar un overlay semitransparente (como hacen muchos frameworks), el algoritmo genera ambos modos desde el principio, compartiendo los mismos hues pero con lightness completamente diferente.

Lo que se comparte entre light y dark

El color primary, destructive y ring son idénticos en ambos modos. Son los colores de acción y tienen su propio contraste garantizado.

Lo que cambia entre light y dark

background → light L: 93–99% (casi blanco), dark L: 2–13% (casi negro)
muted → light L: 86–96% (blanco grisáceo), dark L: 11–26% (gris oscuro)
border → light L: 75–91% (gris claro), dark L: 23–45% (gris medio oscuro)
secondary → saturación mínima, L alta / saturación mínima, L baja
accent → saturación media, L alta / saturación media, L baja

Y aquí viene el detalle que hace que los modos oscuros tengan personalidad: los fondos oscuros no usan necesariamente el mismo hue que los fondos claros.

// Para el fondo oscuro, se elige un darkTintHue con más libertad:
const darkTintCandidates = [baseHue, secondaryHue, accentHue, rand(200, 260), rand(140, 180)];
const darkTintHue = Math.random() > 0.35
  ? darkTintCandidates[randInt(0, darkTintCandidates.length - 1)]
  : baseHue;

Esto significa que el fondo oscuro puede tener un tinte azul profundo aunque el color primario sea naranja. Es lo que evita que todos los modos oscuros sean “gris neutro con colores encima”.

El flujo completo en 12 pasos

`1. Elegir HUE BASE (0–360°)

Elegir ESTRATEGIA DE ARMONÍA → calcular secondaryHue y accentHue 2.5 Elegir MOOD → rangos S/L para cada token
Aplicar micro-variación (satTwist, litTwist)
Generar PRIMARY (hue base + rangos del mood)
Generar SECONDARY en versión base / light / dark
Generar ACCENT en versión light / dark
Generar DESTRUCTIVE (siempre en zona de rojos, 330–30°)
Elegir darkTintHue y lightTintHue para los fondos
Generar BACKGROUND light (L: 93–99%) y dark (L: 2–13%)
Generar MUTED light y dark
Generar BORDER light y dark
Calcular todos los FOREGROUNDS por luminancia WCAG automática`

Nombrar cada paleta

Para que cada tema sea memorable, el algoritmo genera nombres combinando dos listas de palabras:

[Arctic, Velvet, Neon, Cosmic, Ember, Frosted...] + [Dawn, Wave, Pulse, Storm, Bloom...]

→ “Arctic Dawn”, “Velvet Pulse”, “Cosmic Storm”

Son 70+ adjetivos × 70+ sustantivos = más de 4,900 combinaciones posibles, todas con ese sabor evocador de los nombres de temas de código.

En resumen

Lo que hace especial a este algoritmo es que la aleatoriedad está estructurada. Nada se elige de forma verdaderamente libre: el azar actúa dentro de rangos matemáticamente definidos, siguiendo relaciones de color probadas durante décadas de teoría del diseño.

El resultado es un generador que puede producir miles de paletas distintas, cada una coherente y usable desde el primer intento, con modo claro y oscuro listos para producción.

Escrito analizando el código fuente de color-algorithm.js del proyecto Armonic Themes.

Puedes verlo en https://themes.devcito.org

El algoritmo de Azar: cómo funciona el generador de aleatoriedad

2026-04-26T00:00:00+00:00

Azar es una suite de herramientas de aleatoriedad completamente estática, construida con Astro y Tailwind CSS. Su gran diferencia con otros generadores web es que no depende solo de Math.random(): aprovecha la entropía del usuario, la entropía del navegador y un pool interno que se alimenta de eventos reales.

Este artículo explica en detalle cómo funciona el algoritmo de Azar, por qué es mejor usarlo en este tipo de herramienta y qué hace cada parte del sistema.

1. Introducción: por qué Azar es distinto

La mayoría de las implementaciones de aleatoriedad en JavaScript se limitan a una línea:

const r = Math.random();

Eso es suficiente para animaciones simples, pero no para casos donde queremos que el resultado esté influido por la interacción humana. En Azar, toda la lógica corre en el navegador del visitante, y el objetivo es capturar entropía real y mezclarla de forma segura.

¿Qué busca Azar?

usar el movimiento del cursor como fuente de datos impredecibles
capturar toques y movimiento de dispositivo en móviles
usar el jitter natural de requestAnimationFrame
combinarlo con Math.random() para mayor robustez
exponer una API global window.azarRandom() que todas las herramientas usan

Azar no pretende reemplazar un generador criptográfico de clase mundial, pero sí añade calidad real frente a una solución puramente determinista basada en Math.random().

2. Arquitectura general del motor

El núcleo del motor está en src/layouts/Layout.astro, y se compone de tres bloques:

el pool interno de entropía (Uint32Array de 256 elementos)
la señal visual de entropía azarSignal
la API pública window.azarRandom()

Todas las páginas y componentes del sitio usan esta misma API para generar resultados aleatorios.

2.1 Estructura del pool

Azar usa un buffer circular de 256 enteros sin signo:

const POOL_SIZE = 256;
const pool = new Uint32Array(POOL_SIZE);
let poolIdx = 0;

Este pool no es solo almacenamiento: es el corazón de la mezcla. Cada evento relevante inyecta datos y cada generación consume valores del pool para producir números.

2.2 Función de mezcla xorMix

La función que mezcla valores internamente es un xorshift rápido:

function xorMix(a: number): number {
  a ^= a << 13;
  a ^= a >> 17;
  a ^= a << 5;
  return a >>> 0;
}

Esta transformación no es un generador criptográfico independiente, pero sí es excelente para mezclar bits de forma eficiente.

Cada vez que se alimenta el pool, se hace así:

function feedPool(v: number) {
  pool[poolIdx % POOL_SIZE] = xorMix(pool[poolIdx % POOL_SIZE] ^ (v | 0));
  poolIdx = (poolIdx + 1) % POOL_SIZE;
}

Ese feedPool combina el valor nuevo con el valor ya existente en la posición actual del pool, aplica la mezcla y avanza el puntero.

3. Las fuentes de entropía humana

Azar recoge entropía directa de la interacción del usuario. Estas son las fuentes principales:

3.1 `mousemove`

Cada movimiento del mouse contribuye con velocidad y coordenadas:

document.addEventListener("mousemove", (e) => {
  const speed = Math.hypot(e.movementX, e.movementY);
  boostSignal(speed * 0.0045);
  feedPool((e.movementX * 137 + e.movementY * 59) | 0);
  feedPool((e.clientX ^ (e.clientY << 8)) | 0);
}, { passive: true });

Se usa movementX y movementY para capturar la dinámica del movimiento, y además se inyectan las coordenadas clientX/clientY en el pool.

3.2 `touchmove` y `touchstart`

En móviles, los toques son igual de valiosos:

document.addEventListener("touchmove", (e) => {
  const t = e.touches[0];
  boostSignal(0.05);
  feedPool((t.clientX * 17 + t.clientY * 31) | 0);
  feedPool((performance.now() * 100) | 0);
}, { passive: true });

document.addEventListener("touchstart", () => {
  boostSignal(0.09);
  feedPool(performance.now() | 0);
}, { passive: true });

Los toques agregan coordenadas táctiles y tiempo, lo que es útil cuando no hay mouse.

3.3 `click`

Cada clic suma entropía adicional:

document.addEventListener("click", (e) => {
  boostSignal(0.07);
  feedPool((e.clientX * 7 + e.clientY * 11) | 0);
}, { passive: true });

La idea es simple: cada interacción del usuario debe cambiar el estado interno del pool.

3.4 `devicemotion`

Los móviles con acelerómetro proporcionan datos físicos reales:

if ("DeviceMotionEvent" in window) {
  window.addEventListener("devicemotion", (e) => {
    const a = e.acceleration;
    if (!a) return;
    const mag =
      Math.abs(a.x ?? 0) + Math.abs(a.y ?? 0) + Math.abs(a.z ?? 0);
    boostSignal(mag * 0.006);
    feedPool((mag * 1000) | 0);
  }, { passive: true });
}

El movimiento real del dispositivo introduce ruido que difícilmente puede ser predecible desde el lado del servidor.

4. Entropía de fondo: `requestAnimationFrame`

Incluso cuando el usuario está quieto, hay entropía disponible. El tiempo entre frames no es constante: depende de la CPU, el sistema operativo y otros procesos.

let lastRaf = performance.now();
function rafLoop() {
  const now = performance.now();
  const diff = now - lastRaf;
  lastRaf = now;
  feedPool((diff * 100000) | 0);
  feedPool((now * 10000) | 0);
  requestAnimationFrame(rafLoop);
}
requestAnimationFrame(rafLoop);

Ese diff y el now son mediciones de jitter natural. No son completamente aleatorios, pero sí aportan ruido constante.

Este patrón está inspirado en técnicas de generación de entropía donde se usa el retardo de reloj o de ciclo para obtener bits impredecibles.

5. Señal visual: `azarSignal`

Azar no solo genera números; también muestra un HUD que indica la “cantidad de entropía activa”. Esa señal es útil para el usuario y para transmitir la idea de que el sistema está vivo.

El cálculo es este:

const FLOOR = 0.08;
const CEILING = 1.0;
const DECAY_K = 0.975;
let signal = FLOOR;

function boostSignal(amount: number) {
  signal = Math.min(CEILING, signal + amount);
}

signal = Math.max(FLOOR, signal * DECAY_K + FLOOR * (1 - DECAY_K));

En otras palabras:

hay un piso mínimo de 8%
no se llega a 100%
cada frame usa un decaimiento multiplicativo
la señal sube con movimientos y toques

Eso produce una experiencia visual donde las acciones del usuario se traducen en una marca visible de energía aleatoria.

6. Generación final: cómo sale el número aleatorio

La función pública es azarRandom() y es la que usan todas las herramientas del sitio.

function azarRandom(): number {
  let s = 0;
  const t = (performance.now() * 10000) | 0;
  for (let i = 0; i < 8; i++) s ^= pool[(poolIdx + i) % POOL_SIZE];
  s ^= t;
  s ^= t >>> 16;
  s = xorMix(s);
  pool[poolIdx % POOL_SIZE] = s;
  poolIdx = (poolIdx + 1) % POOL_SIZE;

  const humanEntropy = (s >>> 0) / 4294967296;
  const machineEntropy = Math.random();
  return (humanEntropy + machineEntropy) % 1;
}

Paso a paso:

se extraen 8 valores del pool y se combinan con xor
se mezcla con el tiempo actual (performance.now())
se transforma de nuevo con xorMix
se guarda el valor resultante en el pool
se normaliza a un número entre 0 y 1
se suma con Math.random() y se aplica módulo 1

¿Por qué sumar `Math.random()`?

Porque aporta una fuente adicional del propio motor JS del navegador. Si por alguna razón la entropía del pool fuera baja, Math.random() refuerza el resultado.

La suma modular mantiene la distribución uniforme en el rango [0, 1).

7. Ventajas frente a `Math.random()` solo

7.1 Más variedad de fuentes

Math.random() depende del motor del navegador. Azar usa además:

movimiento del mouse
toques táctiles
acelerómetro
jitter de frames

7.2 Estado compartido

El pool interno acumula entropía entre eventos. Es decir, cada interacción altera un estado que persiste y se reutiliza.

7.3 Más difícil de predecir desde fuera

Un generador que solo usa Math.random() puede ser más fácil de inferir si el motor es conocido. Agregar la entropía del usuario hace que el resultado dependa de factores externos al navegador.

8. Dónde usa Azar esta API

Las herramientas del proyecto no generan números por su cuenta. Todas reclaman el mismo punto de acceso global:

src/components/tools/Sorteo.astro
src/components/tools/Dados.astro
src/components/tools/Cartas.astro
src/components/tools/Numero.astro
src/components/tools/Moneda.astro
src/components/tools/Ruleta.astro

Esto asegura consistencia: cualquier mejora en el motor se beneficia a todas las herramientas.

Aunque el algoritmo es la parte técnica, Azar también cuida el SEO y la presencia social.

En src/layouts/Layout.astro hay metadatos como:

canonical dinámico
og:image
twitter:image
preload de /preview.png
JSON-LD con schema.org

Esto mejora la calidad del sitio cuando se comparte en redes y también ayuda al rastreo de motores de búsqueda.

Enlaces relacionados

Astro
Tailwind CSS
MDN Math.random()
MDN crypto.getRandomValues()
schema.org WebApplication
requestAnimationFrame
10. Conclusión

Azar demuestra cómo un sitio estático puede ofrecer aleatoriedad de mejor calidad sin backend. En lugar de depender únicamente de un PRNG del navegador, combina:

entropía humana real,
jitter de hardware y sistema,
mezcla interna de pool,
y el propio Math.random().

El resultado es un sistema apropiado para juegos, sorteos y herramientas de azar en el frontend.

Si quieres, puedo preparar otra versión enfocada en cómo integrar este motor en una librería independiente o cómo agregarlo fácilmente a otro proyecto Astro.

Puedes verlo en https://azar.devcito.org

Google AdSense en Angular con osbo-adsense-angular

2024-06-30T00:00:00+00:00

osbo-adsense-angular

Google AdSense for Angular Applications

Source code https://github.com/Programmercito/osbo-adsense-angular Install

npm install osbo-adsense-angular

Use Add adsense code Use the standard AdSense code somewhere in your <head></head> as you normally would

<script async src=//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js></script>

Import NgModule Add AdsenseModule to the imports of your NgModule

import { OsboSenseModule } from 'osbo-sense'; @NgModule({ imports: [ OsboSenseModule }), ...

Use in the component html

<ngosbo-adsense [config]="config"></ngosbo-adsense> In the componente Typescript

// multiples ads this.config = {} as SenseConfiguration; this.config.tipo = "multiple"; this.config.dataadclient = "ca-pub-xxxxx"; this.config.dataadformat = "autorelaxed"; this.config.dataadslot = "999999999"; this.config.style = "display:block"; // display ads this.config1 = {} as SenseConfiguration; this.config1.tipo = "display"; this.config1.dataadclient = "ca-pub-xxxxx"; this.config1.dataadformat = "auto"; this.config1.dataadslot = "9999999"; this.config1.datafullwidthresponsive = "true"; this.config1.style = "display:block"; // infeed ads this.config2 = {} as SenseConfiguration; this.config2.tipo = "infeed"; this.config2.dataadclient = "ca-pub-xxxxx"; this.config2.dataadformat = "fluid"; this.config2.dataadslot = "99999999"; this.config2.dataadqlayoutkey = "xxxxxx"; this.config2.style = "display:block";

happy coding!

UPDATE.

the 1.0.0 version released!

Master-Detail Validation with Tokens for Store Security

2023-09-15T00:00:00+00:00

When we, as programmers, need to ensure acceptable security in our applications, we face challenges such as validations where we must prevent users from modifying data that doesn’t belong to them and for which they don’t have permissions.

We have frameworks, languages, and libraries that allow us, through roles, permissions, tokens, sessions, and others, to secure our developments, at least on the application side. However, there are validations that these tools don’t cover. I’m talking about validating the internal logic of the application when entering data into a table. For instance, let’s describe a case where it’s easy to validate a set of data and another case where it’s more complex and difficult to efficiently validate, especially when there’s more than one detail or even a chain of tables.

Case Study

We have two tables: a “sales” table and a “sales_detail” table. Users can enter, modify, and sell data, but only in the “store” where they work. Therefore, we would assume some fields as follows:

Sales Table

Id (sequential)
store_id
user
description
client

Sales Detail Table

Id (sequential)
sale_id
product_id
price

(Where sale_id is a Foreign Key with the Sales table)

Security Requirements

Users should only be able to add sales from the store where they are working.
Users should only be able to add details from the store where they are working.

Solutions for the Sales Table

Considering that there are user data in some authentication and authorization medium when calling our endpoint, a simple solution is to compare the storeid of the table against the storeid or the allowedid for the session user. If they match or are on this list, allow the sale record to be saved in the table.

This is common to do; sometimes developers forget, a problem that increases more in a REST architecture where requests don’t depend on anything prior to being executed. Likewise, these types of validations that contrast the table’s storeid against the user’s permissions are simple to do, and we could do it against more ids and more tables for a more complex validation.

Figure: Validation of the store entered with the user’s store, all the data needed for validation is available.

Solutions for the Sales Detail Table

Figure: Any sale is valid, even if it’s not from your store, creating a security hole in the application.

In this table, validations become a bit more complex since, although we still have or always have user data and their allowed stores, what we don’t have is the store_id of the sales table. Generally, the reality is that the developer is more focused on ensuring that their module or development works correctly and, not seeing this problem, either underestimates or omits it. However, it can be a significant security problem considering the following:

In the salesdetail table, the user could enter a saleid from another store that doesn’t belong to them. However, if they entered closed sales whose totals were already calculated and processed, it might not be taken into account by a state machine. But if they entered a sale_id from another store that is being processed, they could sell a product without the client even realizing that they are being sold more, or even worse, remove a product, or modify the quantity of products, causing problems with sales, stores, sellers, and many more issues.

To address this, we have logical solutions to perform consistent validation, some of which we detail below:

To validate, and since we don’t have the id of the sales table in the detail, what we could do is go against the master table and get the id to, once we have it, validate in the same way as with the master table. However, if we have a larger or more massive number of details, the number of calls to the master table to do this validation could cause system slowness. However, for small systems, it’s a logical validation and not very complex in reality.

Another alternative would be to return to the fields to validate in this case storeid as part of the fk key that is sent in the request and is automatically validated with the database for its existence and also validated against the session, the same as was done in the master table. This option would be the most feasible, but it would require that the ids to validate in this case the storeid were part of the FK key along with the detail id, ensuring that the validation against the stores with which the user has permission is made before entering the table.

But what happens if we are forced from the design to comply with rules like normalization that wouldn’t allow us to keep the fields in each table, and what happens if there are more details of the details in a chain, the redundancy of the data would be much greater than two tables, then we have to resort to another type of validations, here we come with my solution proposal, a solution that I consider more in line with large and scalable systems.

Figure: If validated, an error 403 is triggered because that sale doesn’t belong to your assigned store.

Proposed Solution

The proposed solution avoids going to the database to make the query in what could be a large table, although it involves some processing, but without the use of queries or other things, it should cost much less than other solutions, making it a better solution than the others.

For this, we will use a token that contains the information of the id of the record that this user has access to, that is, the saleid where they have already entered, in some other cases they could have other ids that would vary according to the type of validation we want to perform, for this case this signed token must contain the saleid and the user id together and signed to be able to validate the user who has permission to the sale detail and can allow operations, this use could also have variations of states or operations on the table but for our example, it would only have the general information of the sale as well as the user so that it doesn’t serve more users.

For the token, we have two options that we could use, so that the client sends with the request and it would depend on the user to see which one to use:

JWT
HMAC

A JWT would have the advantage of having expiration dates, other extra algorithm data, the possibility of sending more data, and as a disadvantage the verification of the signature that would take a little longer than an HMAC but its versatility would give us advantages of more uses or combine other data to validate for extra logic.

An HMAC can send any data, and the hash is the signature to verify, these data could be used for validation, however, the token serves forever so the table would have to have some protection mechanism to prevent more data from being entered for that sale and the client forgets the token for greater security.

In our case study, we can use either of the two, JWT is the most known and our choice in this case that will be generated once the data is created in the master Sales table and saved by the client in a safe place, when the client requires sending data from the detail table.

Steps to follow to send data to the table with validation:

Once the client requires performing actions on the “sales_detail” table, they send the token along with the request as a header (in cases like forms they could send it as a hidden field if it’s not an object or a body).
Once on the server, the backend should verify the token signature.
If the signature is valid, the backend will decode the data sent in the token to a verifiable format.
The data is verified and compared with

the data sent and with the session data, in this case, verify that the saleid is the same as the saleid sent in the body and the userid compared with the userid of the session or the authorization method used.

If everything verified is correct, then the requested action can be performed by the used endpoint, in this example case, use the insert into the table.
If any of the validations fail, then the endpoint will issue a security error and that the permissions are wrong.

As you can see, this will prevent users from being able to edit, create, or delete information from other stores, as well as depending on how the validation is also preventing information from already closed sales from being entered, as in the use of JWT automatically since the generated JWTs would already be expired when the sale is closed, logic that the developer will have to see which is the best and which gives him more security.

Figure: Solution with a token that includes the missing information for validation; it is considered valid since it is signed at the moment it is validated in the master table.

Library Solution

To solve this problem more simply, a library has been built in Java to help perform these types of validations with the following features:

Generates the token with the information to be validated.
Easily choose between the two types of tokens (JWT and HMAC).
Configure the algorithm in the case of using JWT.
Validate the integrity of the token.
Retrieve the data for its validation.

To use the library with Maven:

Token Generation

Here we have the example of how it could be generated and responded in a header to be read by the client:

As you can see, the user and the sale to the detail will be sent signed, where as it is signed it will be assumed that there is permission on this sale. Bearing in mind that the storeid should also be validated, it is guaranteed that this saleid can be edited.

Token Validation

The example shows how the token would be retrieved from the headers sent by the client and a basic validation:

The library will save us the time of writing code to generate and validate the token, as well as retrieve the data to validate easily. With all this, we have been able to overcome a major security problem when developing that we often don’t take into account or solve in other ways or directly by having large teams some don’t take it into account and that can cause major problems in the future if a user or a hacker manages to exploit this problem, although with a different design, for example, having large and alphanumeric keys, the most optimal are always sequential, and with these tokens, we can protect any endpoint.

References

Libreria en maven

Maven Central: io.github.programmercito:DataSealGuard (sonatype.com)

Código fuente de la librería

Programmercito/datasealguard-java (github.com)

Perfil de github

Programmercito (Programmercito) (github.com)

Repositorio de ejemplos

Programmercito/datasealguard-java-examples (github.com)

La Importancia de una Arquitectura Base de Código

2023-08-21T00:00:00+00:00

Desarrollar aplicaciones o sistemas ERP escalables con un alto número de líneas de código es una tarea compleja que requiere una planificación cuidadosa y un enfoque estructurado. Una estrategia comúnmente recomendada en este contexto es la creación de una arquitectura base de código sólida. Esta arquitectura base se convierte en el cimiento sobre el cual se construirá todo el sistema, y está compuesta por bibliotecas, módulos y código base que abordan tareas comunes y repetitivas, como la creación de pantallas, APIs y otras funcionalidades esenciales de la aplicación.

La razón principal detrás de desarrollar una arquitectura base de código es la coherencia y la eficiencia. En proyectos de gran envergadura, es fácil que los desarrolladores utilicen diferentes frameworks, bibliotecas y enfoques, lo que puede llevar a una falta de uniformidad en la estructura del código y dificultar el mantenimiento a largo plazo. Al proporcionar una arquitectura base, se establecen directrices claras para el desarrollo, lo que asegura que todos los miembros del equipo sigan un conjunto común de estándares y prácticas. Esto facilita la colaboración y permite que el código sea más legible y mantenible en el tiempo.

Además de fomentar la coherencia, una arquitectura base de código también puede mejorar la productividad. Los desarrolladores no necesitarán reinventar la rueda cada vez que enfrenten una tarea común, ya que podrán aprovechar los componentes y módulos predefinidos. Esto acelera el proceso de desarrollo y reduce la probabilidad de errores.

Para asegurar el éxito de una arquitectura base de código, es esencial llevar a cabo un análisis profundo de los requisitos del sistema y de las necesidades de la aplicación. Esto permitirá identificar las características y funcionalidades comunes que deben ser parte de la arquitectura base. Algunos elementos clave pueden incluir:

Librerías y Frameworks Unificados: Seleccionar un conjunto coherente de librerías y frameworks que sean adecuados para el proyecto y que todos los desarrolladores utilicen. Esto evita la proliferación de tecnologías dispersas en el sistema.
Patrones de Diseño: Definir patrones de diseño estándar que guíen la estructura de la aplicación. Esto asegura que la arquitectura sea escalable y adaptable a medida que el sistema crece.
Módulos Reutilizables: Desarrollar módulos y componentes reutilizables que aborden funciones comunes. Esto incluye plantillas para pantallas, lógica de negocios genérica y componentes de interfaz de usuario.
Documentación Detallada: Proporcionar documentación exhaustiva sobre la arquitectura base, explicando cómo se deben utilizar los componentes, las pautas de codificación y las mejores prácticas.
Actualización Continua: Mantener la arquitectura base actualizada con las últimas tecnologías y mejores prácticas. Esto garantiza que el sistema siga siendo eficiente y relevante a lo largo del tiempo.

En resumen, desarrollar una arquitectura base de código para aplicaciones o sistemas ERP de gran tamaño es una estrategia efectiva para promover la coherencia, la eficiencia y la productividad en el desarrollo. Al proporcionar un conjunto sólido de estándares y componentes, se establece una base sólida para el crecimiento y el mantenimiento a largo plazo del sistema.

Usando JWT para Mostrar información sin Base de Datos, tampoco backend

2022-09-25T00:00:00+00:00

En el mundo moderno del desarrollo web, a menudo buscamos soluciones que reduzcan la complejidad y los costos. Una idea innovadora es usar JSON Web Tokens (JWT) para transportar y validar datos sin la necesidad de una base de datos. En este blog, exploraremos cómo puedes mostrar información usando JWT en un enlace y un sitio web, sin necesidad de usar un backend, usaremos Java para la generación del token sin levantar ninguna backend ( podríamos usar cualquier otro lenguaje inclusive typescript sin levantar ningún servicio publicado) y Angular para el frontend.

Firma Asimétrica y JWT

La firma asimétrica utiliza un par de claves: una clave privada para firmar el JWT y una clave pública para verificar la firma. Esto significa que mientras el emisor firma el JWT con su clave privada, cualquier parte que tenga la clave pública correspondiente puede verificar la autenticidad del JWT, pero no puede modificarlo ni volver a firmarlo.

¿Cómo se utiliza JWT con firma asimétrica para transmitir información?

Creación del JWT:

El emisor define el payload con la información que desea compartir.
El JWT se firma usando un algoritmo de firma asimétrica y la clave privada del emisor.
El JWT firmado se envía al receptor.

2. Recepción y Validación del JWT:

El receptor obtiene el JWT.
Se valida la firma del JWT usando la clave pública del emisor.
Si la validación es exitosa, el payload se decodifica y se utiliza la información.

¿Por qué JWT?

JWT es un estándar abierto que define una forma compacta y autónoma de transmitir información entre partes en forma de objeto JSON. Esta información puede ser verificada y confiada porque está firmada digitalmente.

Ventajas:

- Simplicidad: Elimina la necesidad de bases de datos o backends complejos.

- Integridad de datos: La firma garantiza que los datos no han sido alterados.

- Distribución: Un simple enlace con el JWT permite acceder al valor.

- Seguridad: Al ser un token firmado el contenido de este no se puede modificar y si se lo hace el sitio web no lo mostrara, haciendo que lo que se mande no se pueda cambiar para mostrar otra cosa.

Desafíos y consideraciones:

- Generación del JWT: Aunque no necesitas un backend para servir los datos, aún necesitarías algún mecanismo o proceso para generar el JWT con el valor de la moneda.

- Expiración del JWT: Los JWT generalmente tienen un tiempo de expiración. Si alguien intenta acceder al enlace después de la expiración, no podrá ver el valor.

- Tamaño y eficiencia: Si bien un JWT es relativamente pequeño, es posible que no sea el método más eficiente para transportar un simple valor numérico.

- Seguridad: Aunque el JWT garantiza la integridad de los datos, no garantiza su confidencialidad. Cualquiera puede decodificar un JWT y ver su contenido.

- Dependencia de la clave: Si la clave privada utilizada para firmar el JWT se pierde o se ve comprometida, tendrías que generar una nueva y actualizar cualquier lógica del lado del cliente que use la clave pública para la verificación.

Implementación:

1. Generación del JWT con Java:

2. Validación y visualización con Angular:

Para el frontend, usaremos Angular con TypeScript. Hay varias bibliotecas disponibles para manejar JWT en TypeScript, como jsrsasign.

3. Funcionamiento.

Hasta este punto sabemos bien como una firma asimétrica es usa en jwt para enviar información que en el camino no se puede modificar, pero como se hace.

Usaremos la libreria JwtLinkDinamic

<dependency>
<groupId>io.github.programmercito</groupId>
<artifactId>JwtLinkDinamic</artifactId>
<version>1.0.1</version>
</dependency>

2. Aca ejemplo de uso, puede usarse en un backend, aun que la idea es que no se use en uno , si no en una pc local que no encesita estar prendida todo el tiempo:

public static void main(String[] args) {
String link = “https://programmercito.github.io/jwtlink-web-example/#/example/${jwt}”;
MonedaPrecio monedap = new MonedaPrecio();
monedap.setMoneda(“Dolar”);
monedap.setPrecio(33.23);
String resul = JwtMessage.generate(link, monedap);
System.out.println(resul);
}

Aca vemos el resultado:

https://programmercito.github.io/jwtlink-web-example/#/example/eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE3NTg3NTQwNDUsInYiOiJ7XCJtb25lZGFcIjpcIkRvbGFyXCIsXCJwcmVjaW9cIjozMy4yM30ifQ.bFApTsTqufmxrc7p6Eu9KYvVGsrlmJPV2VMbIdT6I8FMSJzUnA0ERqGBLKPspfN3uzB0rkw-Ftu97EkVqcoQIgwsMKw2wa_7EJW8TTp9imQ5nXv2H-Z5Jk43O6JKYZrb7b87pQkf-uajVjWRmWDmsN5l457MiG7Ln0_H7v0uAQsI251UWyLCTvsyAUkm1c2sRBPBVHoTDERSNoWFdWfZLDyoviyNB_iPUHVcTPxMJZAXd6Dg0MNC-TdyAwPSXp94J_lXjzn7x_o4-IExY19JlrJBoZ5lRZAQIi57y92U0lZNlTrjPZI7jkH_CnKpGv3qaVTqq7V35cCG2BjE8wH79A

3. Para poder desplegar la apllicacion en angular como dijimos no se usara un backend pero si un frontend, un ejemplo se ha desplegado en:

Programmercito/jwtlink-web-example (github.com)

aca el codigo de llamado al JWT:

import { Component, OnInit } from ‘@angular/core’;
import { ActivatedRoute } from ‘@angular/router’;
import { ValidateService } from ‘src/app/core/validate.service’;
import { Buffer } from ‘buffer’;

@Component({
selector: ‘example’,
templateUrl: ‘./example.component.html’,
styleUrls: [‘./example.component.sass’]
})
export class ExampleComponent implements OnInit {
dato: string = “”;
valido: boolean = true;
objeto: any;
constructor(private active: ActivatedRoute, private valid: ValidateService) {

}
ngOnInit(): void {
this.dato = this.active.snapshot.paramMap.get(“data”) ?? “”;
if (this.valid.valid(this.dato)) {
let jwtpartido: string[] = this.dato.split(“.”);
let base: string = Buffer.from(jwtpartido[1], ‘base64’).toString(“utf8”);
let json: any = JSON.parse(base);
this.objeto = JSON.parse(json.v);
} else {
this.valido = false;
}
}
}

Una vez accediendo al link podemos ver como hemos accedido a los datos del jwt de manera segura:

Repo de la aplicación de ejmplo de uso de JWT:

Programmercito/jwtlink-web-example (github.com)

Conclusión:

Usar JWT para transportar y validar datos es una solución ingeniosa que reduce la complejidad y los costos asociados con bases de datos y backends. Sin embargo, es esencial ser consciente de las limitaciones y desafíos que presenta esta aproximación. Es importante recordar que, aunque puedes decodificar y validar un JWT en el lado del cliente, sin embargo, hay que tomar en cuenta que si o si, debe usarse una firma asimétrica, que los links y su información debería ser publica ya que seguridad en el frontend es siempre relativa, luego esta técnica resulta ser útil a la hora de faltar backend o no se puede gastar en él.

devcito blog

Creación del Blog y Nuevo Diseño Git Sketchbook

El Diseño: Git Sketchbook

¿Qué verás por aquí?

Cómo funciona el algoritmo de colores de Armonic Themes

El problema de las paletas “aleatorias”

El principio fundamental: un solo hue lo gobierna todo

Las estrategias de armonía

Los Moods: la personalidad de cada paleta

La micro-variación: el toque de aleatoriedad controlada

Accesibilidad automática: WCAG sin esfuerzo

Cómo funciona el modo oscuro

Lo que se comparte entre light y dark

Lo que cambia entre light y dark

El flujo completo en 12 pasos

Nombrar cada paleta

En resumen

El algoritmo de Azar: cómo funciona el generador de aleatoriedad

1. Introducción: por qué Azar es distinto

¿Qué busca Azar?

2. Arquitectura general del motor

2.1 Estructura del pool

2.2 Función de mezcla xorMix

3. Las fuentes de entropía humana

3.1 mousemove

3.2 touchmove y touchstart

3.3 click

3.4 devicemotion

4. Entropía de fondo: requestAnimationFrame

5. Señal visual: azarSignal

6. Generación final: cómo sale el número aleatorio

¿Por qué sumar Math.random()?

7. Ventajas frente a Math.random() solo

7.1 Más variedad de fuentes

7.2 Estado compartido

7.3 Más difícil de predecir desde fuera

8. Dónde usa Azar esta API

9. SEO y compartición social

Enlaces relacionados

10. Conclusión

Google AdSense en Angular con osbo-adsense-angular

Master-Detail Validation with Tokens for Store Security

Case Study

Sales Table

Sales Detail Table

Security Requirements

Solutions for the Sales Table

Solutions for the Sales Detail Table

Proposed Solution

Steps to follow to send data to the table with validation:

Library Solution

La Importancia de una Arquitectura Base de Código

Usando JWT para Mostrar información sin Base de Datos, tampoco backend

3.1 `mousemove`

3.2 `touchmove` y `touchstart`

3.3 `click`

3.4 `devicemotion`

4. Entropía de fondo: `requestAnimationFrame`

5. Señal visual: `azarSignal`

¿Por qué sumar `Math.random()`?

7. Ventajas frente a `Math.random()` solo