El tema de hoy es un problema de configuración de Postfix. Al configurar un servidor de correo, puedes llevarte la sorporesa de que se envían los correos al exterior bien, se reciben bien, puedes enviar un correo a alguien de tu mismo dominio, pero si pones dos destinatarios o más de tu propio dominio, el correo no llega a sus destinatarios.
Si haces un mailq, verás que la cola de correos tiene retenido ese correo con múltiples destinatarios de tu propio dominio, y no hay forma de que salga. Este comportamiento se debe a que en el archivo main.cf de Postfix, debes incluir esta línea, para que esos correos lleguen correctamente a sus destinatarios:

dovecot_destination_recipient_limit = 1

Listo. Simplemente con esta línea, esos correos llegarán correctamente. No olvides hacer un restart del servicio de Postfix para que coja el cambio en la configuración. Y si ves que la cola sigue sin moverse, haz un

postqueue -f

para forzar que los correos se vuelvan a intentar enviar.

Más

Hasta ahora las reglas de envío en las plataformas de comercio electrónico han sido muy simples, pero con el encarecimiento del combustible, es cierto que los clientes han empezado a necesitar y demandar cada vez reglas más complejas para que el envío gratuito sea una opción válida tanto para el comprador como para el vendedor.

En Magento 2, si bien hay algunas extensiones para la creación de reglas de envío, no teníamos una Free Shipping Bar o Barra para el aviso de envío gratis que se ajuste a esas reglas que se salen de lo simple, pero los chicos de WebbyTroops tienen la solución, y creo que es el producto que se ajusta mejor a día de hoy a las necesidades de casi cualquier empresa que tenga una plataforma Magento 2:

  • Make my Shipping Rule, extensión que te permite crear cualquier tipo de regla de envío, por compleja que sea
  • Free Shipping Bar extensión que complementa a Make my Shipping Rule y que te permite tener varias reglas para envío gratuito, e ir cambiando entre ellas

Desde Esencial Sistemas recomendamos estos dos productos como la solución más económica y completa para un problema difícil de solventar actualmente. Además, su soporte es muy bueno (en inglés) y os ayudarán en lo que necesitéis.

Más

Siguiendo la estela de los dos últimos artículos sobre securización de plataformas, en esta ocasión traemos un truco apuntado por uno de nuestros colaboradores, Fernando, que nos explica que para securizar la API de WordPress y evitar que la usen sin tener un acceso con usuario y contraseña, hay que añadir este filtro en functions.php del tema. De esta manera, podremos abrir nuestra API y usarla, pero no tendremos efectos indeseados por no tenerla securizada.
[crayon-62842e5f5cd41565754030/]

Más

Como decíamos en el artículo sobre ocultar la versión de la plataforma de Magento 2, una medida de seguridad básica en las plataformas Open Source es ocultar la versión de la misma, con el objeto de que no sea posible explotar sus vulnerabilidades. En WordPress esto se consigue de diversas maneras, desde el uso de un plugin, como Wordfence o similar, a insertar en el archivo de functions.php una instrucción como esta:

[crayon-62842e5f5db1c819147680/]

o una función como esta otra:

[crayon-62842e5f5db22671792239/]

En WordPress es muy sencillo ver la versión de nuestra plataforma, simplemente chequeando nuestro código fuente, o a través del feed de RSS, o incluso, leyendo el archivo readme.html por lo que es una plataforma especialmente sensible a los ataques por vulnerabilidades en cada versión.

Más

Una medida de seguridad básica en las plataformas Open Source es ocultar la versión de la misma, con el objeto de que no sea posible explotar sus vulnerabilidades. En Magento 2 conseguimos esto con una instrucción muy simple:
[crayon-62842e5f5dc5f577332850/]
Con esto conseguimos que si hacemos una llamada por navegador a
[crayon-62842e5f5dc64446607628/]
en lugar de devolvernos el número de versión de nuestro Magento 2, nos devuelva un error 404 en lugar de (por ejemplo)

Magento/2.4 (Community)

Más

