Parche de seguridad SUPEE-9767 - ¿Posibles problemas?

108

Un nuevo parche de seguridad está disponible para Magento 1, que aborda 16 problemas de APPSEC: https://magento.com/security/patches/supee-9767

Siete de las vulnerabilidades tienen una puntuación de 8.0 o superior para CVSSv3 Severity , y están siendo explotadas en la naturaleza, por lo que este es un parche crítico. Los sitios pueden aplicar SUPEE-9767 o actualizar a la nueva versión CE 1.9.3.3 / EE 1.14.3.3.

¿Cuáles son los problemas comunes o las dificultades a tener en cuenta al aplicar SUPEE-9767?


ACTUALIZACIÓN 2017-07-12:

Magento ha lanzado SUPEE-9767 V2 y CE 1.9.3.4 para abordar muchos de los problemas del parche inicial. Si aplicó V1, debe revertir y luego aplicar V2. Si aún no ha parcheado, simplemente aplique V2, y la mayoría de los problemas mencionados aquí no serán relevantes.

Ryan Hoerr
fuente
"Siete de las vulnerabilidades tienen un puntaje de 8.0 o superior para CVSSv3 Severity, y están siendo explotadas en la naturaleza, por lo que este es un parche crítico". Solo quería comprobar, ¿el "atacante" necesita ingresar al administrador para realizar alguna de estas vulnerabilidades?
PaddyD
3
sí, debe tener acceso de administrador para explotar ...
MagenX
Sin embargo, el parche no parece detener el punto final común de fuerza bruta (es decir, / rss / order / new), que parece ser la forma más común en que los botters intentan acceder a las áreas de administración.
Ricky Odin Matthews
1
Lo uso para RSS @RickyOdinMatthews en .htaccess RewriteRule ^/?(index.phprss|index.php/rss/catalog|index.php/rss/order|rss/catalog|rss/order).*$ /no-route [R=301,L,NC]
Richard Feraro
@ RichardFeraro Yo uso nginx, pero ya uso una solución similar. Sin embargo, he notado que los robots suelen buscar y forzar estos puntos finales por fuerza bruta.
Ricky Odin Matthews

Respuestas:

107

Aquí está mi descripción general del parche después de profundizar en él

AHORRO DE TIEMPO : Experius proporciona un asistente de parches que lo ayuda a encontrar los archivos en temas personalizados, módulos personalizados o sobrescrituras locales que también pueden necesitar ser parcheados manualmente , puede encontrarlo aquí: https://github.com/experius/Magento- 1-Experius-Patch-Helper # magento

Teclas de formulario de pago

Como se dijo en la otra publicación, este parche agrega claves de formulario a los siguientes formularios:

Forma del carrito de envío:

app/design/frontend/<package>/<theme>/template/checkout/cart/shipping.phtml

Formulario de pago de facturación en varios puntos:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/billing.phtml

Formulario de pago y envío de envío múltiple:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/shipping.phtml

Formulario de pago de direcciones de multipunto:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/addresses.phtml

Formulario de pago de facturación:

app/design/frontend/<package>/<theme>/template/checkout/onepage/billing.phtml

Forma de pago del envío:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping.phtml

Formulario de pago:

app/design/frontend/<package>/<theme>/template/checkout/onepage/payment.phtml

Forma de pago y envío:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping_method.phtml

Formulario de pago de facturación persistente:

app/design/frontend/<package>/<theme>/template/persistent/checkout/onepage/billing.phtml

Además de eso, los siguientes archivos JS se han actualizado para que sean compatibles con ese cambio:

  • js/varien/payment.js
  • skin/frontend/base/default/js/opcheckout.js

Qué hacer:

Si está utilizando versiones personalizadas de esas plantillas, deberá actualizarlas agregando el siguiente código:

<?php echo $this->getBlockHtml('formkey') ?>

Si está utilizando un módulo de pago de terceros, deberá ponerse en contacto con ellos para que puedan proporcionar una versión actualizada de su módulo.

Además, si tiene versiones personalizadas de los archivos JS enumerados anteriormente, también deberá actualizarlos.

Excepto su tiempo :

Fabian Schmengler escribió un pequeño y agradable script para actualizar todas esas cosas por usted, puede encontrarlo aquí:

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

NOTA IMPORTANTE : la validación de la clave de formulario de pago se puede cambiar en el backend a través de un nuevo campo de configuración en Sistema> Configuración> Administrador> Seguridad> Habilitar validación de clave de formulario al finalizar la compra . ¡ESTO NO ESTÁ HABILITADO POR DEFECTO, por lo que tendrá que habilitarlo para beneficiarse de esta característica de seguridad! Tenga en cuenta que recibirá un aviso en el backend si no está habilitado.

Devolución de llamada de carga de imagen

El controlador de la galería de imágenes se ha actualizado para agregar una devolución de llamada de validación.

Qué hacer

Si está utilizando un módulo personalizado que carga imágenes con un código similar al siguiente:

        $uploader = new Mage_Core_Model_File_Uploader('image');
        $uploader->setAllowedExtensions(array('jpg','jpeg','gif','png'));
        $uploader->addValidateCallback('catalog_product_image',
            Mage::helper('catalog/image'), 'validateUploadFile');
        $uploader->setAllowRenameFiles(true);
        $uploader->setFilesDispersion(true);

Le sugiero que actualice ese código agregando la siguiente pieza después:

        $uploader->addValidateCallback(
            Mage_Core_Model_File_Validator_Image::NAME,
            Mage::getModel('core/file_validator_image'),
            'validate'
        );

Enlaces simbólicos

Este parche elimina el campo de configuración del sistema que le permite permitir enlaces simbólicos de plantilla en el back-end. Solía ​​estar en Sistema> Configuración> Desarrollador> Plantilla> Permitir enlaces simbólicos . Ahora toda la sección de plantillas se ha ido.

Además de eso, ese campo ahora está deshabilitado de forma predeterminada a través de app/etc/config.xml

Lo curioso aquí es que recibirá un aviso en el backend si tiene ese campo de configuración habilitado antes del parche, pero no podrá desactivarlo cuando el campo desaparezca.

La única forma de hacerlo es ejecutando la siguiente consulta SQL

UPDATE core_config_data SET value = 0 WHERE path = "dev/template/allow_symlink";

Aclaración

