Píldoras PrestaShop de agosto de 2024: cabeceras, Odoo y facturas
Las ideas sueltas de agosto de 2024 en @PrestashopEsp: código oculto de una extensión en las descripciones, cuándo generar la factura, cabeceras de seguridad con cuidado con la CSP y por qué desactivar un módulo vulnerable no basta.
Lo que dejó agosto de 2024 en el grupo y no daba para un artículo entero: seguridad, facturas, una copia local que se escapa y un par de consejos de marketing.
Iframes de una extensión del navegador escondidos en las descripciones
Gustavo encontró en las descripciones de los productos de un cliente varios iframe ocultos que apuntaban a chrome-extension:// y a un fichero tpc.html. No se veían en la tienda, solo en el código, y volvían a aparecer después de quitarlos. Otros miembros del grupo vieron que la ruta corresponde a una extensión de Chrome para compartir contenido; Gustavo sospechaba de algún conector o servicio externo con acceso a la base de datos. Lo que hizo: buscar tpc.html en toda la base de datos desde phpMyAdmin para ver cuántos productos estaban afectados, limpiarlos y cambiar la contraseña de la base de datos, y el código dejó de añadirse. Antes de limpiar con SQL, haz copia.
Para empezar a vender más: una campaña de Shopping sencilla
Rekire abrió un debate sobre qué acciones de marketing funcionan en una pequeña empresa en la que el jefe hace de todo. La respuesta de Gustavo fue concreta: empezar siempre por una campaña de Shopping sencilla, configurada lo justo. Si funciona, buscar entonces a alguien que la configure y la controle bien. Otro compañero añadió que todo depende del público, porque cada uno se trabaja de forma distinta y en canales distintos. Y Rekire dejó una advertencia: la publicidad en redes, si no la controlas, no compensa.
¿Factura al cobrar o al enviar?
Un compañero que iba a dar unos días al cliente para modificar su pedido antes del envío se planteó cuándo generar la factura. Gustavo explicó lo que aconseja a sus clientes: que la factura se genere al pasar el pedido a «Enviado» y no al aceptar el pago, para no tener que hacer rectificativas por cada cancelación. Él mismo reconoció que no sabía si eso encaja con la normativa o si debe hacerse al cobrar. En PrestaShop se decide en la configuración de los estados de pedido. Antes de cambiarlo, consulta el criterio con tu gestor.
Un checkout con menos campos choca con las direcciones de PrestaShop
Un compañero quería que en el checkout solo se pidieran nombre, correo y dirección. El problema, explicó Rekire, es que PrestaShop no deja crear una dirección sin ciertos campos obligatorios, y ocultarlos a mano en las plantillas se pierde al actualizar. Su módulo de registro ampliado lo resuelve creando la dirección de verdad y guardando en los campos obligatorios que no pidas el valor por defecto que tú configures. Avisó de un límite: si el cliente añade una segunda dirección, PrestaShop puede volver a pedir el resto de datos.
La copia local te manda a la web real
Un compañero montó una copia de su tienda 1.7.8 en su ordenador: cambió el dominio en la configuración y en la tabla de URL de la tienda, borró la caché y regeneró el .htaccess. El back-office abría, pero «Ver tienda» le llevaba a la web en producción. Gustavo le pidió revisar app/config/parameters.php: si sigue apuntando a la base de datos del servidor, la copia lee la configuración real y redirige allí. Además de los dominios, comprueba siempre a qué base de datos está conectada la copia. Una copia conectada a la base real también escribe en ella.
La factura de Odoo, directa desde Mi cuenta
Si facturas con Odoo y no con PrestaShop, Gustavo explicó cómo lo resuelve: Odoo genera una URL de descarga del PDF de cada factura protegida con un token de acceso, y él la muestra en «Mi cuenta» de PrestaShop. El cliente no tiene que registrarse en Odoo, el PDF no se guarda en ningún sitio intermedio y el token se puede regenerar cada vez que el cliente visita la página. La URL tiene la forma /my/invoices/ID?report_type=pdf&download=true&access_token=TOKEN. Sin el token, nadie debería poder bajar la factura de otro.
Cabeceras de seguridad en el .htaccess, con cuidado con la CSP
Un compañero compartió un bloque de cabeceras de seguridad para el .htaccess: HSTS para forzar HTTPS, X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN contra el clickjacking y una política de Referrer-Policy. Su consejo: definirlas en la web y no solo en el servidor, para que no se pierdan al migrar. Un aviso nuestro: el bloque incluía Content-Security-Policy: default-src 'self', que en una tienda bloquea pasarelas de pago, analítica, fuentes y chats externos. Empieza con Content-Security-Policy-Report-Only, mira qué se bloquearía y ve ampliando la lista.
Las hojas de reclamaciones se las puede llevar el cliente
Una duda práctica para quien tiene también tienda física: ¿el cliente tiene que rellenar la hoja de reclamaciones en el local o se la puede llevar? Rekire contestó que se la puede llevar y traerla después, y que no tienes que firmar su copia hasta que te la entregue rellena. El juego tiene tres copias: una para la empresa y dos para el cliente, que presentará una en consumo. Los modelos y los plazos dependen de cada comunidad autónoma, así que revisa los de la tuya.
Un módulo vulnerable sigue siéndolo aunque esté desactivado
Un compañero preguntó si bastaba con desactivar un módulo con una vulnerabilidad conocida y activarlo solo cuando lo necesitara. La respuesta fue que no. Rekire explicó que, aunque esté desactivado o desinstalado, si sus ficheros siguen en el servidor lo más probable es que la vulnerabilidad siga ahí, y recordó un módulo de carritos abandonados que, hace años, servía para infectar tiendas aunque estuviera desinstalado. Gustavo lo resumió: en ese caso, hay que eliminarlo.
Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación