Proyecto tipo: Bot para publicar artículos automáticamente

PROBLEMA

El cliente quiere publicar artículos automáticamente sin la necesidad de intervención humana en su web que está gestionada por un CMS (WordPress).

Proporciona una serie de temáticas y quiere que los artículos tengan cierta actualidad.

Se publicará un artículo cada semana.

PROPUESTA

Se hará una investigación de fuentes de información de donde sacar información de actualidad sobre las temáticas indicadas. Se elegirán 3.

También se buscarán fuentes de información relacionada aunque no sea de actualidad. Se elegirán 2.

Se hará un análisis para determinar cual es la mejor lógica para componer todo lo que se pueda obtener de las distintas fuentes de información en un único artículo con sentido.

Se planteará una plantilla para el formato de los artículos.

Las fuentes que no sean de actualidad se preprocesarán para dejar los datos preparados para los siguientes 2 años tras la puesta en marcha. Adicionalmente, se creará un manual para que cualquiera con conocimientos mínimos pueda repetir dicha tarea cuando se precise.

Se programará el código del bot, teniendo dos componentes principales:

  • Una araña que examine las distintas fuentes de actualidad y recopile la información.
  • Un bot que sea el que efectivamente se encargue de publicar artículos automáticamente en el WordPress del cliente.
Tecnologías

Se usará Python o PHP en función de comprobaciones pendientes de los servidores del cliente, para el código fuente de los dos programas planteados.

Como almacenamiento, dado que no se requiere una gran persistencia y hay mucha tolerancia a errores, se usará SQLite.

El cliente deberá proporcionar acceso de administrador a su instalación de WordPress o realizar las siguientes acciones para el testing y la puesta en marcha:

  • Proporcionar un usuario que tenga permisos de creación de artículos pero no de publicación para el testing.
  • Proporcionar un usuario que tenga permisos para publicar articulos en el WordPress.
  • Realizar las modificaciones necesarias en su instalación de WordPress para asegurar la disponibilidad de la API Rest y alguno de sus plugins de autenticación.

PRECIO

3.700€

TIEMPO

Estará disponible en 2 semanas para verificación por parte del cliente y la puesta en producción, que llevará otra semana. Dado que los artículos se publican cada semana, el primero saldría publicado un mes tras la aporbación del presupuesto.

Nota aclaratoria:

Este proyecto tipo, es un ejemplo de proyecto que se ha realizado o se podría realizar. En ningún caso tiene validez como presupuesto real y sólo pretende documentar las distintas posibilidades que existen.

Actualmente, con los cambios que ha habido en cuanto a las posibilidades existentes, la propuesta podría ser diferente en estos momentos.

Se han omitido nombres de empresas y productos.

Por favor, si tuviese necesidad de algo similar, no dude en ponerse en contacto.

How to implement a distributed OAuth 2.0 system

Some months ago (more than a year), I was playing with the WordPress REST API. I did an analysis about how to implement a distributed OAuth 2.0 system as an attempt to collaborate with the community. I wrote it as a comment over a discussion post, but I am going to replicate that here in order to save it with my other ideas and works.

  • coolapp.com is the site of the app
  • cooldev.com is the WP site of the developer in which I defined the app as multitenant
  • cooluser.wordpress.com is the WP site of the user who wants authorize coolapp.com to interact

01- User access to coolapp.com and says “Hey, I want to use this cool app”
02- coolapp.com ask for its server and user writes cooluser.wordpress.com
03- coolapp.com ask to cooluser.wordpress.com to identify the user
04- the user writes his credentials in cooluser.wordpress.com
05- cooluser.wordpress.com redirects to coolapp.com with a code saying “Yeah, this man is my man”
06- coolapp.com then ask to cooldev.com and says “Hey, I have a user with a code that wants to acces to the resource cooluser.wordpress.com and I am the coolapp.com (this is my client_id and this my client_secret)”
07- cooldev.com generates a token
08- cooldev.com says to cooluser.wordpress.com “Hey, I just generated this token that expires in 3600 seconds”
09- cooluser.wordpress.com says “I would prefer not to work, but you know, it’s ok”
10- cooldev.com sends the response to coolapp.com with the token
11- then coolapp.com using the token, can now ask to cooluser.wordpress.com to do some stuff

If you look at this diagram

Abstract Protocol Flow
Abstract Protocol Flow

Client = coolapp.com
Resource Owner = cooluser.wordpress.com
Authorization Server = cooldev.com
Resource Server = cooluser.wordpress.com

The RFC says:

“The interaction between the authorization server and resource server
is beyond the scope of this specification. The authorization server
may be the same server as the resource server or a separate entity.
A single authorization server may issue access tokens accepted by
multiple resource servers.”

but with some conversation like the one in 8 and 9 it could be resolved.

Resumen del evento WordCamp Cantabria

Si no me equivoco, nadie por estos lares anunció el evento WordCamp Cantabria. Mi excusa es que cuando empecé a publicar ya no quedaban entradas y es que, a diferencia de muchos eventos, este no es de cuantos más mejor. Solo 200 entradas para que 200 participantes compartieran y aprendieran unos de otros.

Seguir leyendo en CantabriaTIC.