Primero, le sugiero que verifique esas dos publicaciones que lo ayudarán a comprender el propósito de esa modificación de Symlink:

Esta modificación se trata realmente de llamar contenido descargable (como imágenes) a través de directivas de plantilla.

El problema relacionado con los enlaces simbólicos solo se puede explotar con acceso de administrador y Magento también agregó más protección en la carga de imágenes.

Tenga en cuenta que son algunas protecciones contra la forma conocida de explotarlo, además de la configuración en sí.

Qué hacer : si como yo, estás usando Modman o Composer con enlaces simbólicos de plantillas, enfrentarás algunos problemas. Todavía estoy tratando de averiguar qué es lo mejor que se puede hacer aquí, aparte de tratar con consultas SQL.

Publicación principal sobre este tema: SUPEE-9767, modman y enlaces simbólicos

Lista de posibles problemas

V2 fue lanzado desde esa publicación original. No olvides actualizar

Loco

La palabra 'confirmado' se usa para errores confirmados. Si no está allí, eso significa que podría ser un error, pero aún no se ha confirmado.

Problemas fallidos de Hunk

Tenga en cuenta que todos esos problemas podrían deberse simplemente a que modificó el archivo original, para verificar que este no sea el caso:

  • Haga una copia de seguridad del archivo donde obtiene el error Fallo de Hunk
  • Descargue el archivo original de su versión de Magento
  • Compara ambos archivos

Si los archivos son diferentes, tendrá que aplicar el parche con el archivo original y luego volver a aplicar los cambios personalizados de forma limpia, como:

  • plantilla personalizada en una carpeta de tema personalizado
  • local.xml
  • aplicación / código / archivo local

Si los archivos no son diferentes, se trata de un problema de permiso o un "error" en el parche.

Raphael en Digital Pianism
fuente
1
@Icono no. Para verificar, use la herramienta a la que hice referencia en la parte superior de mi respuesta
Raphael en Digital Pianism el
1
solo para agregar a la lista de "otros problemas": parece que magento.stackexchange.com/questions/167616/… tampoco está solucionado en la última versión
Anton Boritskiy
1
@RaphaelatDigitalPianism: magento.stackexchange.com/q/177560/51361
1
Otra adición a la lista: el parche rompe el multishipping para el tema predeterminado magento.stackexchange.com/questions/177681/…
Aad Mathijssen
1
'La marca de agua tiene fondo negro cuando es transparente': puede confirmar que esta es correcta. Esto sucede cuando
cargas
42

Problema1: form_key inválido en la página de pago

Magento agrega form_keyen la mayoría de las formas.

si es así using default onepage and using custom theme, comenzará a recibir ** form_keyproblema al finalizar cada paso **;

debe agregar clave de formulario en <?php echo $this->getBlockHtml('formkey') ?>

para formar cada paso de pago si hay archivos debajo,

  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/billing.phtml
  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/payment.phtml
  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping.phtml

  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping_method.phtml

si los archivos de plantilla están llamando desde el tema base, entonces no crea un problema. Porque el parche actualizará automáticamente esos archivos.

También tenga en cuenta: <?php echo $this->getBlockHtml('formkey') ?>siempre debe estar dentro de la etiqueta del formulario

 <form action="" .....>
     <fieldset>
      .......
       <?php echo $this->getBlockHtml('formkey') ?>
     </fieldset>
 </form>

** Si utiliza el pago de envío múltiple de Magento, debe hacerlo en

archivos a continuación:

Problema 2: problema de form_key con el formulario de estimación de envío en la página del carrito:

Agregue form_key en el formulario de envío estimado en la página del carrito

Luego debe agregar clave de formulario <?php echo $this->getBlockHtml('formkey') ?>

a app/design/frontend/{Your_Package}/{YOUR_THEME]/template/checkout/cart/shipping.phtml

Problema 3: Magento onepage checkout opcheckout.js error