Esto realmente es un bug que debería haberse corregido ya, pero que misteriosamente sigue vigente en Magento 2.4. Cuando al grabar tus datos como administrador, da este mensaje de error:

«Invalid header value detected»

es porque estás escribiendo en tu nombre y/o apellidos una vocal tildada o una ñ o algún carácter parecido. En muchos sitios te dirán que toques código, sobreescribas core de Magento… lo más fácil y que funciona a la primera es ir al archivo di.xml (en app/etc) y añadir esta regla:

[crayon-62842e5f5dd5a914591079/]

Más

Este no es un error tan común como parece, pero a la hora de desarrollar, puede ser algo fastidioso si te encuentras con él. Cuando en el momento de compilación, ésta se detiene y devuelve un mensaje parecido a este:

Errors during compilation:

Company\Extension\Model\Config\Structure\XXXX

Incompatible argument type: Required type: string. Actual type: array; File:

Y a continuación, indica el archivo donde se produce.
Lo mismo que pone Incompatible argument type: Required type: string. Actual type: array; File:, puede poner otros tipos. Lo importante en este caso es tener claro cuál es el tipo actual y el que debería estar.

La solución a este error es simple: editáis el archivo que nos indica, que tendrá un __construct. En él habrá unas líneas justo antes del __construct, que serán más o menos así:

/**

     * Constructor

     *

     * @param \Magento\Framework\Config\FileResolverInterface $fileResolver

     * @param Converter $converter

     * @param \Magento\Config\Model\Config\SchemaLocator $schemaLocator

     * @param \Magento\Framework\Config\ValidationStateInterface $validationState

     * @param CompilerInterface $compiler

     * @param \Magento\Framework\Module\Dir\Reader $dirReader

     * @param array $idAttributes

     * @param string $domDocumentClass

     * @param string $defaultScope

     */

Y después, aparecerá el constructor en sí

public function __construct(

        \Magento\Framework\Config\FileResolverInterface $fileResolver,

        \Magento\Config\Model\Config\Structure\Converter $converter,

        \Magento\Config\Model\Config\SchemaLocator $schemaLocator,

        \Magento\Framework\Config\ValidationStateInterface $validationState,

        CompilerInterface $compiler,

        \Magento\Framework\Module\Dir\Reader $dirReader,

        $fileName = ‘system.xml’,

        $idAttributes = [],

        $domDocumentClass = ‘Magento\Framework\Config\Dom’,

        $defaultScope = ‘global’

    )

En mi caso , faltaba la línea   * @param string $fileName, por lo que generaba ese error. Añadiéndola en el orden correcto, funciona todo. En otras ocasiones, el error está en que los tipos no son los correctos, poniendo que es una cadena cuando lo que recibe es  un array, así que este tipo de mensaje se debe corregir observando primero

/**
* Constructor
*
* @param \Magento\Framework\Config\FileResolverInterface $fileResolver
* @param Converter $converter
* @param \Magento\Config\Model\Config\SchemaLocator $schemaLocator
* @param \Magento\Framework\Config\ValidationStateInterface $validationState
* @param CompilerInterface $compiler
* @param \Magento\Framework\Module\Dir\Reader $dirReader
* @param string $fileName
* @param array $idAttributes
* @param string $domDocumentClass
* @param string $defaultScope
*/

y después, contrastándolo con la información que tenemos en

public function __construct(
\Magento\Framework\Config\FileResolverInterface $fileResolver,
\Magento\Config\Model\Config\Structure\Converter $converter,
\Magento\Config\Model\Config\SchemaLocator $schemaLocator,
\Magento\Framework\Config\ValidationStateInterface $validationState,
CompilerInterface $compiler,
\Magento\Framework\Module\Dir\Reader $dirReader,
$fileName = ‘system.xml’,
$idAttributes = [],
$domDocumentClass = ‘Magento\Framework\Config\Dom’,
$defaultScope = ‘global’
)

Más

Vamos a realizar una serie de artículos breves donde iremos explicando por qué se generan algunos errores en Magento 2 y cómo corregirlos. Por ejemplo, hemos migrado de un servidor a otro y al intentar entrar en la página, nos encontramos con este error
[crayon-62842e5f5de5b618022758/]
La solución más inmediata es ir a la carpeta generated/metadata y borrar el archivo global.php, pero este error indica otro problema: seguramente no tengamos los permisos de los archivos y carpetas correctamente puestos, y el sistema sea incapaz de generar los archivos para mostrar la web. Lo que nos indica este error es que debemos revisar el grupo y usuario propietarios de los archivos y directorios, porque el sistema es incapaz de actuar sobre ellos. Lo normal es tenerlos a www-data:www-data, y con unos permisos de 775 para carpetas y 664 para archivos, pero depende también de la configuración del servidor. En cualquier caso, este error señala más allá del borrado de global.php.

 

Más

Os dejo aquí el PDF que puse en charla sobre Seguridad en comercios electrónicos de C0r0n4con Christmas Edition 2020. Si tenéis alguna duda, no dudéis en poneros en contacto a través de la página de contacto, o en RRSS y os responderemos a la máxima brevedad.
Descarga el archivo «Seguridad en ecommerce. C0r0n4con 2020»

Más

Hemos actualizado recientemente unas cuantas plataformas de Mautic, de la versión 2 a la 3, y en todas ha terminado pasando lo mismo: necesitaba actualizarse por línea de comandos, y hemos tenido que forzarla, es decir, actualizar la base de datos por un lado y el código por otro, lanzando para ello varias veces upgrade_v3.php –ignore-warnings y limpiando entre uno y otro la caché mediante línea de comandos, y restaurando permisos en las carpetas y archivos.
Si estáis en esta tesitura, os recomiendo que miréis antes de desesperaros el archivo de errores que está en var/logs del propio Mautic, y os dará una pista de qué le está ocurriendo.
Por otro lado, una vez habéis conseguido pasar a la versión 3, os recomiendo que sigáis actualizando (ya estas versiones sí pueden actualizarse a través de la plataforma, sin necesidad de usar la línea de comandos), ya que la última versión corrige muchos pequeños errores de la versión 3.0 y 3.1.
Por último, comentaros que si al entrar en el panel de configuración de Mautic e intentar aplicar los cambios, os devuelve un error como este:
mautic.core.update.archive_no_such_file
La solución es muy simple: id a var/cache y veréis que el directorio prod no tenga los permisos, o usuario o grupo correcto. Corregidlo y todo irá bien.

Más

En este blog no somos de realizar largos y sesudos artículos, no obstante, en este caso es necesario explicar un proceso largo y nada intuitivo, por lo que se impone romper con nuestras reglas y hacer un tutorial extenso, que ayude con un proceso no muy documentado aún.

Hasta principios de 2020, había un procedimiento para descargar y actualizar las bases de datos de GeoLite y GeoIP para Mautic, pero por un cambio en la política de envío de datos de la empresa que mantiene estos datos (Maxmind), ahora debemos realizar unos pasos distintos a los que te explican en la mayoría de las webs del mercado, así que si estás siguiendo algún tutorial y no te funciona, no desesperes, no estará actualizado (mira la fecha del artículo, seguramente será de antes de principios de 2020).

¿Cómo debemos proceder a partir de 2020?

Primero crearemos una cuenta gratuita en Maxmind para descargar GeoLite2. Para este paso, usaremos este enlace:
https://www.maxmind.com/en/geolite2/signup

Una vez que hayas rellenado el formulario, recibirás un correo electrónico de Maxmind, (mira en la carpeta de SPAM si no lo encuentras), y haremos clic en el enlace para crear una contraseña. (Donde pone «first create a password here»). No uses otros enlaces, porque no funcionarán. Una vez creada la contraseña, lógate con ella y busca en el menú de la izquierda el elemento «My License Key». Ahí tendrás un botón para generar la clave de licencia («Generate new license key»). Haz clic en él y sigue los pasos que te indica (poner un nombre a la clave que estás generando) y marca la opción «Generate a licensekey and config file for use with geoipupdate version 3.1.1 or newer». Hacemos clic en «Confirm». Al hacer esto, nos mostrará una vez la clave y el ID de usuario, por lo que deberemos guardar estos datos para poderlos usar después.

Hacemos clic en el botón de «Download Config» y guardamos este archivo también. Lo necesitaremos en el servidor donde tenemos Mautic.
A continuación necesitamos entrar por una terminal al servidor y ejecutar (comandos para Ubuntu):
add-apt-repository ppa:maxmind/ppa

apt update
apt upgrade

apt install geoipupdate
Con estas instrucciones, insertaremos el repositorio en nuestro servidor e instalaremos geoipupdate.

Para poder ejecutar a continuación el script descargado, necesitaremos poner el contenido del archivo .conf que nos descargamos anteriormente en el directorio etc/ del script instalado, en el archivo que se llama GeiIP.conf.*

Llegados a este punto, ya tenemos el script funcionando en nuestro servidor. Ahora tenemos que poder actualizarlo. Para ello, por un lado debemos unir Mautic con lo instalado en el servidor, y por otro, lanzarlo como proceso cron. Vamos a ello.

Lo que primero debemos hacer es irnos al directorio donde está Mautic instalado, y comprobar que existe app/cache/ip_data. Si no existiera, creamos esa ruta, y le damos permisos 775.

Ejecutamos a continuación:
sudo -u daemon geoipupdate -f /etc/GeoIP.conf -d /ruta/de/mautic/app/cache/ip_data -v
Al poner -v (verbose), nos devolverá información sobre el proceso y el resultado del script. Con esto, Mautic ya deberá poder leer la base de datos que intentábamos tener actualizada. Vamos ya por el último punto: ejecutamos crontab -e e insertamos

0 0 * * * sudo -u daemon geoipupdate -f /etc/GeoIP.conf -d /ruta/de/mautic/app/cache/ip_data

Y con esto, todos los días a las 0:00 se ejecutará esta línea, actualizando GeoIP. Y ya está. No tocaremos nada en Mautic, más allá de indicar la ruta de la base de datos, si no es la correcta. Pero no intentaremos actualizarla a través de Mautic, ya que este proceso ya es independiente de Mautic.

*NOTA: para sistemas no Ubuntu, este archivo .conf puede estar en una ruta distinta a /etc. Para averiguarlo, bastará con ejecutar geoipupdate -v y nos mostrará la ruta que buscamos.

Más

Has montado Mautic en un servidor limpio, lo has probado y funciona todo. Estás configurando el correo electrónico, haces la comprobación de conexión, todo va bien. Pero es llegar al envío de prueba del correo, y se queda eternamente pensando, hasta llegar a un error 503 del servidor.
Este error, unido a los mensajes que devuelve el archivo de log del servidor, pueden llevarte a dar vueltas inútilmente.
Por otro lado, el log del propio Mautic (en app/logs), tampoco te va a ayudar mucho:

[crayon-62842e5f5df54562335443/]

Realmente este problema lo que está indicando es que muy probablemente tengas que instalar el paquete PHP-Imap. Dependiendo de si usas CentOS o Ubuntu, la instalación puede variar un poco, esto mejor lo buscas según sea tu distro. Y al terminar de instalarlo, recuerda reiniciar Apache (o Nginx) y PHP-FPM si lo estás utilizando.

Más

El ataque a plataformas de WordPress por este tipo de malware ha saltado de forma masiva a principios de septiembre de 2.020. se caracteriza por insertar un código en JavaScript al principio de ciertos archivos de la web y artículos en la base de datos, de manera que la web hackeada redirecciona el tráfico que le llega y lo lleva a una serie de webs ajenas a la web hackeada.

¿Cómo logra penetrar en el sistema?

En principio parece que aprovecha una vulnerabilidad de un plugin, File Manager, aunque esa vulnerabilidad puede estar presente en otros plugins.

¿Cómo lo quito del sistema?

Si tiene una copia de seguridad de antes del ataque, restáurela, instale todas las actualizaciones que necesite el sistema y desinstale aquellos plugins discontinuados y los que sirvan para administrar los archivos de WordPress (sus nombres pueden ser File Manager o similar).
Si no tiene copia, o ésta está infectada también, o la copia no es lo suficientemente actualizada, entonces puede hacer una de estas dos cosas:

1.- Armarse de paciencia y empezar a limpiar código malicioso de la siguiente forma:

Localizar los archivos insertados en el sistema para infectarlo

En el directorio de wp-content/uploads/ habrá probablemente un archivo llamado _lte o lte_ o similar. Y algún archivo que aparentemente sea de WordPress, porque su nombre comenzará por wp- y tendrá extensión .php. Hay que borrarlos. También habría que localizar en el directorio raíz algún archivo añadido a los propios de WordPress.

Limpiar el código

Lo más cómodo es sustituir los directorios w-admin y wp-include de una versión limpia de WordPress que se localice en la web oficial de WordPress. Después se localizarán los archivos modificados recientemente (una técnica fiable para saber cuándo se produjo el ataque es mirar la fecha y hora de index.php, y a partir de ahí, buscar los archivos .js y .php modificados en esa fecha y hora).

Archivos PHP

Una vez localizados los archivos .php modificados, se sustituirá la cadena insertada antes del primer ««. La cadena que encontramos nosotros inicialmente era
aunque la URL puede cambiar.

Archivos JS

En este caso, puede ser que la cadena a insertar sea parecida a esta cadena:


Limpiar la base de datos

Hay que descargar un backup de la tabla de posts y buscar la cadena que hemos visto anteriormente en los archivos .php insertadas, y borrarlas. Después se vuelcan estas líneas modificadas de nuevo con un replace, de forma que todas las líneas quedan sin el script insertado.

2.- O hacer las cosas un poco más rápidas.

Esto sólo puede hacerse sólo si no se han modificado ni plugins ni plantilla, o bien se tienen los códigos originales de lo modificado:

Localizar la cadena insertada mirando el index.php en el directorio raíz.
Limpiar la tabla de posts la base de datos

, como se explica en el apartado anterior y extraer un backup completo.

Realizar una lista de los plugins y la plantilla que tiene instalada

Y si hay un tema hijo, se deberá tener o bien un backup válido o bien, habrá que limpiar el código del tema hijo, como se explica en el punto anterior «Limpiar código»

Limpiar el directorio de imágenes

Haremos un backup de wp-content/uploads y se buscará el archivo _lte o similar para borrarlo, junto con el archivo que comience por wp- en ese directorio, y que no sea propio de WordPress

Borrar la web

Excepto wp-config.php, wp-content/uploads/* y volver a instalar WordPress y los plugins

Si tiene una web hackeada y no sabe recuperarla, podemos ayudarle.

Más

Hace unos años escribimos un artículo sobre cómo generar un archivo DOCX desde el contenido de una página web que podéis consultar en este enlace.

Ahora explicamos cómo imprimir por ejemplo el resultado de una búsqueda específica que hayamos programado en WordPress. En este caso, hicimos un buscador personalizado para un modelo de datos definido con ACF que necesitaba, y al realizar las búsquedas, el cliente quería poder extraer esos datos en listados que obtenía resultado de las búsquedas, con los campos personalizados tal y como se devolvían en la página, con un orden y una agrupación específicos, cosa que los plugins que conocíamos de WordPress no permitían.

Para ello, en la página en la que construíamos el listado hemos insertado un formulario con campos ocultos con un botón visible con el que enviamos la información en html exáctamente que queríamos listar en DOCX. Al hacer clic, ese botón enviará la información a un archivo como el del enlace anterior, en el que se recibe todo el HTML, creando el archivo DOCX con el listado, y simplemente añadimos un poco de estilo para poder mostrar el listado con el mismo diseño.

El código necesario para hacer todo esto es sencillo:

En el archivo donde está el resultado de la búsqueda, creamos:
[crayon-62842e5f5e03c527516084/]
y el archivo que genera el DOCX:
[crayon-62842e5f5e040603650971/]
 

Más
Esta web utiliza cookies propias para su correcto funcionamiento. Puede consultar nuestra política de cookies, política de privacidad y aviso legal. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información    Configurar y más información
Privacidad