Patch de segurança SUPEE-10570 - Possíveis problemas?

45

O Magento lançou um novo patch de segurança para o M1 e atualizações para o M1 e o M2.

Quais problemas devo procurar ao atualizar ou aplicar este patch?

SUPEE-10570

SUPEE-10570, Magento Commerce 1.14.3.8 e Open Source 1.9.3.8 contêm vários aprimoramentos de segurança que ajudam a fechar a execução remota de código (RCE), scripts entre sites (XSS e outros problemas). Essas versões também incluem pequenas correções funcionais listadas no notas de lançamento.

ATUALIZAÇÃO DE SEGURANÇA DO MAGENTO 2.2.3, 2.1.12 E 2.0.18

O Magento Commerce e o Open Source 2.2.3, 2.1.12 e 2.0.18 contêm vários aprimoramentos de segurança que ajudam a fechar o Cross-Site Scripting (XSS), a autenticação remota de código do usuário Admin autenticada (RCE) e outras vulnerabilidades. Os lançamentos incluem correções funcionais adicionais. Para descobrir mais sobre as correções funcionais, consulte as Notas de versão do Magento Commerce 2.0.18, 2.1.12, 2.2.3 e Magento Open Source 2.0.18, 2.1.12, 2.2.3.

Ryan Hoerr
fonte
1
Para o Open Source / Community Edition 1.x, nenhuma alteração de modelo de front-end parece estar incluída; portanto, pelo menos, isso não deve criar muitos problemas. No entanto - um backup do banco de dados é altamente recomendado, pois há dois scripts de instalação (atualização) incluídos neste patch. Mais detalhes podem ser obtidos após a correção dos primeiros ambientes.
Christoph Farnleitner 27/02
1
Se você tem lojas usando uma grade de administração personalizada que inclui o nome da loja, o patch agora a escapa, provavelmente para corrigir algumas explorações em potencial com base na alteração do nome e na renderização da loja.
Andrew Quackenbos
Até agora, corrigi 2 sites no 1.9.0.1 sem problemas.
asdfasdfasf 27/02
1
Eu apliquei o patch 1.9.3.0, 1.9.0.1 e 1.9.1.0, até agora sem problemas
David
2
Isso é do blog de segurança: magento.com/security/patches/supee-10570 NOTA: Alguns clientes estão com problemas no checkout ao tentar criar uma conta durante o check-out. Um patch de atualização ou uma solução alternativa para corrigir esse problema estará disponível em breve. Se você está enfrentando esse problema no momento, considere reverter a parte do código que está causando esse problema, aplicando o seguinte patch: invalid_sesssion_fix.patch da seção Arquivos de Lançamento, SUPEE-10570
The Tankgirl

Respostas:

29

Aqui está a lista de arquivos modificados pelo patch SUPEE-10570:

app/Mage.php 
app/code/core/Mage/Admin/Helper/Data.php
app/code/core/Mage/Admin/Model/Block.php 
app/code/core/Mage/Admin/Model/Resource/Block.php 
app/code/core/Mage/Admin/Model/User.php 
app/code/core/Mage/Adminhtml/Block/Catalog/Category/Edit/Form.php 
app/code/core/Mage/Adminhtml/Block/Catalog/Product/Grid.php 
app/code/core/Mage/Adminhtml/Block/Newsletter/Template/Grid/Renderer/Sender.php 
app/code/core/Mage/Adminhtml/Block/Sales/Order/Grid.php 
app/code/core/Mage/Adminhtml/Block/Sales/Order/View/Info.php 
app/code/core/Mage/Adminhtml/Block/System/Store/Edit/Form.php 
app/code/core/Mage/Adminhtml/Block/Tag/Assigned/Grid.php 
app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Renderer/Store.php 
app/code/core/Mage/Adminhtml/Block/Widget/Tabs.php 
app/code/core/Mage/Adminhtml/Model/Config/Data.php 
app/code/core/Mage/Adminhtml/Model/System/Store.php 
app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php 
app/code/core/Mage/Adminhtml/controllers/CustomerController.php 
app/code/core/Mage/Adminhtml/controllers/System/BackupController.php
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
app/code/core/Mage/Core/Model/Variable.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php
app/code/core/Mage/Customer/controllers/AccountController.php
app/code/core/Mage/Customer/etc/config.xml
app/code/core/Mage/Customer/sql/customer_setup/upgrade-1.6.2.0.1.1.1-1.6.2.0.1.1.2.php
app/code/core/Mage/Downloadable/etc/config.xml
app/code/core/Mage/Downloadable/etc/system.xml
app/code/core/Mage/Downloadable/sql/downloadable_setup/upgrade-1.6.0.0.2.1.1-1.6.0.0.2.1.2.php
app/code/core/Mage/ImportExport/Model/Import.php
app/code/core/Mage/ImportExport/Model/Import/Entity/Product.php
app/code/core/Mage/Shipping/Model/Info.php
app/code/core/Mage/Widget/controllers/Adminhtml/Widget/InstanceController.php
app/design/adminhtml/default/default/template/catalog/product/attribute/set/main.phtml
app/design/adminhtml/default/default/template/customer/tab/view.phtml
app/design/adminhtml/default/default/template/customer/tab/view/sales.phtml
app/design/adminhtml/default/default/template/dashboard/store/switcher.phtml
app/design/adminhtml/default/default/template/downloadable/product/composite/fieldset/downloadable.phtml
app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable/links.phtml
app/design/adminhtml/default/default/template/downloadable/sales/items/column/downloadable/creditmemo/name.phtml
app/design/adminhtml/default/default/template/downloadable/sales/items/column/downloadable/invoice/name.phtml
app/design/adminhtml/default/default/template/downloadable/sales/items/column/downloadable/name.phtml
app/design/adminhtml/default/default/template/newsletter/preview/store.phtml
app/design/adminhtml/default/default/template/report/store/switcher.phtml
app/design/adminhtml/default/default/template/sales/order/view/info.phtml
app/design/adminhtml/default/default/template/store/switcher.phtml
app/design/adminhtml/default/default/template/store/switcher/enhanced.phtml
app/design/adminhtml/default/default/template/system/convert/profile/wizard.phtml
app/design/adminhtml/default/default/template/tax/rate/title.phtml
app/design/adminhtml/default/default/template/widget/form/renderer/fieldset.phtml
app/locale/en_US/Mage_Catalog.csv
app/locale/en_US/Mage_ImportExport.csv
lib/Zend/Mail/Transport/Sendmail.php

EDITAR

Finalmente, depois de implantar no site do meu produto (CE 1.7.0.2), notei um problema crítico de bloqueio (processo de pagamento bloqueado).

O contexto: após o endereço da etapa 1, eu crio E registro diretamente o cliente, ele deve ver apenas a próxima etapa da finalização da compra.

O problema: após o supee-10570, o processo de checkout é interrompido após a etapa 1 (no caso de criação da conta) e o cliente é redirecionado para a página inicial (com o carrinho de compras vazio + desconectado) = impossível realizar o checkout.

A correção de emergência: caso você encontre um problema semelhante com sua sessão de checkout / cliente, comente as linhas 414-430 de app / code / core / Mage / Core / Model / Session / Abstract / Varien.php (as adicionadas pelo patch , ver abaixo).

//         if ($this->useValidateSessionPasswordTimestamp()
//             && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
//             && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
//             && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
//             > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
//         ) {
//             return false;
//         }

//         if ($this->useValidateSessionExpire()
//             && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
//             && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
//             return false;
//         } else {
//             $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
//                 = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
//         }

EDIT (2)

Eu acho que a seguinte condição sempre retornará false (Mage_Core_Model_Session_Abstract_Varien nas linhas 414-419, especialmente as linhas 417 + 418).