Si usa el pago predeterminado de una página y tiene, opcheckout.js entonces debería verificar

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {está disponible en opcheckout.js

Si no sale, reemplace

if (elementos [i] .name == 'pago [método]') {

con

if (elementos [i] .name == 'pago [método]' || elementos [i] .name == 'form_key') {

Para el caso del problema1, problema2, problema3, el problema se puede solucionar fácilmente usando el script add-checkout-form-key.sh de @FabianSchmengler . Solucionará el problema en sus archivos de tema receptivo

Problema 4: Clave de formulario inválida después del inicio de sesión del cliente cuando Mage_Customer_Model_Session reescribe

Si la Mage_Customer_Model_Sessionclase reescribe o ha llamado desde

app/code/local/Mage/Customer/Model/Session.phpentonces es posible que tenga un problema de form_key cuando configuramos un cliente para la sesión usando setCustomerAsLoggedIn()/ o después de que un cliente configuró en la sesión.

En este caso, debes agregar

Mage :: getSingleton ('core / session') -> renewFormKey ();

en setCustomerAsLoggedIn () antes de la llamada de

Mage::dispatchEvent('customer_login', array('customer'=>$customer));

  public function setCustomerAsLoggedIn($customer)
    {
        $this->setCustomer($customer);
        $this->renewSession();
        // add this  for patch -9767
        Mage::getSingleton('core/session')->renewFormKey();
       // end this for patch 9767
        Mage::dispatchEvent('customer_login', array('customer'=>$customer));
        return $this;
    }

Problema 5: problema de Form_key después de cerrar sesión

Después de cerrar la sesión del cliente de la sesión , puede comenzar el problema de la sesión si If Mage_Customer_Model_Sessionclass reescribe o ha llamado desde

app/code/local/Mage/Customer/Model/Session.php

En esas mismas necesidades para este caso:

   protected function _logout()
    {
        $this->setId(null);
        $this->setCustomerGroupId(Mage_Customer_Model_Group::NOT_LOGGED_IN_ID);
        $this->getCookie()->delete($this->getSessionName());
// add this  for patch -9767
Mage::getSingleton('core/session')->renewFormKey();
        return $this;
    }

Recomendación:

Recomendación 1: para solucionar el problema de supee-9767 , puede usar el parche https://github.com/experius/Magento-1-Experius-Patch-Helper

Esta es una mejor solución por ahora.

Tenga en cuenta que , antes de hacerlo, se recomienda encarecidamente realizar copias de seguridad de archivos y bases de datos o copias de seguridad completas del sistema.


Recomendación 2: Use la función de parche en su COMPROBACIÓN DE ONESTEP

Sabemos que la versión del parche supee-9767 por razones de seguridad, si usa ONESTEP CHECKOUT, entonces debe agregar la validación form_key para GUARDAR la acción de su controlador de pago onestep .

Suponga que para guardar los detalles del método de envío, su pago en este paso ha utilizado saveShippingmethod () Luego, en esto, debe agregar

if ($this->isFormkeyValidationOnCheckoutEnabled() && !$this->_validateFormKey()) {
           return;
      }

También debe agregar la clave de formulario <?php echo $this->getBlockHtml('formkey') ?> en la sección respectiva de los archivos phtml de pago de onestep

Algún enlace relacionado

https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/

Amit Bera
fuente
1
Una línea agradable y rápida para encontrar sus archivos de plantilla personalizados para la clave de formulario en el pago; encontrar aplicación / diseño / interfaz | grep -E "pago / onepage / (facturación | pago | envío | método_envío) .phtml" | grep -v "base / predeterminado" | grep -v "rwd / default"
Peter Jaap Blaakmeer
66
o actualícelos de inmediato con un revestimiento un poco más largo: gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b
Fabian Schmengler
¡Esa es la magia de @FabianSchmengler! :)
Amit Bera
@FabianSchmengler increíble, ¡eso funcionó!
Peter Jaap Blaakmeer
1
@AmitBera FYI: algunos complementos de pago utilizan AJAX para enviar facturación / envío / etc. Solo tuve que parchear uno. Una manera fácil de hacerlo es poner <script> var formKey = "<? Php echo Mage :: getSingleton ('core / session') -> getFormKey ();?>"; </script> en la cabeza del tema. Luego puede agregar form_key: formKey como parámetro para el envío de AJAX. Por supuesto, pruebe los formularios después para confirmar el envío del nuevo parámetro y edite el Controlador para manejarlo como mencionó en su publicación.
Kalvin Klien
26

Basado en mi primer pase en la revisión del archivo de parche ...

  • Se admin/security/validate_formkey_checkoutha agregado una nueva configuración . Cuando se activa, se verifica la presencia de una clave de formulario en los formularios de pago. Si los archivos de plantilla se anulan en el tema, deberán actualizarse allí. Esta configuración parece estar desactivada por defecto
  • Los enlaces simbólicos parecen no estar permitidos por defecto (en app/etc/config.xml). Además, la capacidad de permitirlos parece haberse eliminado de la configuración del administrador. Sin embargo, si su sitio anteriormente habilitaba explícitamente enlaces simbólicos, la configuración se guardaría en la base de datos, anulando este cambio.
  • Debe borrar tanto el caché como el caché de página completa al aplicar este parche. Las excepciones de diseño se guardan en un formato incompatible con la decodificación. Verá un error como este "Error de decodificación: error de sintaxis" si no vacía la memoria caché de la página.
mpchadwick
fuente
1
También podría ingresar con un editor hexadecimal y agregarlo a la base de datos usted mismo, pero eso puede ser un poco demasiado para la mayoría de las personas
gato
1
Si algunos de ustedes están usando CDN, como cloudflare, asegúrese de purgar el caché. Intenté pasar por el proceso de pago con CDN activo y no pasaría de la página Pagos. En el momento en que purgué el caché y habilité el modo de Desarrollo, todo salió bien.
Icono
14

Debajo del base/defaultarchivo afectado con este parche, si estos archivos estaban en su tema, haga los cambios correspondientes

app/design/frontend/base/default/template/checkout/cart/shipping.phtml

app/design/frontend/base/default/template/checkout/multishipping/billing.phtml

app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/billing.phtml

app/design/frontend/base/default/template/checkout/onepage/payment.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml

app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml

en todos los phtmlarchivos anteriores , se agrega la línea de clave de formulario, así que agregue esta línea en su archivo phtml respectivo.

 <?php echo $this->getBlockHtml('formkey') ?>

Para el problema anterior, @fabian creó un script que agregará la clave de formulario incluso en su archivo de tema

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

después de aplicar el parche de seguridad si obtiene un error para la clave de formulario, puede aplicar este parche, para aplicar este proceso de parche es igual que el parche de seguridad solo

  sh filename.sh

y un base/defaultcambio en el Jsarchivo

  skin/frontend/base/default/js/opcheckout.js

así que si este jsarchivo se está cargando desde su tema, siga los pasos a continuación

quitar la línea de soplado

 if (elements[i].name=='payment[method]') {

y agregue debajo de la línea en lugar de arriba

 if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {

EDITAR

Y si está utilizando cualquier extensión de pago que anula debajo de los archivos, agregue la línea de clave de formulario en el archivo phtml de la extensión de pago.

EDIT2 - Problemas

1) Error en saveBillingAction () u obtener clave de formulario nula o problema de clave de formulario: Parche 9767 obteniendo clave de formulario no válida

2) Hunk # 1 FALLÓ en 225. 1 de 1 trozo FALLÓ - guardar rechazos en la aplicación de archivo / diseño / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtml: SUPEE-9767 - Hunk # 1 FALLÓ en 225. 1 de 1 trozo FALLÓ

3) guardar rechazos en la aplicación de archivo / código / core / Enterprise / PageCache / Model / Observer.php.rej: SUPEE-9767 ERROR: el parche no se puede aplicar / revertir con éxito

4) SUPEE-9767, modman y enlaces simbólicos: SUPEE-9767, modman y enlaces simbólicos

5) app / design / frontend / rwd / default / layout / page.xml Hunk # 1 FAILED at 36. Hunk # 2 FAILED at 54. 2 de 2 hunks FAILED: SUPEE-9767 Error

6) 1 de 1 trozo FALLIDO - guardando rechazos en la aplicación de archivo / código / core / Mage / Sales / Model / Quote / Item.php: Magento 1.9.2.2 SUPEE-9767 ERROR de parche

7) error de pago de onestep (de nuevo, este es el problema clave del formulario): SUPEE-9767 Magento CE 1.9.3.3 El pago en un solo paso no funciona con la validación de la tecla de formulario al finalizar la compra habilitada

8) problema de registro de cliente de pago en un solo paso: SUPEE-9767 Patch / CE 1.9.3.3 - Pago de una página - Problema de registro de cliente

9) app / code / core / Mage / Core / Model / File / Validator / Image.php: Magento SUPEE 9697 1.9.2.2 falla en Image.php

Murtuza Zabuawala
fuente
1
La versión 2 del parche debería estar disponible pronto. Los errores deben ser reparados.
Icono
1
@icon esperando la v2
Murtuza Zabuawala
9

Tenga en cuenta que los enlaces simbólicos siempre se han deshabilitado de manera predeterminada en las nuevas instalaciones de Magento admin. Los valores de configuración SI / NO están predeterminados en 'NO'. La actualización ahora deshabilita explícitamente los enlaces simbólicos en config.xml y, como precaución adicional, también elimina la sección de plantilla de admin-> developer que contenía la opción de configuración.

Esto no afectará su configuración actual de enlaces simbólicos, si habilitó manualmente los enlaces simbólicos anteriores a 1.9.3.2, permanecerán habilitados, aunque ya no podrá ver la configuración en admin.

Los usuarios que usan modman para administrar los módulos Magento 1.x deben asegurarse de no deshabilitar los enlaces simbólicos, ya que esto deshabilitará los módulos modman.

Los administradores responsables pueden habilitar nuevamente la sección de administración del enlace simbólico buscando los cambios de diferencias en la sección de plantilla en app / code / core / Mage / Core / etc / system.xml y agregando la sección a su system.xml en la línea 600. O los enlaces simbólicos de doble verificación todavía están habilitados con

n98-magerun.phar config: volcado | enlace simbólico grep

Aquí está el archivo diff para magento1933 y magento1932 para ayudarlo a identificar cambios en el tema predeterminado que pueden afectar sus temas personalizados / extendidos.

diff -r magento1933 magento1932> https://pastebin.com/ADzMBLhr

paj
fuente
¿Por qué han eliminado la opción Symlinks ?, ¿existe ahora un exploit abierto al público (fuera del usuario administrador) o es solo un riesgo si se encuentra en un entorno compartido?
PaddyD
este hilo parece responder a mi pregunta: magento.stackexchange.com/questions/176952/…
PaddyD
Los enlaces simbólicos están deshabilitados por alguna razón. Sugiero copiar en lugar de enlace simbólico: magento.stackexchange.com/a/177149/54863
Barryvdh
9

Problema: el uso de php7 a veces arroja el siguiente error:

Decoding failed: Syntax error

#0 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(179): Zend_Json::decode('')
#1 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(215): Enterprise_PageCache_Model_Observer->_loadDesignExceptions()
#2 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(125): Enterprise_PageCache_Model_Observer->_saveDesignException()
#3 /______/app/code/core/Mage/Core/Model/App.php(1358): Enterprise_PageCache_Model_Observer->cacheResponse(Object(Varien_Event_Observer))
#4 /______/app/code/core/Mage/Core/Model/App.php(1337): Mage_Core_Model_App->_callObserverMethod(Object({custom extensio}_Model_Rewrite_PageCache_Observer), 'cacheResponse', Object(Varien_Event_Observer))
#5 /______/app/Mage.php(456): Mage_Core_Model_App->dispatchEvent('controller_fron...', Array)
#6 /______/app/code/core/Mage/Core/Controller/Varien/Front.php(182): Mage::dispatchEvent('controller_fron...', Array)
#7 /______/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#8 /______/app/Mage.php(691): Mage_Core_Model_App->run(Array)
#9 /______/index.php(105): Mage::run('brandfield_nl', 'store')
#10 {main}

Es bastante seguro de que la versión de Zend tiene que hacer algo con él. Una solución rápida es esto, pero seguramente no es correcta:

-> app / code / core / Enterprise / PageCache / Model / Observer.php: 244 reemplácelo con:

    if ($cachedSslOffloaderHeader !== false) {
        $cachedSslOffloaderHeader = trim(@Zend_Json::decode($cachedSslOffloaderHeader));
    }

-> y app / code / core / Enterprise / PageCache / Model / Observer.php: 177 con:

    if ($exceptions !== false) {
        $exceptions = Zend_Json::decode($exceptions);
    }

Por supuesto, cree un complemento para reescribir esto. Pero estoy seguro de que hay algo mejor que hacer aquí.

ACTUALIZACIÓN (Mejor solución)

-> Ve a: lib / Zend / Json.php y después de la línea 76 agrega esto:

    if ((float)phpversion() >= 7.0
        && empty($encodedValue)
    ) {
        return null;
    }

Cree su extensión para anularla y no edite el archivo principal.

folektoras133
fuente
La caché se borró por completo. Este no es el mismo problema.
folektoras133 01 de
2
Nos topamos con este mismo problema: la reversión de app / code / core / Enterprise / PageCache / Model / Observer.php eliminó el problema, pero obviamente esa no es la solución correcta, solo la prevención a:5:{i:0;s:29:"Decoding failed: Syntax error";i:1;s:1376:"#0 app/code/core/Enterprise/PageCache/Model/Observer.php(177): Zend_Json::decode('a:0:{}')
Judder
9

Problema: el código dinámico o CSS desactiva el elemento de entrada de clave de formulario al finalizar la compra

Un problema que he visto es cuando el código dinámico (paypal plus) en el proceso de pago de una página sobrescribe el elemento del conjunto de campos en el formulario de método de pago de un solo paso html: eliminar o deshabilitar (con css) el elemento oculto form_key.

La solución es asegurar que el elemento formkey no esté siendo deshabilitado por ningún código dinámico o CSS. Mover el código de la tecla de formulario fuera del elemento del conjunto de campos también puede ayudar

<form>
    <?php echo $this->getBlockHtml('formkey') ?>
    <fieldset>
        <?php echo $this->getChildHtml('methods') ?>
    </fieldset>
</form>

Puede confirmar fácilmente si la clave_formulario se está detectando y enviando al controlador de una página inspeccionando las solicitudes de red ajax en su navegador a medida que avanza por los métodos de pago, cada método debe incluir la clave del formulario en los datos del formulario ajax, si el formulario La clave no está allí, pero el código fuente de Magento ha sido parcheado.

ingrese la descripción de la imagen aquí

paj
fuente
2
Este poco de solución no pareció funcionar para mí con EE. Descubrí que el archivo también app/design/frontend/[package]/[theme]/template/giftcardaccount/onepage/payment/scripts.phtml debía actualizarse: las líneas 35-38 deben actualizarse para incluir || elements[i].name == 'form_key'junto con los otros selectores para mantener el campo de formulario form_key deshabilitado.
Greg Nickoloff
Gracias g-man1066! Ese era exactamente el problema que estaba teniendo.
grafikchaos
9

Problema: faltan correcciones en head-simple.phtml

app/design/adminhtml/default/default/template/oauth/authorize/head-simple.phtml

necesita las mismas soluciones que

app/design/adminhtml/default/default/template/page/head.phtml
William Tran
fuente
Para aquellos que buscan, esa solución es; github.com/nathandcornell/magento-patches/blob/…
Peter Jaap Blaakmeer
8

PROBLEMA: El registro del cliente falla cuando se utiliza el pago genérico de 5 pasos de Magento.

Este problema solo se presenta cuando HABILITAMOS la autenticación de clave de formulario. Versión utilizada: 1.7.0.2, pero parece que alguien ha publicado que el mismo problema también ocurre en la versión 1.9.3. SUPEE-9767 Patch / CE 1.9.3.3 - Pago de una página - Problema de registro del cliente

Cuando vaya a pagar, se nos presentan 2 opciones: PAGAR COMO INVITADO O REGISTRARSE Una vez que haga clic en "Registrarse" y complete el formulario junto con la contraseña, proceda a través de todos los pasos y complete el pedido. El pedido se realiza, PERO el cliente nunca se registra en magento. Parece que el huésped hizo un pedido.

Cuando regresé y desactivé la autenticación de clave de formulario, e intenté hacer un pedido mientras me registraba como cliente, se realizó sin ningún problema y el cliente se registró en el back-end.

Icono
fuente
1
Aquí hay una publicación más detallada sobre este tema magento.stackexchange.com/questions/177035/…
Raphael en Digital Pianism
8

ACTUALIZACIÓN 13/07/2017 [EL PROBLEMA ESTÁ FIJO]

El equipo de Magento ha lanzado SUPEE-9767 V2 en esta versión del parche. Se solucionó el problema con los gifs transparentes y png.

Debe revertir todos los cambios en el archivo que se discutió en este hilo. Luego revierta el parche V1 aplicado y finalmente aplique la nueva versión V2.


PRE - SUPEE-9767 V2

No utilice el código que se describe a continuación, en su lugar, aplique V2 del parche, el problema que se describe a continuación ya está solucionado en esta versión

Si alguien experimenta un problema con png transparentes, cuando se carga desde el panel de administración, el fondo se vuelve negro. (En los productos) está relacionado con la devolución de llamada de Image Upload introducida en:

app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php

Por el momento no estoy seguro de qué es exactamente lo que está causando este comportamiento, pero estoy tratando de resolverlo, puedo confirmar que cuando se elimina la devolución de llamada, el extraño comportamiento desaparece.

ingrese la descripción de la imagen aquí

ACTUALIZAR

Ok, encontré la función que también se actualiza desde SUPEE-9767, esto en realidad está rompiendo la transparencia en los png, se crea una copia de la imagen original sin transparencia.

+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
@@ -87,10 +87,33 @@ public function setAllowedImageTypes(array $imageFileExtensions = array())
      */
     public function validate($filePath)
     {
-        $fileInfo = getimagesize($filePath);
-        if (is_array($fileInfo) and isset($fileInfo[2])) {
-            if ($this->isImageType($fileInfo[2])) {
-                return null;
+        list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
+        if ($fileType) {
+            if ($this->isImageType($fileType)) {
+                //replace tmp image with re-sampled copy to exclude images with malicious data
+                $image = imagecreatefromstring(file_get_contents($filePath));
+                if ($image !== false) {
+                    $img = imagecreatetruecolor($imageWidth, $imageHeight);
+                    imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
+                    switch ($fileType) {
+                        case IMAGETYPE_GIF:
+                            imagegif($img, $filePath);
+                            break;
+                        case IMAGETYPE_JPEG:
+                            imagejpeg($img, $filePath, 100);
+                            break;
+                        case IMAGETYPE_PNG:
+                            imagepng($img, $filePath);
+                            break;
+                        default:
+                            return;
+                    }
+                    imagedestroy($img);
+                    imagedestroy($image);
+                    return null;
+                } else {
+                    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
+                }
             }
         }
         throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));

ACTUALIZAR

Aquí está la versión actualizada de la función para preservar la transparencia png

  imagealphablending($img, false);
  imagesavealpha($img, true);

Estas dos líneas deben agregarse al parche. Actualiza la función enapp/code/core/Mage/Core/Model/File/Validator/Image.php

/**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                imagealphablending($img, false);
                imagesavealpha($img, true);  
                imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

ACTUALIZACIÓN 23/06/17

Esta versión actualizada de la función corrige la transparencia PNG y GIF.

    /**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagecolortransparent($img, imagecolorallocatealpha($img, 0, 0, 0, 127));
                        imagealphablending($img, false);
                        imagesavealpha($img, true);
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagealphablending($img, false);
                        imagesavealpha($img, true);  
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}
Daniel Yovchev
fuente
1
Esto resolvió mi problema en una instalación de Magento 1.7. ¡Gracias!
Tjitse
No hay problema, Tjitse solo tome nota de este cambio en caso de que el equipo de Magento no repare el parche, tendrá que revertirlo cuando realice el próximo parche. He enviado el problema a la comunidad en bugcrowd.com, espero que pronto introduzcan el parche.
Daniel Yovchev
esto lo arregla para pngs, pero no para archivos gif transparentes. los archivos gif necesitan un manejo ligeramente diferente usando imagecolortransparent
alternar el
Gracias por señalar esto alternate, vea la función actualizada que también corrige la transparencia gif.
Daniel Yovchev
7

Problema: Permitir notificación de enlace simbólico no se muestra a los administradores

La notificación de enlace simbólico no se mostrará en el área de notificación del administrador ya que no está incluida en el <block type="core/text_list" name="notifications" as="notifications">

El parche para CE y EE a continuación:

--- app/design/adminhtml/default/default/layout/main.xml
+++ app/design/adminhtml/default/default/layout/main.xml
@@ -119,7 +119,8 @@ Default layout, loads most of the pages
<block type="adminhtml/cache_notifications" name="cache_notifications" template="system/cache/notifications.phtml"></block>
<block type="adminhtml/notification_survey" name="notification_survey" template="notification/survey.phtml"/>
<block type="adminhtml/notification_security" name="notification_security" as="notification_security" template="notification/security.phtml"></block>
-            </block>
+                <block type="adminhtml/checkout_formkey" name="checkout_formkey" as="checkout_formkey" template="notification/formkey.phtml"/></block>
+                <block type="adminhtml/notification_symlink" name="notification_symlink" template="notification/symlink.phtml"/>
<block type="adminhtml/widget_breadcrumbs" name="breadcrumbs" as="breadcrumbs"></block>
<!--<update handle="formkey"/> this won't work, see the try/catch and a jammed exception in Mage_Core_Model_Layout::createBlock() -->

El problema es </block>al final de checkout_formkey(que es automático) y, por lo tanto, cierra al padre notifications. Esto hace notification_symlinkque no se incluya en el core/text_listy no se represente.

mwylde
fuente
Esto no es realmente un problema, la notificación se ha eliminado porque los enlaces simbólicos se han deshabilitado explícitamente y se ha eliminado la sección de configuración del enlace simbólico. No es posible cambiar manualmente el valor del enlace simbólico en admin en v1933, por lo que mostrar una notificación de administrador no tiene sentido. El problema será para las nuevas instalaciones de 1933 donde los usuarios que requieren enlaces simbólicos, es decir, para modman, ya no pueden habilitarlo manualmente. Se podría inferir que Magento no espera que las nuevas instalaciones ... 1.x
PAJ
No estoy de acuerdo, este parche no deshabilita explícitamente la configuración si ya está configurada, solo la deshabilita si aún no está configurada. Por lo tanto, si una instancia tiene dev / template / allow_symlink establecido en yes en el DB / local.xml antes de este parche y aplica el parche, DEBERÍA recibir la advertencia de que los enlaces simbólicos están permitidos ya que son potencialmente vulnerables.
mwylde
Entiendo tu punto y estás en lo correcto. Pero para un usuario normal, ¿qué harían entonces? Es imposible deshabilitarlo manualmente desde el administrador ya que se ha eliminado la opción de configuración. Es un poco de una situación de Catch 22 ...
PAJ
7

Pequeño consejo para #patchday; después de copiar 1.9.3.3 sobre su instalación, ejecute git diff -w --stat | grep -v " 2 +" | grep -v " 0"para ver rápidamente cambios más grandes en los archivos.

Peter Jaap Blaakmeer
fuente
7

Problema: plantilla de envío EE no parcheada

Parcheé una instalación EE 1.13.1.0, y la plantilla de envío empresarial ( app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) no tenía la clave de formulario agregada, pero las plantillas de facturación y pago sí.

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml fue parcheado

Laura
fuente
También necesitaba (para EE 1.14.2) agregar el form_key a /app/design/frontend/enterprise/default/template... .../checkout/cart/coupon.phtml,.../giftcardaccount/cart/block.phtml .../giftcardaccount/cart/check.phtml
Greg Nickoloff
4

Hay un problema con las versiones de Magento EE que están parcheadas con SUPEE-9767 (por lo que no con las actualizaciones a 1.14.3.3). La clave de formulario en esa página se almacenará en caché. Entonces, cuando vacío mi caché y luego voy a la página de un producto y me aseguro de que la página esté completamente en caché (actualizar un par de veces), debería poder agregar ese producto a mi carrito.

Ahora, cuando abro un navegador diferente (o modo incógnito), abra la misma página e intente agregar el producto al carrito nuevamente. El producto no se agregará al carrito debido a la clave de formulario. Ahora, cuando vuelva a vaciar el caché, el producto puede agregarse nuevamente al carrito.

Gracias a Jasper Zeinstra

Arjen Miedema
fuente
3

Para los desarrolladores que usan Magento Composer Intaller, puede cambiar la estrategia de implementación a Copiar en lugar de Enlace simbólico. También puede configurar para agregar los archivos del módulo a su .gitignore, para que su repositorio se mantenga limpio.

https://github.com/Cotya/magento-composer-installer/blob/master/doc/Deploy.md#deploy-per-copy-instead-of-symlink

{ "extra":{ "magento-root-dir": "htdocs/", "magento-deploystrategy": "copy", "auto-append-gitignore": true } }

Barryvdh
fuente
Descubrimos que con la copia se "magento-force": true,vuelve importante
Jeroen
2

Problema: Patch estaba trabajando en Vanilla Magento 1.7.0.0 [editado]

Durante la prueba de nuestro script de parche descubrimos un problema en el parche para Magento 1.7.0.0. No sé si alguien todavía lo usa, pero de todos modos es un problema en SUPEE-9767. Utilizamos una instalación de vainilla e instalamos primero todos los parches anteriores.

Archivo de parche utilizado: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh El archivo de parche no funciona para Magento 1.7.0.1 y 1.7.0.2

Resumen de problemas:

ERROR: Patch can't be applied/reverted successfully.
...
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
...
checking file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED
...

Para el registro, esto en el 1.7.0.0 probamos el parche en:

$ grep SUPEE app/etc/applied.patches.list
2017-06-01 12:59:49 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
-e 2017-06-01 12:59:49 UTC | SUPEE-1049 | EE-1.12.0.2 | v1 | 6d06f286f461562fa6d6573349f1491f7bf89859 | Wed Feb 13 17:46:13 2013 -0800 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-01 12:59:49 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-01 12:59:49 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-01 12:59:49 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-01 12:59:49 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-01 12:59:49 UTC | SUPEE-6788 | CE_1.7.0.1 | v1 | 04d237d56b116989e46839c41691585d927f99db | Fri Oct 23 13:52:50 2015 +0300 | f69136a
2017-06-01 12:59:49 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-01 12:59:50 UTC | SUPEE-8788 | CE_1.7.0.0 | v2 | 6b5ef4fc5b09af74d0fd401440948d0a54dd203d | Fri Oct 14 19:27:22 2016 +0300 | 84fa3dd598466fa5c482965a3f8e5395af33bf9d
2017-06-01 12:59:50 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-01 12:59:50 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523
Jeroen Vermeulen - MageHost
fuente
44
Si le falta ese archivo, lo más probable es que no haya aplicado el parche de seguridad SUPEE-7405.
Ryan Hoerr
@RyanHoerr tiene razón, SUPEE-7405 se omitió porque el archivo oficial PATCH_SUPEE-7405_CE_1.7.0.2_v1-2016-01-20-04-58-44.shno funciona para 1.7.0.0. Creé una versión fija del archivo. Si alguien lo necesita, envíeme un mensaje.
Jeroen Vermeulen - MageHost
2

Solo tuve que revertir este parche debido a un comportamiento extraño. Por alguna razón, ciertos usuarios no pueden agregar ciertos artículos a su carrito.

Supongo que tiene algo que ver con las viejas cotizaciones que chocan con la cotización actual para ese cliente. Verifiqué este problema iniciando sesión como usuario para asegurarme de que no era solo un 1D10T.

Ha sido un problema desde que tomé ese parche el viernes pasado. Estamos utilizando 1.14.2.4 . Estamos muy modificados, por lo que podría funcionar bien para otros usuarios. ¡Sólo una advertencia!

Discípulo de uno
fuente
Eso es correcto, el parche rompe la acción de agregar al carrito para la versión EE del Magento. Básicamente, el problema ocurre debido a que el módulo PageCache tiene una versión de la lógica de generación form_key, mientras que la sesión tiene la suya propia. Cuando FPC tiene la versión en caché de la página solicitada, pero necesita regenerar el minicart, se activa la sesión que regenera form_key al mismo tiempo que se llama FPC save que genera su propia form_key. En ese punto, el valor de sesión de form_key difiere de uno almacenado en la cookie del cliente (utilizado en el procesador FPC), por lo que obtiene una clave no válida al agregar al controlador del carrito.
Stjepan
También me encuentro con este problema. Te avisaré si encuentro una solución.
cmtickle
Resolví
cmtickle
¿Alguien sabe si esto se resuelve en SUPEE-9767 v2?
Discípulo del Uno
2

Problema: bucle de redireccionamiento infinito en 1.6.0.0

Arreglo rapido

Encuentre las siguientes líneas dentro de la función de método protegido _checkBaseUrl ($ request) en el archivo app / code / core / Mage / Core / Controller / Varien / Front.php

 if (isset($uri['scheme']) && $uri['scheme'] != $request->getScheme()
        || isset($uri['host']) && $uri['host'] != $request->getHttpHost()
        || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) {  

Cambia estas líneas a

 if (isset($uri['host']) && $uri['host'] != $request->getHttpHost()
            || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) { 

Después de eso, guarde el archivo (comprométase a su REPO), borre el caché (elimine todo lo que está dentro de la carpeta var / cache) y vuelva a cargar el frente de su tienda. Debería encontrar que el sitio se carga sin más problemas de redireccionamiento 302 después de aplicar el parche SUPEE 9767.

Causa principal

La diferencia en el valor SCHEME entre la solicitud real y el URI después de la redirección. Por ejemplo: la solicitud real devuelve el esquema HTTP pero el esquema en el URI puede ser HTTPS.

Posibles razones subyacentes

  1. Es probable que tenga una regla de redireccionamiento en el archivo .htaccess para redirigir todas las solicitudes http a https. El usuario solicita http://yourdomain.com y es posible que haya cambiado el esquema y lo haya redirigido a https: // yourdomain en lugar de http://yourdomain.com que realmente había solicitado.

  2. Las URL seguras y no seguras de la base comienzan con https

Haijerome
fuente
2

El ERROR CONFIRMADO "El registro del cliente falla al finalizar la compra" ocurrió un poco diferente de mi parte.

Si el cliente elige registrarse en el proceso de pago, su contraseña no se almacena correctamente. El cliente se creó correctamente solo porque la contraseña no está almacenada. Detecté esto por el hecho de que la contraseña no se mostraba en el correo electrónico de bienvenida. La gente no puede iniciar sesión debido a esto también.

Corrección de errores vinculada en SUPEE-9767 Patch / CE 1.9.3.3 - Pago de una página - El problema de registro del cliente también ha hecho el trabajo por mí.

ahe_borriglione
fuente
2

¿Alguien puede decirme para qué diablos ... esto es ... en supee-9767?

ingrese la descripción de la imagen aquí

Detzler
fuente
1
La versión jQuery 1.10.2 se considera vulnerable y está marcada por algunos escáneres PCI. La versión 1.12 no es.
Ryan Hoerr
@Detzler StackExchange no es un foro. Si desea hacer una pregunta, debe publicar una, no una respuesta a una pregunta.
toon81
1
Ryan Hoerr preguntó sobre cualquier problema que traiga el parche. Así que le dije un posible cambio importante, como puede ver en la captura de pantalla. No puedo explicar la razón de este cambio. Entonces le pregunté. Entonces, ¿cuál es tu problema?
Detzler
2

El parche no funciona incluso para un Magento 1.7.0.2 de vainilla.

martins@martinsmac.local:/var/www/magento1702-original$ ./PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file app/code/core/Mage/Admin/Model/Session.php
Hunk #1 succeeded at 109 (offset -29 lines).
patching file app/code/core/Mage/Adminhtml/Block/Checkout/Formkey.php
patching file app/code/core/Mage/Adminhtml/Block/Notification/Symlink.php
patching file app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Filter/Date.php
patching file app/code/core/Mage/Adminhtml/Model/Config/Data.php
patching file app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php
patching file app/code/core/Mage/Checkout/controllers/MultishippingController.php
patching file app/code/core/Mage/Checkout/controllers/OnepageController.php
Hunk #1 succeeded at 293 (offset -34 lines).
Hunk #2 succeeded at 313 (offset -34 lines).
Hunk #3 succeeded at 363 (offset -34 lines).
Hunk #4 succeeded at 392 (offset -34 lines).
Hunk #5 succeeded at 431 (offset -34 lines).
patching file app/code/core/Mage/Checkout/etc/system.xml
patching file app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
patching file app/code/core/Mage/Core/Controller/Front/Action.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
Hunk #1 succeeded at 141 (offset -7 lines).
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
patching file app/code/core/Mage/Core/etc/config.xml
patching file app/code/core/Mage/Core/etc/system.xml
patching file app/code/core/Mage/Customer/Model/Session.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Adapter/Zend/Cache.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php
patching file app/code/core/Mage/ImportExport/Model/Import/Uploader.php
patching file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php.rej
patching file app/code/core/Mage/Widget/Model/Widget/Instance.php
patching file app/code/core/Mage/XmlConnect/Helper/Image.php
patching file app/design/adminhtml/default/default/layout/main.xml
patching file app/design/adminhtml/default/default/template/notification/formkey.phtml
patching file app/design/adminhtml/default/default/template/notification/symlink.phtml
patching file app/design/adminhtml/default/default/template/page/head.phtml
patching file app/design/frontend/base/default/template/checkout/cart/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/billing.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/billing.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/payment.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml
patching file app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml
patching file app/etc/config.xml
patching file app/locale/en_US/Mage_Adminhtml.csv
patching file app/locale/en_US/Mage_Core.csv
patching file app/locale/en_US/Mage_Dataflow.csv
patching file downloader/Maged/Connect.php
patching file downloader/Maged/Controller.php
Hunk #1 succeeded at 400 (offset -5 lines).
Hunk #2 succeeded at 923 (offset -5 lines).
patching file downloader/Maged/Model/Session.php
Hunk #2 succeeded at 235 with fuzz 2 (offset -13 lines).
patching file js/varien/payment.js
patching file skin/frontend/base/default/js/opcheckout.js

incluso después de aplicar parches más antiguos manualmente.

$ grep '|' app/etc/applied.patches.list
2017-06-19 04:01:42 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-19 04:03:26 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
2017-06-19 04:04:12 UTC | SUPEE-1049 | EE_1.12.0.2 | v1 | 5cd884653325315804056d4c591572385b3c1d03 | Thu Mar 20 16:33:19 2014 +0200 | v1.12.0.2..HEAD
2017-06-19 04:05:01 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-19 04:06:38 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-19 04:07:10 UTC | SUPEE-1533 | EE_1.12 | v1 | _ | n/a | SUPEE-1533_EE_1.12_v1.patch
2017-06-19 04:08:41 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-19 04:09:29 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-19 04:10:00 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-19 04:11:22 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-19 04:11:50 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-19 04:12:12 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-19 04:14:30 UTC | SUPEE-8167 | EE_1.12.0.2 | v1 | b1be28f9cd8c2ecba2aa403e59ad9e3d2855eb95 | Thu May 4 13:52:13 2017 +0300 | 8d12ea6fe564b6dc9ed1affb6de990f81aca3796..HEAD
2017-06-19 04:16:21 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-19 04:16:44 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523
2017-06-19 04:19:35 UTC | SUPEE-6788 | CE_1.7.0.2 | v1 | 0398c4b951d9a0f64495e7b8b3b8ca480952dd70 | Fri Oct 23 13:50:23 2015 +0300 | cfc252b

La solución / problema que encontré es que algunos de los cambios en el parche para 1.7.0.2 son para archivos que no existen antes de 1.9.2.3. Así que copié los siguientes archivos de una nueva instalación 1.9.2.3 antes de ejecutar el script de parche:

  • app / code / core / Mage / Core / Model / File / Validator / Image.php
  • app / code / core / Mage / Sales / Model / Quote / Item.php
Ricardo Martins
fuente
El parche asume que todos los demás parches de seguridad ya se han aplicado. Los archivos de los que está hablando fueron agregados / modificados por parches anteriores. Te falta al menos SUPEE-7405.
Ryan Hoerr
Hola Ryan: De hecho, también intenté aplicar 7405, pero tampoco funcionó ... $ ./PATCH_SUPEE-7405_CE_1.7.0.2_v1.1-2016-02-23-07-22-52 \ (1) .sh Comprobando si el parche se puede aplicar / revertir con éxito ... ERROR: El parche no se puede aplicar / revertir con éxito. (..) Adminhtml / Helper / Sales.php Hunk # 1 FALLÓ en 121. 1 de 1 trozo FALLÓ - guardar rechazos en el archivo (..) Adminhtml / Helper / Sales.php.rej parcheando el archivo (..) / Core / Model / Config.php Hunk # 1 FALLÓ en 1642. 1 de 1 trozo FALLÓ - guardar rechazos en el archivo (..) Config.php.rej parcheando el archivo (..) / Quote / Item.php Hunk # 1 FALLÓ en 509 ....
Ricardo Martins
@RicardoMartins, ¿cómo puedo resolver este error? ?
zus
0

Solo una adición a https://magento.stackexchange.com/a/176930/46249

Tenga en cuenta que los enlaces simbólicos siempre se han deshabilitado de manera predeterminada en las nuevas instalaciones de Magento admin. Los valores de configuración SÍ / NO están predeterminados en 'NO'. La actualización ahora desactiva explícitamente los enlaces simbólicos en config.xml y, como precaución adicional, también elimina la sección de plantilla de admin-> developer que contenía la opción de configuración.

Esto no afectará su configuración actual de enlaces simbólicos, si habilitó manualmente los enlaces simbólicos anteriores a 1.9.3.2, permanecerán habilitados, aunque ya no podrá ver la configuración en admin.


El texto en negrita no es correcto. Si se actualiza a 1.9.3.4 (SUPEE-9767 V2) o se eliminará la configuración actual más reciente:

# app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.6-1.6.0.7.php
$connection->delete(
    $this->getTable('core_config_data'),
    $connection->prepareSqlCondition('path', array(
        'like' => 'dev/template/allow_symlink'
    ))
);

Los administradores responsables pueden habilitar nuevamente la sección de administración del enlace simbólico buscando los cambios de diferencias en la sección de plantilla en app / code / core / Mage / Core / etc / system.xml y agregando la sección a su system.xml en la línea 600. O los enlaces simbólicos de doble verificación todavía están habilitados con

Solo hacer que la opción de configuración sea visible nuevamente no resuelve el problema. Aparece la opción, pero no puede cambiar la configuración ya que el modelo de backend recientemente introducido evita guardar el valor. Ver:

# app/code/core/Mage/Core/etc/system.xml
<backend_model>adminhtml/system_config_backend_symlink</backend_model>

y

# Mage_Adminhtml_Model_System_Config_Backend_Symlink
public function save()
{
    return $this;
}

Entonces, debe eliminar o anular este modelo de back-end, consulte ¿Cómo habilitar los enlaces simbólicos después de la instalación de SUPEE-9767 V2?

sv3n
fuente