Symfony 5: Paso 16

16.3 Diseñando una clase verificadora de spam

16.6 Comprobando comentarios en busca de spam

Seguimos comentando y haciendo nuestras modestas acotaciones al caso desarrollado por Fabien Potencier en su libro «Symfony 5: La Vía Rápida» edición en español (versión original en inglés v1.0.14, versión de la traducción: v1.0.12)

Aclaración importante del 31/08/2020: Hoy he llegado al Paso 19, y veo que allí Potencier desarrolla con profundidad, varias de las carencias de este capítulo 16. Pero en este Paso 16, nunca aclaró que se perfeccionaría con el Paso 19.

Abordaremos en conjunto los dos pasos, 16.3 y 16.6, porque van encadenados, uno depende del otro. Hubiera quedado más claro en el libro, desde el punto de vista didáctico, poner uno a continuación del otro.

El punto 16.3 se desarrolla en las páginas 164 y 165 del libro. Tal como está escrito el código se pueden recibir 3 valores de respuesta y se resumen en la página 165:

Si el valor de respuesta es 0: El comentario no es spam (ham).
Si el valor es 1: El comentario podría ser considerado spam (En realidad para Akismet es Spam, pero lo deja a consideración final del administrador del sitio).
Si el valor es 2: Estaríamos en un caso de un comentario que entraría en la categoría de flagrante spam (blatant spam) y sería directamente rechazado, y no grabado en la tabla de comentarios para consideración del administrador .

Sin embargo la información que recogemos en el sitio de Akismet, plantea que la API devuelve solo dos valores: (1) verdadero, cuando hay spam con alta probabilidad , o (0) falso (ham), cuando podemos considerar con alta probabilidad que el comentario enviado no es un spam. Se puede ver la explicación con más detalle en el sitio Askimet, más precisamente aquí:

https://akismet.com/development/api/#comment-check

Tambien puede leerse con provecho este link relacionado en el sitio de Akismet:

There’s a Ninja in Your Akismet

¿De donde saca Potencier 3 valores (0, 1 y 2)?

Lo que en realidad sucede, es que Akismet, es capaz de enviar, al menos, tres tipos de respuestas. Dos se engloban en la categoría de spam, y una en la categoria de no spam.

Las dos subcategorías de spam (podría ser spam y blatant spam), responden a variables distintas, y así está explicado en la página de Akismet cuyo link está citado arriba. Esas variables diferentes, son las que aprovecha Potencier para distinguir dos valores posibles para el spam.

Veámoslo un poco más en detalle. Abajo una capturadel código de la clase SpamChecker, del código de Potencier tal como está en su libro (pp. 164-165):

El tip que Potencier propone inmediatamente abajo de la enumeración de los tres resultados posibles, en la página 165, no funciona si no instalamos:

symfony composer req symfony/mime

Por cierto, desde el punto de vista didáctico, el tip está mal ubicado, ya que dicho tip debería estar al final del punto 16.6, donde recién se puede probar. De todas maneras, con ese tip no podemos probar si el código funciona cuando se devuelve el valor 2 en la función getSpamScore. El caso con valor 2, nunca se daría escribiendo solo la dirección de mail de prueba de spam como akismet-guaranteed-spam@example.com, ya que como dijimos, Akismet devuelve solo dos valores y nosotros esperamos probar tres valores. Según la lógica de Potencier, solo en el caso que la función getSpamScore reciba de Akismet la respuesta que genera el valor 2, el mensaje será rechazado, mientras que si da el valor 1, el mensaje igual es «aprobado» y no existe nada en la lógica de la función show en el archivo ConferenceController.php que advierta al administrador que se encuentra frente a un posible spam (valor 1: maybe spam) . Pero incluso si se diera el valor 2, como respuesta, no hay como probarlo en la etapa de desarrollo, así como está el código y con la dirección de prueba akismet-guaranteed-spam@example.com nunca tendríamos el caso de un valor igual a 2. No nos queda otra posibilidad que forzar a la función show para asumir el valor 2, y luego ver la respuesta del código escrito. Cuando hacemos que se ejecute el código en página 168 pero forzando a que se cumpla la identidad que está dentro del if (2 === $spamChecker->getSpamScore($comment, $context)) { throw new \RuntimeException (‘Blatant spam, go away!’)} Obtenemos una página como la siguiente, nada elegante por cierto, aunque quizás un spammer se la merezca:

Pero no cuesta mucho un mensaje más prolijo con este código, por ejemplo:

Que nos lleva a esta pantalla:

Pero aún tenemos más para decir. Si el valor que devuelve la función getSpamScore fuera 1, le podríamos facilitar el trabajo al administrador, cambiando el valor por defecto del estado del mensaje que es ‘submitted’, a un valor como por ejemplo: ‘may be spam’ Codificando, podría ser algo como lo que muestra el recuadro en rojo:

El resultado del cambio del código, se refleja en la lista de comentarios, donde ahora el comentario sospechoso de ser spam, está idetificado claramente en su columna de estado (State) como ‘may be spam’: