SUPEE-10975 Posibles problemas

16

SUPEE-10975 ha sido lanzado, sería genial saber si alguien tiene algún problema al intentar aplicar esto, ¿entrará en conflicto con el parche más reciente que agrega soporte 7.2?

Hasta ahora, estos son los archivos modificados que puedo ver 

app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
app/code/core/Mage/Adminhtml/Block/Newsletter/Template/Edit.php
app/code/core/Mage/Adminhtml/controllers/Cms/BlockController.php
app/code/core/Mage/Adminhtml/controllers/Customer/GroupController.php
app/code/core/Mage/Adminhtml/controllers/SitemapController.php
app/code/core/Mage/Adminhtml/controllers/System/BackupController.php
app/code/core/Mage/Captcha/Model/Observer.php
app/code/core/Mage/Captcha/Model/Zend.php
app/code/core/Mage/Captcha/etc/config.xml
app/code/core/Mage/Catalog/Model/Api2/Product/Image/Rest/Admin/V1.php
app/code/core/Mage/Catalog/Model/Product/Attribute/Media/Api.php
app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
app/code/core/Mage/Core/etc/config.xml
app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.7.1.1-1.6.0.7.1.2.php
app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
app/code/core/Mage/ImportExport/Model/Import/Entity/Customer.php
app/code/core/Mage/ImportExport/Model/Import/Entity/Customer/Address.php
app/code/core/Mage/Payment/etc/config.xml
app/code/core/Mage/Payment/etc/system.xml
app/code/core/Mage/Payment/sql/payment_setup/upgrade-1.6.0.0.1.1-1.6.0.0.1.2.php
app/code/core/Mage/Sendfriend/Block/Send.php
app/code/core/Mage/Wishlist/controllers/IndexController.php
app/code/core/Zend/Controller/Request/Http.php
app/design/adminhtml/default/default/template/cms/browser/content/files.phtml
app/design/frontend/base/default/layout/captcha.xml
app/design/frontend/base/default/template/wishlist/sharing.phtml
app/design/frontend/rwd/default/layout/page.xml
app/design/frontend/rwd/default/template/sendfriend/send.phtml
app/etc/modules/Mage_All.xml
app/etc/modules/Mage_Captcha.xml
app/locale/en_US/Mage_Wishlist.csv
js/lib/jquery/jquery-1.12.0.js
js/lib/jquery/jquery-1.12.0.min.js
js/lib/jquery/jquery-1.12.0.min.map
js/lib/jquery/jquery-1.12.1.js
js/lib/jquery/jquery-1.12.1.min.js
js/lib/jquery/jquery-1.12.1.min.map

¿Alguien ha tenido algún problema con estos cambios?

magento-1 security patches php-7.2 supee-10975 Razentic
fuente

Respuestas:

12

Hasta ahora, me he encontrado con los siguientes problemas con el parche SUPEE-10975:

  • Ya no es posible eliminar grupos de clientes a través del administrador debido a una falta de declaración de devolución en el nuevo método Mage_Adminhtml_Block_Customer_Group_Edit::getDeleteUrl(problema encontrado por @ mikhail-chelevich). Este es el caso cuando las claves secretas están habilitadas para el administrador, que es el valor predeterminado. El problema también está presente en 1.9.4.0. Este problema se soluciona con el parche SUPEE-11043, que no se ha lanzado oficialmente, pero está disponible como GitHub Gist .
  • El Mage_Sendfriendmódulo no se puede deshabilitar sin deshabilitar también el Mage_Captchamódulo. De lo contrario, se produce la siguiente excepción principal: Module "Mage_Captcha" requires module "Mage_Sendfriend".(problema encontrado por @zlep)
  • Los cambios en la sendfriend/send.phtmlplantilla que se han realizado en el rwd/defaulttema no se realizan en el base/defaulttema. Esto significa que para el base/defaulttema, CAPTCHA no se puede habilitar, y también que los nombres y correos electrónicos de los destinatarios ingresados ​​anteriormente no se muestran en la página (para el caso típico de un envío de formulario que desencadena un error de validación del lado del servidor).
  • El nuevo método Mage_Sendfriend_Block_Send::getRecipientsCountintroduce una incompatibilidad PHP 7.2 porque a countse realiza en un NULLvalor al cargar la página sin ningún destinatario (que es el valor predeterminado en la carga de página nueva). Este problema se ha solucionado en 1.9.4.0.

Tenga en cuenta que solo he revisado el parche para 1.9.3.10, pero sospecho que los problemas están presentes en todas las versiones del parche.