if ($this->useValidateSessionPasswordTimestamp()
            && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
            && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
            && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
            > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
        ) {
        return false;

VALIDATOR_PASSWORD_CREATE_TIMESTAMP será sempre maior que VALIDATOR_SESSION_EXPIRE_TIMESTAMP. O registro de data e hora de "expiração" da sessão é redefinido na criação da conta, inevitavelmente mais antigo que o init da sessão.

Por exemplo, se você criar o cliente durante o checkout, isso retornará falso e o cliente será expulso (= finalizar o checkout, redirecionar para a página inicial e o carrinho vazio). Muito mal.

Eu relatei esse problema para a equipe magento. Vou dar um feedback aqui o mais rápido possível.


EDIT (3)

Um novo patch é o wip (na página de download do patch do magento, escreva "SUPEE-10570 para CE 1.7.0.0 - PATCH ATUALIZADO ESPERADO, NÃO USE (0,06 MB)").


EDIT (4) ~ 1 mês após o problema inicial de bloqueio relatado

Oi! Espero que todos sejam mercadorias (e espere que você não tenha mantido o estado inicial do patch até agora, a menos que a receita da sua empresa provavelmente tenha diminuído seriamente ^^).

Observei a seguinte frase da página oficial: "O Magento agora está fornecendo um patch atualizado (SUPEE-10570v2) que não causa mais esse problema. Observe, no entanto, que esse novo patch não protege mais contra duas tarefas relacionadas ao manuseio de sessões de baixo risco. problemas de segurança contra os quais o SUPEE-10570 está protegido. " da página oficial supee-10570.

Na página de lançamento, podemos finalmente encontrar o arquivo v2 (PATCH_SUPEE-10570_CE_v1.7.0.2_v2-2018-03-29-08-52-37.sh).

Eu investiguei as modificações em detalhes. Finalmente, parece que a equipe do magento decidiu deixar uma parte de segurança do patch. Espero que essa falha de segurança não cause danos graves (é pouco crítico de acordo com a nota oficial).

Depois de reverter v1 + aplicar v2, lembre-se de que os seguintes arquivos sejam revertidos como seu estado inicial (antes da aplicação da v1):

app/code/core/Mage/Adminhtml/controllers/CustomerController.php
app/code/core/Mage/Customer/controllers/AccountController.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php

PS: obviamente, alguns outros arquivos também são modificados, verifique em conformidade.

DarkCowboy
fonte
1
@ Ícone: eu acabei de relatar esse bug ao magento. Publicarei a resposta assim que receber um feedback oficial.
DarkCowboy
4
@ Ícone / Soleil: Infelizmente ainda não há resposta ou correção oficial em relação ao meu pedido de correção de bug.
precisa saber é o seguinte
1
@DarkCowboy Acabei de notar que, uma vez que você vá para a página de download de patches, poderá ver a equipe do Magento adicionar uma nota no patch 1.7.0.0 e 1.7.0.2. Parece que um novo patch está chegando.
Ícone
3
Olá a todos. Vi que um novo patch foi adicionado ("PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-28-04-54-53.sh"). Você pode ver a diferença aqui (o painel esquerdo é o 1º patch "PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-23-06-28-18.sh"): diffchecker.com/uGON91aR . Portanto, nenhuma correção para o novo patch ?! Além disso, o aviso "... ATUALIZADO PATCH ESPERADO, NÃO USAR" desapareceu. Então, estou um pouco confuso com o que a equipe principal do magento está fazendo com esse problema.
DarkCowboy
1
FYI, V2 do patch ainda lista "SUPEE-10570_CE_v1.9.2.4 | CE_1.9.2.4 | v1" emapp/etc/applied.patches.list
Moose
9

(não tenho certeza se isso estava nas notas de versão do começo)

Problemas conhecidos

Esses dois problemas conhecidos estão associados ao uso de tags HTML no atributo SKU de um produto:

  • Se você tentar importar produtos que contenham tags HTML no atributo SKU, o Magento exibirá esse erro no estágio de validação de dados (ou seja, quando você clicar em Verificar dados ):
 Invalid value in SKU column. HTML tags are not allowed.
  • Se você tentar criar ou editar um produto no painel Admin e o valor do atributo SKU do produto contiver tags HTML, o Magento emitirá esse erro ao tentar salvar o produto: HTML tags are not allowed in SKU attribute.

Nas notas de atualização :

Se o patch não for aplicado durante o patch lib/Zend/Mail/Transport/Sendmail.php, isso pode significar que a instalação do Magento foi corrigida anteriormente com SUPEE-9652v1 em vez de SUPEE-9652v2. A solução recomendada é reverter o patch SUPEE-9652v1 e aplicar SUPEE-9652v2 antes de aplicar o SUPEE-10570.

sv3n
fonte
7

Eu tive o mesmo problema que o @DarkCowboy depois de aplicar o patch ao Magento CE 1.7.0.2.

Depois de optar por me registrar como um novo cliente durante a finalização da compra, fazer o pedido cria o pedido e o cliente, mas, em vez de exibir a página de sucesso do pedido, sou redirecionado para a página inicial e desconectado.

A solução que encontrei é reverter a ordem dos blocos de código nas alterações para app/code/core/Mage/Core/Model/Session/Abstract/Varien.php.

Comparando a versão corrigida com o mesmo arquivo no Magento CE 1.9.3.8, encontrei os novos blocos para validar a expiração da sessão e o carimbo de data e hora da senha em uma ordem diferente.

Magento CE 1.9.3.8 - Linhas 476-491:

    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
        $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    }
    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;
    }

Magento CE 1.7.0.2 - Linhas 414-430:

    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;
    }

    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
        $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    }

Isso resulta no valor de $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]ser maior que $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime(), o que significa que o método sempre retorna falso e a validação falha.

Alterar o código no Magento CE 1.7.0.2 para corresponder à versão no Magento CE 1.9.3.8 corrige o problema.

O código resultante para Magento CE 1.7.0.2 - Linhas 414-430:


    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
        $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    }
    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;
    }

Sugiro que você crie seu próprio arquivo de correção e aplique diretamente no arquivo principal (é assim que eu costumo abordar a correção de bugs no núcleo). Isso facilitaria a reversão se o Magento emitir uma versão 2 do patch.

Dave Herbert
fonte
Oi Dave. Parece que você encontrou o mesmo problema que eu. Com relação à sua correção, com a inversão, a segunda condição não será testada ... Investigarei esses dados da sessão.
precisa saber é o seguinte
4
Atualização para 1.7.0.2 prevista para meados de março. (v2 do patch), o problema está confirmado.
Piotr Kaminski
Alguém já testou se essa solução realmente mantém a verificação do carimbo de data e hora da alteração de senha funcionando ou se reabre a falha de segurança que eles estavam tentando corrigir? Nota: Se você não se importa com o benefício de segurança, pode simplesmente desativar a verificação do carimbo de data e hora da alteração de senha, useValidateSessionPasswordTimestamp()retornando false. (uma mudança de linha no mesmo arquivo)
Eric Seastrand
Oi. Avaliamos que o problema "redirecionar com carrinho vazio" ainda existe com a ordem de validação alterada. Desativamos a verificação "useValidateSessionPasswordTimestamp" até que o magento crie uma atualização.
Steven Fritzsche
6

Vimos uma página em branco no / checkout / carrinho após aplicar o SUPEE-10570 e compilar. Apenas para esclarecer: com o compilador desativado, tudo correu bem; com o compilador ativado, só conseguimos ver uma página em branco do carrinho quando logado sem nenhuma entrada de log (mesmo depois de ativar todos os logs possíveis e modo de desenvolvedor).

A solução foi alterar a função getPasswordTimestamp()em app/code/core/Mage/Customer/Helper/Data.php(é claro que significa app/code/local/Mage/Customer/Helper/Data.php:!) E usar em Mage::getSingleton('core/resource')vez de Mage::getModel('customer/customer')ou Mage::getSingleton('customer/session'). Então substitua a função inteira, por exemplo, com estas linhas de código:

    $resource = Mage::getSingleton('core/resource');
    $readConnection = $resource->getConnection('core_read');
    $query = 'SELECT * FROM ' . $resource->getTableName('customer_entity').' WHERE `entity_id` = '.$customerId;
    $results = $readConnection->fetchAll($query);
    $result=$results[0];
    $date_created = Varien_Date::toTimestamp($result['created_at']);
    return $date_created;

Depois de recompilar o problema se foi. Mais alguém com esse problema?

Explicação em alemão aqui .

Bastian Kretzschmar
fonte
Essa é de várias maneiras diferentes alguns dos piores conselhos e códigos já vistos aqui. Por favor, não faça nada disso em casa.
pong
Exatamente o mesmo comigo. Este patch não está funcionando com o compilador ativado.
Rafael Patro
Em 1.9.3.9, ele funciona bem para mim.
precisa saber é o seguinte
4

1.7.0.0

Patch: PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh

Este erro ocorre se você ainda não aplicou o SUPEE-9652 ou SUPEE-9767

patching file lib/Zend/Mail/Transport/Sendmail.php
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 130.

Aplique esses patches para corrigir o problema.

Tyler V.
fonte
2
Certifique-se de que você tem 9652 e 9767 instalado
Ícone
De fato, testamos o SUPEE-10570 em todas as versões de baunilha do Magento desde 1.6.0.0 e tudo funciona. Mas somente se você aplicou todos os patches anteriores. Aqui você pode procurar quais correções são necessárias: docs.google.com/spreadsheets/d/…
Jeroen Vermeulen - MageHost
4

1.7.0.0

PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh Arquivo de Patchapp/code/core/Mage/Core/Model/Session/Abstract/Varien.php

O patch para 1.7.0.0 adiciona apenas uma constante:

+    const VALIDATOR_PASSWORD_CREATE_TIMESTAMP   = 'password_create_timestamp';

No entanto, adiciona o uso de duas novas constantes, notadamente esta:

+        if ($this->useValidateSessionPasswordTimestamp()
+            && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
+            && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
+            && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
+            > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
+        ) {
+            return false;
+        }

Isso resulta no erro:

PHP Fatal error:  Uncaught Error: Undefined class constant 'VALIDATOR_SESSION_EXPIRE_TIMESTAMP' in 
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php:406
Stack trace:
#0 
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php(358): Mage_Core_Model_Session_Abstract_Varien->_validate()
#1 
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php(176): Mage_Core_Model_Session_Abstract_Varien->validate()
#2 
app/code/core/Mage/Core/Model/Session/Abstract.php(84): Mage_Core_Model_Session_Abstract_Varien->init('core', 'frontend')
#3 
app/code/core/Mage/Core/Model/Session.php(42): Mage_Core_Model_Session_Abstract->init('core', 'frontend')
#4 
app/code/core/Mage/Core/Model/Config.php(1354): Mage_Core_Model_Session->__construct(Array)

O conserto:

Adicione uma definição para esta segunda constante acima ou abaixo da primeira constante adicionada por este patch.

const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';

Até agora não vi esse problema em nenhum dos 1,9. ou 1.14.x patches, porque eles definem a constante corretamente.

Tyler V.
fonte
Isso foi corrigido adicionando const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';ao topo do arquivo, como é feito na maioria das outras versões deste patch.
Tyler V. #
Yep parece ser específico para 1.7.0.0 remendo
danmentzer
Tyler, você pode adicionar a correção à sua resposta real e não à seção de comentários.
precisa saber é o seguinte
1
Também gostaria apenas de notar que isso também efeitos patches para a versão EE do patch bem EE 1.12.0.0
danmentzer
3

A primeira coisa que você deve verificar, se você aplicou a versão correta do SUPEE-6788 ou SUPEE-7405 anteriormente, se não reverter a versão errada e, em seguida, aplique a versão correta do SUPEE-6788 / SUPEE-7405.

Em seguida, tente novamente aplicar o SUPEE-10570.

Vio
fonte
2

Os arquivos abaixo são atualizados / adicionados após o patch aplicado SUPEE - 10570 no EE

