Webhooks salientes y sus destinos

El emisor firma cada aviso para que el receptor pueda comprobar que viene de él. Si el mismo secreto sirve para todas las empresas suscritas, cada una de ellas lo conoce, y cualquiera puede fabricar un aviso firmado que otra aceptará como auténtico. El secreto, además, se vuelve imposible de rotar sin coordinar a todos a la vez.

Lo habitual es un secreto distinto por suscripción, que se muestra una sola vez al crearla, se puede rotar con un periodo en que valen el viejo y el nuevo, y se guarda en el servidor como cualquier otro secreto. La forma de firmar —marca de tiempo incluida en lo firmado, cuerpo exacto— es la misma que se exige a un proveedor cuando uno es el receptor.

Abre el laboratorio. En ejemplo-carga.json está lo que viaja en cada aviso: nombre, documento y teléfono del empleado, y sus dos direcciones. Revisa en suscripciones.txt el esquema de cada destino.

En emisor-avisos.js el comentario final explica quién puede cambiar un destino y cuándo surte efecto. Lee cambios-suscripciones.txt en orden y fíjate en tres cosas del cambio de la tarde del 30 de noviembre: quién lo hizo y desde cuándo existía esa cuenta, a qué dominio apunta ahora el destino frente a los que usa esa empresa, y si alguien más se enteró.

Mide el alcance en envios-salientes.txt: entregas de esa suscripción al nuevo destino, a partir del cambio, que el receptor aceptó. Las que respondieron con error no confirman que el dato se quedara allí, así que en el informe se cuentan aparte.

Cambiar un destino es mover un flujo de datos personales a otra parte, con la misma importancia que cambiar la cuenta bancaria de un proveedor. Lo que no es de este módulo, porque ya lo cubre el de llamadas salientes del servidor, es impedir que el destino apunte a la red interna; aquí la pregunta es quién decide a dónde van los datos de las personas.