Aad Mathijssen
fuente
11

Falta return parent::getDeleteUrl()en app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php

+    public function getDeleteUrl()
+    {
+        if (!Mage::getSingleton('adminhtml/url')->useSecretKey()) {
+            return $this->getUrl('*/*/delete', array(
+                $this->_objectId => $this->getRequest()->getParam($this->_objectId),
+                'form_key' => Mage::getSingleton('core/session')->getFormKey()
+            ));
+        } else {
+            parent::getDeleteUrl();
+        }
+    }
Mikhail Chelevich
fuente
¿Para qué versión de Magento fue esto?
Danmentzer
1
Puedo confirmar este problema: ya no es posible eliminar grupos de clientes a través del administrador. Esto sucede cuando las claves secretas están habilitadas para el administrador, que es el valor predeterminado. Esto está presente en el parche SUPEE-10975, y también en Magento Open Source 1.9.4.0.
Aad Mathijssen
Se ha creado un parche adicional para resolver este SUPEE-11043
Andrew
@ Andrew No puedo encontrar nada sobre SUPEE-11043. ¿Puedes vincular algunas fuentes?
darnok
1
Entonces, la solución debe reemplazarse parent::getDeleteUrl();en app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php conreturn parent::getDeleteUrl();
René Schep
8

Me encontré con un problema con el parche 10975. Después de investigar un poco, pude localizar la respuesta sobre dónde estaba estropeando el parche y por qué.

Para resumir lo siguiente, verifique y asegúrese de parchear SUPEE 9767 V2 correctamente. Esa es la raíz de mi problema.

sh PATCH_SUPEE-10975_EE_v1.12.0.2_v1-2018-11-27-10-36-30.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file app/code/core/Enterprise/PageCache/Model/Processor.php
Hunk #1 succeeded at 690 (offset -3 lines).
patching file app/code/core/Enterprise/Pci/etc/config.xml
patching file app/code/core/Enterprise/Wishlist/Block/Customer/Sharing.php
patching file app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
patching file app/code/core/Mage/Adminhtml/Block/Newsletter/Template/Edit.php
patching file app/code/core/Mage/Adminhtml/controllers/Cms/BlockController.php
patching file app/code/core/Mage/Adminhtml/controllers/Customer/GroupController.php
patching file app/code/core/Mage/Adminhtml/controllers/SitemapController.php
patching file app/code/core/Mage/Adminhtml/controllers/System/BackupController.php
patching file app/code/core/Mage/Captcha/Model/Observer.php
patching file app/code/core/Mage/Captcha/Model/Zend.php
patching file app/code/core/Mage/Captcha/etc/config.xml
patching file app/code/core/Mage/Catalog/Model/Api2/Product/Image/Rest/Admin/V1.php
patching file app/code/core/Mage/Catalog/Model/Product/Attribute/Media/Api.php
patching file app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
patching file app/code/core/Mage/Core/etc/config.xml
Hunk #1 FAILED at 28.
1 out of 3 hunks FAILED -- saving rejects to file app/code/core/Mage/Core/etc/config.xml.rej
patching file app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.2.1.2-1.6.0.2.1.3.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
patching file app/code/core/Mage/ImportExport/Model/Import/Entity/Customer.php
patching file app/code/core/Mage/ImportExport/Model/Import/Entity/Customer/Address.php
patching file app/code/core/Mage/Payment/etc/config.xml
patching file app/code/core/Mage/Payment/etc/system.xml
patching file app/code/core/Mage/Payment/sql/payment_setup/upgrade-1.6.0.0.1.1-1.6.0.0.1.2.php
patching file app/code/core/Mage/Wishlist/controllers/IndexController.php
patching file app/code/core/Zend/Controller/Request/Http.php
patching file app/design/adminhtml/default/default/template/cms/browser/content/files.phtml
patching file app/design/adminhtml/default/default/template/enterprise/cms/page/preview/revision.phtml
patching file app/design/adminhtml/default/default/template/enterprise/customersegment/report/detail/grid/container.phtml
patching file app/design/adminhtml/default/default/template/enterprise/giftregistry/customer/form.phtml
patching file app/design/adminhtml/default/default/template/enterprise/staging/log/information/merge.phtml
patching file app/design/adminhtml/default/default/template/enterprise/staging/log/information/rollback.phtml
patching file app/design/frontend/base/default/layout/captcha.xml
patching file app/design/frontend/base/default/template/wishlist/sharing.phtml
patching file app/design/frontend/enterprise/iphone/template/downloadable/sales/order/creditmemo/items/renderer/downloadable.phtml
patching file app/etc/modules/Mage_All.xml
patching file app/etc/modules/Mage_Captcha.xml
patching file app/locale/en_US/Enterprise_Wishlist.csv
patching file app/locale/en_US/Mage_Wishlist.csv
patching file js/enterprise/adminhtml/staging.js

Arriba está el error que golpeé, que es específico de este archivo.

Mage / Core / etc / config.xml

El error proviene de esta línea del parche.

diff --git app/code/core/Mage/Core/etc/config.xml app/code/core/Mage/Core/etc/config.xml
index 4aebdcdc2cf..4b28f2765a1 100644
--- app/code/core/Mage/Core/etc/config.xml
+++ app/code/core/Mage/Core/etc/config.xml
@@ -28,7 +28,7 @@
 <config>
     <modules>
         <Mage_Core>
-            <version>1.6.0.2.1.2</version>
+            <version>1.6.0.2.1.3</version>
         </Mage_Core>
     </modules>
     <global>

La versión que se muestra aquí no coincide correctamente debido a los parches manuales

SUPEE 9767 v2

Ese parche vino con esta línea que me perdí al parchear manualmente.

diff --git app/code/core/Mage/Core/etc/config.xml app/code/core/Mage/Core/etc/config.xml
index 4a0ff1b..d0de702 100644
--- app/code/core/Mage/Core/etc/config.xml
+++ app/code/core/Mage/Core/etc/config.xml
@@ -28,7 +28,7 @@
 <config>
     <modules>
         <Mage_Core>
-            <version>1.6.0.2</version>
+            <version>1.6.0.2.1.2</version>
         </Mage_Core>
     </modules>
     <global>
danmentzer
fuente
5

En primer lugar, perdón por el duplicado de la respuesta de erej , no puedo comentar ni editar debido a mi puntaje de reputación.

El parche crea un nuevo archivo aquí: app/code/core/Zend/Controller/Request/Http.php

Que se agrega para anular este archivo: lib/Zend/Controller/Request/Http.php

El problema es para Magento bajo 1.9.0.0 (EE 1.14.0.0):

Este método : 

/**
 * Everything in REQUEST_URI before PATH_INFO
 * <form action="<?=$baseUrl?>/news/submit" method="POST"/>
 *
 * @return string
 */
public function getBaseUrl($raw = false)
{
    if (null === $this->_baseUrl) {
        $this->setBaseUrl();
    }

    return (($raw == false) ? urldecode($this->_baseUrl) : $this->_baseUrl);
}

Se anula en el archivo Magento Core app/code/core/Mage/Core/Controller/Request/Http.php

public function getBaseUrl()
{
    $url = parent::getBaseUrl();
    $url = str_replace('\\', '/', $url);
    return $url;
}

Lo cual no toma ningún argumento.

Por lo tanto, activa este aviso estricto en cualquier url, front y admin del sitio web:

Strict Notice: Declaration of Mage_Core_Controller_Request_Http::getBaseUrl() should be compatible with Zend_Controller_Request_Http::getBaseUrl($raw = false) in /var/www/htdocs/app/code/core/Mage/Core/Controller/Request/Http.php on line 36

Si alguien sabe si hay algún V2 de ese parche en camino, avíseme.

A la espera de su actualización, puede redefinir el método de app/code/core/Mage/Core/Controller/Request/Http.phpesta manera:

/**
 * @param bool $raw - Added manually to correct SUPEE-10975 oversight
 *      See /magento/251317/supee-10975-potential-issues
 *      for more information
 *
 * @return mixed|string
 */
public function getBaseUrl($raw = false)
{
    $url = parent::getBaseUrl($raw); // Argument added manually to correct SUPEE-10975 oversight
    $url = str_replace('\\', '/', $url);
    return $url;
}
jdemandre
fuente
4

Con la versión 1.8.1.0 después de aplicar este parche también tuvimos que cambiar la app/code/core/Mage/Core/Controller/Request/Http.php::getBaseUrl()función para ser

public function getBaseUrl($raw = false)
{
    $url = parent::getBaseUrl($raw);
    $url = str_replace('\\', '/', $url);
    return $url;
}

porque este parche añade app/code/core/Zend/Controller/Request/Http.phparchivo y getBaseUrl()función se declara con el parámetro $raw = false.

