Channel2rss ha tenido algunas mejoras hasta el momento de registro de 22 de octubre de 2025
Introducción
Aprovechando Channel2RSS como herramienta de estudio, he estado investigando como funciona el despliegue de software basado en PHP en la actualidad. No he completado grandes proyectos en este lenguaje y lo que recuerdo es tan primitivo como para que el código que me enseñaron en la universidad se parezca a esto:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | <?php $titulo = "spagguetti code"; $cuerpo = "loremp ipsum"; ?> <html> <head> <title><?php echo $titulo; ?></title> </head> <body> <h1> <?php echo $titulo; ?> </h1> <p> El código de PHP se incrustaba directamente en el código de HTML causando gran confusión por mezclar código. </p> <p> <?php echo $cuerpo; ?> </p> </body> </html> |
Así que estuve investigando nuevas formas de mantener la seguridad del código sin aumentar la complejidad del mismo.
El problema que tenia era que estaba acostumbrado al modelo de «Hosting Compartido» que permite solo subir los archivos PHP al directorio publico sin mayores pretensiones. Imagino que ahora eso ha cambiado, pero en principio, fue la razón por la que comencé a estudiar NodeJS pues la lógica no se encuentra en publico, sino que esta es la que decide que es publico o no.
Esto era así incluso hasta la época de Codeigniter 2.x que fue el ultimo que utilice y que abandoné cuando en su cambio a 3.0 luego de la muerte de su creador, ya funcionaba como Laravel, necesitando un interprete que sirva los contenidos según la nueva estructura de seguridad.
Composer
He empezado a usar Composer bajo la excusa de utilizar una herramienta como PHPMailer, así que, como este crea una carpeta llamada Vendor, considere que la estructura de archivos del momento, representaba un riesgo de seguridad innecesario. Hasta el momento había protegido el archivo de base de datos con reglas de nginx, pero esto hace que sea poco portable el código y en realidad, peligroso, pues puede filtrarse información sensible ante los random que andan dando vueltas con sus escaneres de vulnerabilidades todo el dia por internet.
Estructura de seguridad en archivos
Actualmente tengo control del servidor donde alojo mi proyecto, por lo que ya puedo decidir que es publico y que no lo es. Desconozco si esto es posible en los Hosting Compartidos actuales o si hay un método mediante .htaccess que permite lograrlo sin modificar el vhost, pero con esto ya puedo decidir una estructura que no haga públicos los archivos que deben ser privados, incluido el .env
Sigo actualmente esta estructura de directorio:
- 📂config (En un principio iba a usar un config.php, pero ya no)*
- 📂public
- 📂cache
- 📄archivo.xml
- 📂public
- 📂codigo_canal
- 📄imagen.jpg
- 📄feed.xml
- 📂codigo_canal
- 📄index.php *
- 📄suscripcion.php
- 📄desuscripcion.php
- 📄webhook.php
- 📂cache
- 📂src
- 📂vendor
- 📄.env
- 📄database.db
- 📄composer.json
- 📄composer.lock
- 📄webhook.log
* ¿Por qué se debe separar del código?La separación de la configuración del código ofrece varias ventajas:
- Portabilidad: Permite desplegar el mismo código en diferentes entornos (por ejemplo, desarrollo, pruebas y producción) sin necesidad de modificar el código.
- Seguridad: Evita que la información sensible, como contraseñas y claves de API, quede expuesta en el repositorio de código.
- Escalabilidad: Simplifica la gestión de configuraciones a medida que el número de despliegues de la aplicación aumenta, evitando combinaciones complejas de configuraciones.
- Mantenimiento: Facilita la comprensión y mantenimiento del código, ya que las configuraciones se gestionan de forma independiente y no se mezclan con la lógica de la aplicación.
¿Cómo se debe almacenar la configuración?
La metodología recomienda almacenar la configuración en variables de entorno. Este enfoque garantiza que la configuración sea independiente del lenguaje de programación y del sistema operativo, y proporciona un mecanismo seguro para inyectar las configuraciones en la aplicación durante la fase de ejecución.
Seguridad general
Tener organizado los archivos de esta manera permite detectar también los comportamientos extraños desde el log de nginx, el cual también recomiendo segmentar por Vhost si así lo usas. Actualmente no he promocionado por ningún lado la URL de este servicio, por lo que no debería llegar nadie, aun así, el trafico total ya llega casi al mega en el poco tiempo que tiene el nuevo log segmentado. También me llama la atención algunas URL mal formadas que pueden insinuar tanteos para probar la seguridad del sistema.
También es interesante notar la enorme cantidad de Crawlers que llegan. Es interesante que la mayoría del trafico es de Crawlers, pero también es interesante que alguien con Brave ha visitado el sitio 8 veces y al menos 1 vez fue visitada por un navegador safari.
Archivos de configuración
Siguiendo los principios de The Twelve-Factor App, una guia creada por los dueños de Heroku para el despliegue de SaaS (Software as Service o software como servicio), he cambiado la forma en la que se utilizan las variables de configuración, que en principio estaba hardcodeadas directo en el codigo y luego guardadas en config/config.php, pero ahora he separado la configuracion del codigo con el popular .env, que tanto buscan los crawlers por la red.
¿Por que lo buscan tanto? Bueno, eso es fácil, allí están contraseñas, usuarios y mas información importante que sin duda alguna te ahorraran muchas molestias como ciberdelincuente. Y esto es llamativo puesto que al ser algo muy importante debería estar oculto, pero como mencioné antes, lo normal en proyectos PHP era solo tirar todo en la carpeta publica y darte por servido tras llenar las variables que se requerían.
Por esa razón, en este proyecto ahora solo la carpeta /public es servida por Nginx, aunque la carpeta del proyecto siga en el directorio común. De esta manera, solo los archivos mas importantes dan la cara al publico, pero el acceso físico de los mismos sigue siendo posible con rutas relativas.
Las Newsletters
Esta es una nueva función experimental del bot. Para crearla, solo agregué dos archivos PHP, uno de suscripción y otro de descripción, ademas de dos plantillas HTML para los correos en cada acción. Al igual que el archivo RSS se actualiza al instante en cada publicación, también se enviará un correo electrónico apenas el canal publique. Esto es algo interesante por cuanto es posible estar al día con las novedades casi al instante, pero también puede llegar a ser abrumador. La función de desuscripcion se hace mediante un enlace mágico, el cual se encarga de eliminar el registro del usuario para que deje de recibir correos apenas se desuscriba. En lo posible, deseo guardar los mínimos datos que pueda, así que la fila seleccionada se borra con DELETE, pero eso hace que el usuario suscrito pueda ser suscrito casi a la fuerza. No se me ocurre una idea para evitar esto, pero en una próxima actualización podría estar agregando el borrado lógico de suscripción, que mediante un cambio de estado, la persona suscrita puede evitar permanentemente que se le sigan enviando novedades.
El fin de la vista lectura
No sabria si llamarle «fin» puesto que solo lo movi para poder corregir algunas cosas, aunque no estoy muy motivado a ello. Dado que el objetivo principal son los RSS, esto ya esta completado, mientras que al agregar los Newsletter, hacen menos necesario que exista un modo lectura de los canales.
He removido esta vista porque no la veo necesaria, pero si hiciera falta, la podria volver a incorporar. Hasta el momento, debido a que no ha sido publicitado, no tuvo ninguna vista humana, pero si una horrible cantidad de crawlers intentando descubrir vulnerabilidades. Mejor evito riesgos quitando una funcion que probablemente no le vaya a prestar mucha atencion.
Mejoras
Hace falta una opción de apagado de suscripcion. Tengo ideas de como se puede usar para mal las suscripciones que no comentaré por esta via, pero apenas vea comportamientos abusivos, es posible que la deshabilite.
Los bots de botoneras pueden llegar a ser muy molestos. No se todavia como filtrarlos, tampoco se si sea buena idea simplemente dejar de oir lo que miembros no humanos del canal digan, pero en algunas pruebas el contenido de botoneras puede superar al contenido humano, convirtiendo esto en un nido de SPAM
Algunos canales pueden tener una tasa de publicación muy alta. Estaba pensando que tal vez sea mejor hacer un resumen semanal o simplemente acumular todos los post para que se publiquen una vez a la semana. La verdad no tengo idea que camino seguir, puesto que quiero guardar la mínima cantidad de información sobre los usuarios. si los lectores tuvieran la opción de configurar sus preferencias, probablemente tendría que hacer un sistema de login y pos no.
Hay un bug de URL en los archivos de audio. No lo corregí por pereza. Luego revisaré.
Curiosidades
El archivo del modo lectura read.php tiene un problema raro y una de las razones por las que lo he quitado. Por alguna razon, cada que lo edito, sea desde mi compu en casa como en el server directo, puede darse el caso de que los cambios que hagan corrompa el archivo. Por ejemplo, si edito una linea y la dejo bien, al guardar puede que la siguiente linea se incruste en la anterior, dañando todo obviamente.
Algo mas
He configurado mi correo siguiendo las reglas DKIM y SPF actualizadas, tratando de que las grandes empresas no me marcen mis correos como SPAM, o que al menos llegue a la bandeja de SPAM, pero solo lo he probado con mi correo, así que no se si pasara esos filtros. Si no llegan los mensajes, revisa tu bandeja de spam, y marcalo como no spam. Si no funciona, ya revisare que pasa.
Changelog
22 de octubre de 2025
- Creada pagina suscripción
- Agregada la opción newsletter en index.php
- Correcciones de url relativa (eliminadas url absolutas)
- Creación de tabla suscripciones_canales
- Creada la plantilla de envío de correos
- Agregado soporte para composer
- Agregada la librería phpmailer
- Corrección de navegación: El Nombre de la pagina lleva a la pagina de inicio
- Correcciones varias para seguridad
- Se rompió la pagina de read.php funciona parcialmente, no aparece la descripción.
- Me cansé. a la porra la pagina de «read.php». sigo teniendo problemas de que los cambios que hago con ese archivo, se borran o se desplazan
- Agregado este changelog al index y preparado el de la pagina interlan
- Correcciones en la semántica del sitio
- Reestructuración del directorio del proyecto
- Agregadas variables de entorno
- Agregadas opciones de configuración rápidas
TODO
- Apagado de suscripción lógico (el usuario puede pedir que no se le suscriba mas)
- ¿Resumen semanal para no saturar la bandeja de entrada?
- Hacer el sistema para desuscribirse (no te preocupes, me escribes a info@interlan.ec y me encargo de borrarte si no quieres recibir correos hasta que haga el sistema automatico)
- Por alguna razón los archivos de audio en el correo no enlazan al dominio correcto
- Es muy probable que los bots de botoneras y similares se vuelvan muy, muy hostiles con el usuario, especialmente si el dueño del canal deja de publicar, siendo que llenarían la bandeja de entrada de los suscriptores con mucho y muy horrible spam. ¿Debería bloquear la publicación de post desde bots?
Curiosidades
- El archivo read.php se corrompe regularmente. se agregan espacios o directamente se sobrescribe el archivo. no tengo idea de la causa