O @DarkCowboy forneceu uma lista de arquivos diferentes dos arquivos EE :

    app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Hierarchy/Edit/Form.php
    app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Hierarchy/Widget/Chooser.php
    app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Page/Edit/Tab/Hierarchy.php
    app/code/core/Enterprise/Cms/Block/Hierarchy/Menu.php
    app/code/core/Enterprise/Customer/Block/Adminhtml/Customer/Attribute/Edit/Tab/Main.php
    app/code/core/Enterprise/GiftRegistry/Model/Observer.php
    app/code/core/Enterprise/Reward/Block/Adminhtml/Customer/Edit/Tab/Reward/Management/Update.php
    app/code/core/Enterprise/Rma/Model/Shipping/Info.php
    app/code/core/Enterprise/Staging/Block/Adminhtml/Backup/Grid.php
    app/code/core/Enterprise/Staging/Block/Adminhtml/Staging/Grid.php
 app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/edit.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/scope/switcher.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/widget/radio.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/page/preview/store.phtml
    app/design/adminhtml/default/default/template/enterprise/customer/website/switcher.phtml
    app/design/adminhtml/default/default/template/enterprise/invitation/view/tab/general.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/log/information/create.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/staging/edit/tabs/website.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/staging/edit/tabs/website/store.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/staging/merge/settings/website.phtml
    app/design/adminhtml/default/default/template/enterprise/store/switcher.phtml
    app/design/adminhtml/default/default/template/enterprise/store/switcher/enhanced.phtml
    app/design/adminhtml/default/default/template/merchandiser/new/page/html/top-buttons.phtml
    app/design/frontend/enterprise/default/template/cms/hierarchy/pagination.phtml

Algumas notas importantes

password_created_at criado na tabela de atributos do cliente.

app/code/core/Mage/Adminhtml/controllers/CustomerController.php
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php
app/code/core/Mage/Customer/controllers/AccountController.php
app/code/core/Mage/Customer/sql/customer_setup/upgrade-1.6.2.0.5.1.1-1.6.2.0.5.1.2.php

Os arquivos acima são usados ​​para criação e validação. Quando um problema de sessão ocorre na finalização da compra ou na verificação de logon do usuário, qualquer um dos arquivos acima é substituído no pool local ou Qualquer password_created_atatributo é criado na tabela de atributos do cliente e o valor apropriado é armazenado nessa tabela.

Rama Chandran M
fonte
Não foi possível encontrar o password_created_at no banco de dados do CE, onde o problema também é fornecido.
TonkBerlin 02/04/19
verificar este arquivo app / code / core / Mago / Cliente / sql / customer_setup / upgrade-1.6.2.0.5.1.1-1.6.2.0.5.1.2.php
Rama Chandran M
2

Minha versão do magento é ver. 1.9.1.0

Vimos uma página em branco no / checkout / carrinho após aplicar o SUPEE-10570 e compilar. Apenas para esclarecer: com o compilador desativado, tudo correu bem; com o compilador ativado, só conseguimos ver uma página em branco do carrinho quando logado sem nenhuma entrada de log (mesmo depois de ativar todos os logs possíveis e modo de desenvolvedor).

Causa:

  1. a função getPasswordTimestamp será chamada duas vezes quando estiver logado e visite / checkout / carrinho.

  2. compilador desabilitado tanto o trabalho de invocação.

  3. habilitar o compilador apenas o primeiro trabalho de chamada, a segunda chamada falhou.

alguém pode explicar e dar a boa solução?

jun
fonte
2

Um problema com o 1.7.0.2 que notei é o seguinte:

  1. Adicione o produto ao carrinho e vá ao Google Checkout

  2. Clique em "Register"

  3. Preencha todas as informações necessárias sobre o pedido, incluindo detalhes de pagamento, etc.
  4. Clique em Pedido completo.

O PROBLEMA COMEÇA AQUI

5. Redirecionar automaticamente para a página inicial. Você não vê a confirmação do número do pedido. Mas, na realidade, o pedido é feito e a conta do cliente criada.