erej
fuente
No debería ser necesario agregar esta función. Siempre se establecerá de forma predeterminada como no sin formato, porque cualquier funcionalidad que llame a esta función no debería tener $ raw configurado en 1.8.1.
René Schep
4

Tengo un problema con 'Hunk # 1 FAILED at 28'

Supuestamente, los rechazos se guardan en config.xml.rej pero este archivo no existe, tampoco hay una descripción de qué parte del script falló en mi ventana de terminal. Básicamente, el parche falla y no hay indicación de por qué, ¡al menos no para un idiota como yo!

En la primera ejecución, el parche intentó eliminar tres archivos jquery v 1.12.0 que no existían, los reemplacé y apliqué el parche nuevamente, pero ahora falla sin ninguna descripción útil.

Magento 1.9.0.1 completamente parcheado aparte de la actualización de compatibilidad PHP 7.2, permanecerá sin parchear a menos que pueda resolverlo o alguien aquí pueda darme una pista (¡por favor!) Gracias H

PD No estoy seguro de si mi publicación infringe las pautas de SE, estoy respondiendo la pregunta original pero también estoy pidiendo ayuda.

Sparko
fuente
1
Me encontré con este problema, también está relacionado con el parche 9767 v2, agrega un nuevo número de versión a Mage / Core / etc / config.xml. Solo debería agregar al número de versión actual .1.2 También escribiré Una respuesta para esto también.
Danmentzer
3

El Mage_Backupmódulo será deshabilitado por el parche.

