Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué es WebSub? Implementaciones y casos comunes


WebSub , que une a editores y suscriptores, se ha convertido en un método bien adoptado para actualizar contenido en Internet. Dado que el protocolo se puede utilizar para cualquier tipo de datos accesible a través de HTTP, es un método popular para comunicar notificaciones y cambios, y es una gran alternativa al sondeo constante del servidor del pasado. Pero, ¿cómo funciona exactamente el ecosistema WebSub?

En este artículo, exploraremos WebSub, el poderoso ecosistema utilizado por WordPress, CNN y muchas otras redes de publicación para impulsar contenido en la web. Como hemos hecho con otros estándares de Internet en el pasado, profundizaremos en cómo funciona este, identificaremos los casos de uso en los que destaca y proporcionaremos ejemplos de implementaciones de WebSub para mostrar cómo el protocolo  transmite datos de forma segura .

Algunos antecedentes sobre WebSub

WebSub originalmente tenía un nombre mucho más difícil de pronunciar: PubSubHubbub . Comenzó como una extensión de los protocolos Atom y RSS , que se utilizan para generar notificaciones de cambios en tiempo real desde prácticamente cualquier tipo de datos. Siempre que se pueda acceder a los datos mediante HTTP, se puede transmitir un cambio a un cliente y los cambios de HTTP se envían al cliente sin necesidad de que el cliente utilice recursos para el sondeo.

Este estilo de diseño es ideal para noticias , actualizaciones de foros y más, porque permite una especie de esquema de actualización asincrónico que cambia el enfoque tradicional de sondeo de cabeza. En lugar de que un cliente vaya a un sitio web para buscar una actualización, esa actualización se puede enviar automáticamente a un cliente que ha "aceptado" esa comunicación, lo que permite el conocimiento pasivo del contenido a través de alertas.

En enero de 2018 , el W3C adoptó WebSub como una recomendación basada en estos y otros méritos. Para ver por qué es una tecnología tan prometedora, veamos cómo funciona realmente.

Cómo funciona: ¿Qué es un patrón de publicación-suscripción?

WebSub forma una red de editores , suscriptores y centros . Esta red determina cómo se envía el contenido, cuándo se envía y a quién se envía. Los editores son el eje de la red, siendo los propios proveedores de contenidos los que generan los datos que se actualizan y envían a los distintos clientes. Los editores generan este contenido y exponen el contenido a través de referencias de concentrador en los encabezados HTTP, adjuntándolo a un "tema", que etiqueta ampliamente qué es el contenido en realidad y cómo pertenece al usuario.

Crédito del diagrama: www.w3.org

Cuando se cambia algo, el editor publica estos cambios en el propio centro. El suscriptor recupera contenido HTTP del servidor web y, si el contenido contiene una referencia a un concentrador, ese suscriptor puede suscribirse a ese tema de URL de referencia Al hacerlo, básicamente le hace saber al editor que quiere estar "informado" y que cuando se envía una actualización, quiere que se le notifique.

Los concentradores utilizan mecanismos de webhook para notificar a los suscriptores sobre estos cambios, actualizando de forma remota su contenido y enviando contenido de referencia automáticamente. El hub, entonces, actúa como una especie de intermediario pasivo , expulsando el contenido y recibiendo suscripciones a ese contenido sin generar realmente o suscribirse.

Uno de los principales beneficios de WebSub es que incluye un mecanismo de seguridad bastante robusto . En este proceso, los suscriptores pueden enviar un secreto al Hub, que luego se usa para generar una clave HMAC . Luego, esta clave se envía al suscriptor, quien puede verificar el origen comparando la firma con una firma calculada localmente en función de su secreto. Esto garantiza una conexión segura, porque solo el suscriptor y el concentrador pueden generar una clave HMAC segura a partir del contenido secreto.

Relacionado: 5 protocolos para arquitecturas de API basadas en eventos

Arquitectura basada en eventos y WebHooks

Todo el concepto detrás de WebSub, y realmente WebHooks en general, es que se envíen notificaciones para el contenido modificado. Obviamente, esto funciona muy bien para la publicación regular de sitios web, agregadores de noticias, etc., porque el contenido siempre cambia y es mejor enviarlo de forma remota sin necesidad de encuestas.

A pesar de eso, el mayor valor de las notificaciones impulsadas por eventos no reside en las implementaciones del agregador de noticias, ya que el contenido se envía en forma de resumen y se envía sin exigir que el usuario encuentre este evento en un sitio web o portal primero, esto hace que el evento La naturaleza impulsada por WebSub y WebHooks es fundamental para actualizar el contenido de las API, impulsar nuevos cambios de versión e incluso enviar bases de código completamente nuevas al usuario. Para ver cómo funciona esto y por qué es valioso, primero definamos y separemos WebSub y WebHooks en general.