Ícone
fonte
você encontrou alguma solução para isso? Eu estou enfrentando o mesmo problema.
Parth Thummar 06/04
1
V2 de patch é para fora, problema resolvido
Ícone
2

Eu encontrei o mesmo problema, o Magento 1.9.3.8 adicionou esse método à classe Mage_Customer_Helper_Data

/**
 * Get customer password creation timestamp or customer account creation timestamp
 *
 * @param $customerId
 * @return int
 */
public function getPasswordTimestamp($customerId)
{
    /** @var $customer Mage_Customer_Model_Customer */
    $customer = Mage::getModel('customer/customer')
        ->setWebsiteId(Mage::app()->getStore()->getWebsiteId())
        ->load((int)$customerId);
    $passwordCreatedAt = $customer->getPasswordCreatedAt();

    return is_null($passwordCreatedAt) ? $customer->getCreatedAtTimestamp() : $passwordCreatedAt;
}

Se você substituir essa classe na pasta Local (não é a melhor prática), poderemos ter erros gerados por essa classe.

phanvugiap
fonte
2

Esse patch quebrou alguns dos gerenciadores de hierarquia do CMS para usuários de EE.

Isso ocorre devido à seguinte linha de correção, responsável por escapar dos nomes das lojas / sites e corrigir o APPSEC-1873/1979/1980.

diff --git app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
index e45298c..8bee617 100644
--- app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
+++ app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
@@ -36,7 +36,7 @@
             <div class="cms-popup-description"></div>
             <div class="fieldset">
                 <div class="cms-hierarchy manage-form">
-                    <?php echo $this->getFormHtml() ?>
+                    <?php echo $this->escapeHtml($this->getFormHtml()); ?>
                 </div>
             </div>
         </div>

Ele deve mostrar o seletor de loja à esquerda, mas mostra o html à direita. Se você realmente precisar dessa funcionalidade, precisará fazer uma chamada de segurança versus funcionalidade, o que não é ótimo.

mostrar hierarquia quebrada

Luke Rodgers
fonte
0

O mesmo erro exato de Tyler, no patch Magento 1.9.2.4 PATCH_SUPEE-10570_CE_v1.9.2.4_v1-2018-02-28-04-53-53.sh

checking file lib/Zend/Mail/Transport/Sendmail.php
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 129.
2 out of 2 hunks FAILED
Roy Toledo
fonte
verifique se você instalou o patch anterior. patch 9767 particular
Rama Chandran M
Fez uma verificação em www.magereport.com e confirmou que todos os patches também estavam instalados.
Roy Toledo
Vou verificar e fornecer ans
Rama Chandran M
1
@royToledo Certifique-se de que você aplicou remendo SUPEE-9652 bem
Tyler V.
0

Se você possui alguma ferramenta de detecção de patches, provavelmente precisará modificar a detecção SUPEE-9562 porque SUPEE-10570modifica o mesmo arquivo:

lib/Zend/Mail/Transport/Sendmail.php
OZZIE
fonte
0

O patch foi alterado pelo Magento silenciosamente. Aqui mostrado com patch para o Magento 1.8.1.0-1.9.0.1. No primeiro download eu tenho o arquivo

PATCH_SUPEE-10570_CE_v1.9.0.1_v1-2018-02-23-06-18-06.sh

Alguns dias depois eu tenho o seguinte arquivo

PATCH_SUPEE-10570_CE_v1.9.0.1_v1-2018-02-28-04-54-29.sh

Diff mostra que o arquivo anterior contém arquivos do Magento Enterprise Edition que contêm a licença incorreta "Contrato de licença do usuário final do Magento Enterprise Edition". Isso foi corrigido para "Open Software License (OSL 3.0)".

fheyer
fonte
0

Você pode receber o seguinte erro

Hunk #3 FAILED at 17 depois da linha

checking file app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Page/Edit/Tab/Hierarchy.php

Isso aconteceu comigo na versão Magento 1.10.0.2EE. Isso aconteceu porque o patch SUPEE-6285 não foi aplicado.

Mukesh
fonte