Esto se menciona en las notas de la versión oficial ( https://devdocs.magento.com/guides/m1x/ce19-ee114/ce1.9_release-notes.html#ce19-1940 ).

Sin embargo, la solución sugerida para volver a habilitarla es incorrecta:

("Alternativamente, puede usar uno de estos dos métodos para habilitar las copias de seguridad de la base de datos")

En realidad, debe usar los dos métodos mencionados para volver a habilitarlo por completo.

poebel
fuente
2
Recuerde también que volver a habilitar el módulo Mage_Backup lo abre a: "problemas de ejecución remota de código (RCE), scripting entre sitios (XSS) y falsificación de solicitudes entre sitios (CSRF)".
René Schep
2

Puede haber problemas con el manejo correcto del cálculo de impuestos .

Como es habitual en muchos países, nuestro cliente utiliza la configuración de " precios incluyen impuestos " de Magento.

Entonces, después de la actualización de 1.9.3.10 a 1.9.4.0, el impuesto se agregó al total general al finalizar la compra, además de los precios de los artículos que ya incluyen impuestos.

Seguí el problema hasta un cambio en la configuración en el archivo app / code / core / Mage / Sales / etc / config.xml , donde se agregó " msrp " al nodo sales / quote / totals / shipping / after .

No encontré nada sobre MSRP en las notas de la versión y espero que este sea un cambio aislado sin ningún efecto secundario.

Mi solución fue cambiar este nodo a su valor original " subtotal, freeshipping, tax_subtotal " sin el " msrp ". Lo hice en el etc / config.xml de mi propio módulo.

tdk_qst
fuente
1

Problema específico, pero si deshabilitó Mage_Sendfriend (que anteriormente era un módulo que podía deshabilitar de manera segura) arrojará un error de excepción.

zlep
fuente
1
Hicieron que Mage_Captcha dependiera de Mage_Sendfriend en lugar de al revés. Por lo tanto, también debe desactivar Mage_Captcha para deshabilitar Mage_Sendfriend. Lo que podría no ser lo que desea porque deshabilita todos los recaptcha predeterminados de Magento
René Schep
0

Traté de actualizar Magento CE 1.9.3.10 a 1.9.4.0 hoy y tuve múltiples errores. Afortunadamente no estropeó la instalación. Después de la instalación recibí el temido - Error interno del servidor. Me bloquearon y tuve que restablecer todos mis permisos de archivos y carpetas a través de SSH junto con la eliminación de maintenance.flag. Luego reindexé y volví a habilitar el caché. Además, tuve que volver a mi antiguo archivo .htaccess en la carpeta Root and Download. No estoy seguro de cuál debería ser la acción correctiva para obtener una instalación exitosa. Olvidé copiar el texto desde la ventana de la línea de comandos. Entonces no puedo publicar todos los errores. Lo que vi fueron mensajes incompatibles.

Neal Hart
fuente
1
No creo que el método de "actualización" a través del programa de descarga haya funcionado en ninguna instalación que esté al menos un poco editada. ¿Estoy loco?
Kalvin Klien
El método de "actualización" que utiliza Magento Connect funciona cada vez para mí. Lo uso para nuestros tres sitios M1 y todos están muy personalizados (aunque correctamente).
MagentoAaron
0

¿Quitaron la copia de seguridad programada? Sin sección de copia de seguridad programada

¿O tengo algún tipo de problema? ¿Por qué no se menciona esto en ninguna de las notas? Este parece ser un patrón con Magento en el que no mencionan cambios como estos cuando salen actualizaciones.

ACTUALIZACIÓN: parece que lo eliminaron por completo de todas las versiones.

ACTUALIZACIÓN: tuvo que hacer copias de seguridad de manera diferente. Si alguien interesado publiqué algunos de los comandos CRON aquí: ¿ Publicación de estrategia de respaldo SUPEE-10975?

Kalvin Klien
fuente
¿Es esto para alguna versión específica?
Razentic
2
Por twitter.com/ryanhoerr/status/1067819214314987520 Esa es una parte específica que eliminaron por este parche.
Danmentzer
Oh dios ... ok clásico - tengo que averiguarlo en otra fuente y luego en magento sobre la eliminación / adición de funciones.
Kalvin Klien
1
@KalvinKlien en realidad, el primer párrafo de las notas de la versión indica que se ha desactivado; devdocs.magento.com/guides/m1x/ce19-ee114/…
Peter Jaap Blaakmeer
3
El cambio en este parche es que Mage_Backup está desactivado por defecto y las comprobaciones para ejecutar el código son más estrictas (por ejemplo, si la salida de bloque para el módulo está desactivada, las copias de seguridad no se ejecutarán). Todavía puede volver a habilitar manualmente el módulo cambiando falso a verdadero en la sección Mage_Backup de la aplicación / etc / modules / Mage_All.xml. Tenga cuidado de que volver a habilitar la funcionalidad de respaldo potencialmente permita: "problemas de ejecución remota de código (RCE), scripting entre sitios (XSS) y falsificación de solicitudes entre sitios (CSRF)".
René Schep
0

Vimos un problema en un sitio que estaba utilizando una configuración personalizada de varias tiendas por un desarrollador anterior. Todas las URL de las tiendas que no sean la tienda base eran 404ing. Estableció la variable de servidor "HTTP_X_REWRITE_URL" / Encabezado HTTP, que cambió la URL procesada por la Solicitud de Magento.

Esta variable es / fue utilizada por \ Zend_Controller_Request_Http :: setRequestUri (), pero la nueva versión en app / code / core / Zend / Controller / Request / Http.php ya no usa esto. Las posibles soluciones fueron:

  • Establezca $ _SERVER ["IIS_WasUrlRewritten"] en '1' y, en su lugar, establezca $ _SERVER ["UNENCODED_URL"]
  • Establezca $ _SERVER ["REQUEST_URI"] en su lugar

Cualquiera de los dos probablemente funcionaría, pero es probable que el primero tenga menos consecuencias no deseadas, ya que funciona más cerca del sistema anterior.

Li1t
fuente
0

El error específico con el método de pago no está disponible

The requested Payment Method is not availableMagento arrojó muchos errores. Todo en pedidos en los que el método de pago en la devolución del producto era ccsave, que fue eliminado por este supee en config.xml.

El error se produce porque Magento está buscando un $key(ccsave el método de pago en este caso) por el control de las rutas de xml: payment/ccsave/model. Si no lo encuentra, arroja un error. Así que acabamos de hacer un git checkout [insert supee commit]^ app/code/core/Mage/Payment/etc/config.xmly empujamos a maestro para corregir el error.

app / code / core / Mage / Payment / Helper / Data.php

public function getMethodInstance($code)
{
    $key = self::XML_PATH_PAYMENT_METHODS.'/'.$code.'/model';
    $class = Mage::getStoreConfig($key);
    return Mage::getModel($class);
}

app / code / core / Mage / Payment / etc / config.xml

<default>
  <payment>
      <ccsave>
        <model>payment/method_ccsave</model>
      </ccsave>
  </payment>
  ...
</default>
mikemols
fuente
-5

Probablemente no, pero la versión 1.9.4.0 ya tiene ambas implementadas de todos modos.

Ricardo Martins
fuente
1
Estas publicaciones de pila son específicamente para que otros desarrolladores puedan conocer los problemas. Su respuesta a esto no es útil ni descriptiva sobre ningún problema. Sinceramente, simplemente eliminaría esto.
danmentzer