WebHooks carece de verificación

WebHooks es un concepto en el que el cliente se registra en un webhook usando una URL de devolución de llamada , y esta URL luego se usa para enviar contenido al usuario llamando a dicha URL. En el lado de la API, esto se puede implementar en una variedad de formas y niveles de complejidad . Puede ser tan simple como proporcionar un único webhook que se puede utilizar para enviar contenido efímero (es decir, que expira automáticamente para el usuario después de un tiempo establecido) y tan complejo como ofrecer una variedad de GETllamadas que pueden recuperar una lista de devoluciones de llamada, editar URL existentes y modificar estos contenidos.

Los WebHooks son bastante complejos, pero para nuestros propósitos, debemos entender que son un mecanismo para enviar contenido a través de URL de devolución de llamada. En teoría, esta implementación es excelente, pero a menudo requieren sistemas adicionales para asegurarlos. Dado que la URL de devolución de llamada es pública y está expuesta de forma clara, un actor malintencionado puede interceptar esta comunicación y enviar datos falsos. Además, un ataque de denegación de servicio podría paralizar fácilmente el punto final. Incluso algo tan simple como los errores de la aplicación del usuario podría hacer que la entrega fallara, y la simple negligencia del usuario podría resultar en que no se hicieran cambios.

En pocas palabras, los WebHooks no proporcionan verificación de intención en su configuración predeterminada.

WebSub es más seguro

WebSub fue diseñado para solucionar muchos de estos problemas. En primer lugar, dado que WebSub tiene un mecanismo de seguridad incorporado, esencialmente puede desafiar la intención de la solicitud en cualquier etapa del proceso. Asegurarse de que la información sea enviada por el concentrador que dice se puede hacer comparando la clave HMAC con una calculada localmente, verificando que el concentrador esté actuando de buena fe.

Asegurarse de que permanezca sin cambios se puede hacer fácilmente mediante el hash del contenido del editor y comparando el contenido con hash localmente, lo que solo se puede hacer si confiamos intrínsecamente en el editor en primer lugar. Los ataques DoS pueden ser anulados por este mismo proceso, y con métodos integrados de limitación de velocidad o respuestas simples de desafío al exceso de tráfico, esto puede anularse aún más efectivamente.

Existe una amplia gama de beneficios adicionales al usar WebSub sobre WebHooks, especialmente en ciertas aplicaciones, pero en general, son mucho menos importantes que el mecanismo de seguridad agregado que crea una confianza de intención.

Cabe señalar que WebSub envía contenido de forma predeterminada a través de un ping ligero, lo que significa que solo se envían las partes del encabezado como título, enlaces, etc. Esto lo hace más ligero de forma predeterminada que WebHooks. Dicho esto, WebHooks tiene una opción de ping de luz similar que se puede configurar y, como tal, en teoría, podría funcionar de manera similar. Dicho esto, la naturaleza predeterminada del ping ligero agrega valor en gran medida, incluso si viene con la advertencia de que una llamada POST que se transforma en múltiples llamadas GET o sub-POST puede convertirse rápidamente en una limitación de velocidad si no se maneja adecuadamente.

Para más información lea: WebHooks vs WebSub: ¿Cuál es mejor para la transmisión de eventos en tiempo real?

Beneficios y casos comunes

Veamos las ventajas de este  patrón Publicar-Suscribir para ver dónde pueden surgir algunos casos comunes. Este patrón es ante todo una excelente opción para la escalabilidad . Dado que solo los contenidos suscritos se envían al usuario y, por lo general, se envían a través de un ping ligero, el uso de recursos para la notificación es mucho menor que los sistemas de sondeo automatizados tradicionales y, por lo tanto, puede escalar rápidamente a tamaños más grandes. Sin embargo, este beneficio puede evaporarse cuando se pasa a implementaciones de nivel empresarial, con una mayor cantidad de suscriptores que exigen recursos del editor.

Otro gran beneficio es el hecho de que este patrón implementa un acoplamiento suelto . El suscriptor no necesita saber nada sobre la estructura, organización, topología o función de los servidores y sus sistemas de datos para obtener contenido, sino que solo tiene que conocer el punto final principal al que se accede. Debido a esto, hay un mayor nivel de seguridad inherente a la opacidad que da como resultado una mayor confiabilidad y privacidad a nivel de servidor.

Finalmente, en este patrón, el sistema tiene un nivel de funcionalidad asincrónica que es difícil de lograr en los sistemas tradicionales. Si el suscriptor falla, el editor aún funciona, enviando contenido. Por el contrario, si el editor falla, el suscriptor todavía tiene acceso a los registros históricos y al contenido, y no está "excluido" de otros cambios.

Con todo esto en mente, cualquier situación en la que el contenido se envíe mejor de un proveedor a un suscriptor con una metodología segura se beneficiaría enormemente de la implementación de WebSub. Veamos dos implementaciones teóricas para ver esto en acción.

Implementación hipotética 1 - Eco

“ Echo ” es una API que utiliza una serie de API de terceros para recopilar contenido y generar listas de acuerdo con un deseo, interés o necesidad declarados por el usuario. Cuando se encuentra este contenido, se envía al usuario como parte de una colección, es decir, se lanza un nuevo álbum de su artista favorito, por lo que Echo envía este álbum en un formato de agregador de noticias al suscriptor con un enlace para escuchar el sencillo. del album.

El usuario puede definir una colección para que sea prácticamente cualquier cosa, desde nuevos álbumes hasta artículos destacados en un sitio de noticias, desde nuevas noticias de videojuegos hasta títulos que se agregan a su servicio de transmisión favorito. En algunos casos, esto puede requerir el paso de credenciales para iniciar sesión en API y sistemas de terceros para generar estas listas de contenido.

En este caso de uso, la seguridad inherente a WebSub es lo que realmente está en juego. Ser capaz de determinar que el actor en cuestión es quien dice ser es extremadamente importante, especialmente si vamos a confiar en él con cualquier cantidad de credenciales. Si esta información se cifra en tránsito, aumenta la confidencialidad y, cuando se combina con cifrado en reposo, se convierte en un servicio de notificación seguro que no se limita a un solo proveedor, red social o fuente de datos.

Implementación hipotética 2 - ASyncee

“ ASyncee ” es una startup que busca ofrecer proyectos de trabajo a corto plazo como intermediario entre trabajadores y empleadores. La empresa ha identificado una debilidad importante en las soluciones actuales, que requieren el uso de la comunicación tradicional y hacen que, para los trabajadores, buscar trabajo sea a menudo un trabajo en sí mismo.

Por tanto, la puesta en marcha está diseñada para registrar un trabajo de un cliente y transmitir ese trabajo a los usuarios que han registrado un interés en ese "tema" o tipo de trabajo. Debido a la naturaleza de estos trabajos, la demora entre las publicaciones principales y el hecho de que las publicaciones de trabajo no son consistentes o predecibles, ASyncee ha optado por aprovechar WebSub para actualizar los clientes de forma asincrónica.

Al permitir que el usuario opte por ciertos temas, como "Trabajos de arte" o "Trabajos de redacción", los datos que se le envían se pueden adaptar específicamente al usuario en cuestión y sus habilidades específicas, eliminando la necesidad de buscar términos específicos. y categorizaciones demasiado amplias para encontrar publicaciones relevantes. El usuario puede acceder a puntos finales o temas adicionales para solicitar información adicional.

La clave para esto es que, si el cliente o el proveedor se quedan en silencio, el otro todavía puede funcionar y aprovechar los datos generados. Si no hay trabajos adicionales, el usuario aún puede usar sus valores almacenados localmente para aplicar a trabajos y utilizar otros puntos finales para verificar otras ofertas. Si el usuario se queda en silencio, el generador de contenido nunca sabrá que nada ha cambiado. Dado que la naturaleza de estos datos es algo sensible, y algunos trabajos quieren mantener a sus solicitantes algo ocultos, el hecho de que haya una división entre los generadores de contenido y el usuario final significa que el cartel del trabajo no necesita saber quién está interesado hasta que no haya realmente aplicado.

Conclusión

WebSub es una tecnología prometedora y, dado el caso de uso correcto, se puede aprovechar para proporcionar bastante valor. La notificación de contenido nuevo, ya sean nuevas revisiones de la base de código o nuevas ofertas de trabajo, es la función principal de muchas API y, como tal, simplificar este proceso y reducir los recursos demandados puede ser muy beneficioso para la mayoría de las API que se ajustan a los criterios establecidos.

Dicho esto, WebSub es solo un enfoque. Para un servicio que no puede utilizar ese patrón o un servicio que exige una funcionalidad adicional, WebSub no es una opción sólida; sin embargo, para los servicios que pueden funcionar dentro de esa estructura, puede ser la oferta más poderosa hasta la fecha.

 

Publicar un comentario

0 Comentarios