Um novo patch de segurança está disponível para o Magento 1, abordando 16 questões do APPSEC: https://magento.com/security/patches/supee-9767

Sete das vulnerabilidades têm pontuação 8.0 ou superior para a Gravidade CVSSv3 e estão sendo exploradas na natureza, portanto, esse é um patch crítico. Os sites podem aplicar SUPEE-9767 ou atualizar para a nova versão CE 1.9.3.3 / EE 1.14.3.3.

Quais são os problemas ou armadilhas comuns a serem observados ao aplicar o SUPEE-9767?

ATUALIZAÇÃO 12-07-2017:

O Magento lançou o SUPEE-9767 V2 e o CE 1.9.3.4 para resolver muitos dos problemas do patch inicial. Se você aplicou a V1, você deve reverter e aplicar a V2. Se você ainda não fez o patch, aplique a V2 e a maioria dos problemas apresentados aqui não será relevante.

Aqui está minha visão geral do patch depois de cavá-lo

ECONOMIA DE TEMPO : O Experius fornece um auxiliar de correção que ajuda a encontrar os arquivos em temas personalizados, módulos personalizados ou substituições locais que também precisam ser corrigidas manualmente , você pode encontrá-lo aqui: https://github.com/experius/Magento- 1-Experius-Patch-Helper # magento

Teclas do formulário de pagamento

Como dito na outra postagem, esse patch adiciona chaves de formulário aos seguintes formulários:

Formulário de carrinho de remessa:

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

Formulário de verificação de faturamento multiponto:

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

Formulário de verificação de remessa multishipping:

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

Formulário de check-out de endereços multiponto:

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

Formulário de pagamento da cobrança:

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

Formulário de pagamento da remessa:

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

Formulário de pagamento:

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

Forma de envio:

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

Formulário de pagamento de faturamento persistente:

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

Além disso, os seguintes arquivos JS foram atualizados para serem compatíveis com essa alteração:

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

O que fazer:

Se você estiver usando versões personalizadas desses modelos, precisará atualizá-los adicionando o seguinte código:

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

Se você estiver usando um módulo de checkout de terceiros, precisará entrar em contato com eles para que eles possam fornecer uma versão atualizada do módulo.

Além disso, se você tiver versões personalizadas dos arquivos JS listados anteriormente, precisará atualizá-los também.

ECONOMIZE SEU TEMPO :

Fabian Schmengler escreveu um ótimo script para atualizar todas essas coisas para você, você pode encontrá-lo aqui:

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

NOTA IMPORTANTE : a validação da chave de formulário de check-out pode ser alterada no back-end por meio de um novo campo de configuração em Sistema> Configuração> Admin> Segurança> Ativar validação de chave de formulário no check- out . ISTO NÃO É HABILITADO POR PADRÃO, portanto, será necessário habilitá-lo para se beneficiar desse recurso de segurança !!! Observe que você receberá um aviso no back-end se não estiver ativado.

Retorno de chamada de upload de imagem

O controlador da galeria de imagens foi atualizado para adicionar um retorno de chamada de validação.

O que fazer

Se você estiver usando um módulo personalizado que faz o upload de imagens com um código parecido com este:

        $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);

Eu sugiro fortemente que você atualize esse código adicionando a seguinte parte:

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

Symlinks

Esse patch remove o campo de configuração do sistema que permite permitir links simbólicos de modelo no back-end. Costumava estar em Sistema> Configuração> Desenvolvedor> Modelo> Permitir links simbólicos . Agora a seção inteira do modelo se foi.

Além disso, esse campo agora está desativado por padrão através do app/etc/config.xml

O engraçado aqui é que você receberá um aviso no back-end se tiver esse campo de configuração ativado antes do patch, mas não poderá desativá-lo à medida que o campo acabar.

A única maneira de fazer isso é executando a seguinte consulta SQL

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

Esclarecimento

Primeiro, sugiro fortemente que você verifique essas duas postagens que ajudarão a entender o objetivo dessa modificação do Symlink:

• De Peter O'Collaghan: https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/
• De Max Chadwick: https://maxchadwick.xyz/blog/what-allow-symlinks-actually-does

Essa modificação é realmente sobre chamar conteúdo carregável (como imagens) por meio de diretivas de modelo.

O problema relacionado aos links simbólicos é explorável apenas com acesso de administrador, e o Magento também adicionou mais proteção aos envios de imagens.

Observe que existem algumas proteções contra a maneira conhecida de explorá-lo, além da própria configuração.

O que fazer : se, como eu, você estiver usando modman ou compositor com links simbólicos de modelos, terá alguns problemas. Ainda estou tentando descobrir qual é a melhor coisa a fazer aqui além de lidar com consultas SQL.

Post principal sobre esse problema: SUPEE-9767, modman e links simbólicos

Lista de possíveis problemas

V2 foi lançado desde o post original. Não se esqueça de atualizar

Insetos

A palavra 'confirmado' é usada para erros confirmados. Se não estiver lá, isso significa que pode ser um bug, mas ainda não foi confirmado.

• O registro do cliente falha no checkout CONFIRMADO E CORRIGIDO NA V2
• Erro PHP7 e EE CONFIRMADO
• Erro com EE, FPC e exceções de design CONFIRMADAS
• Adicionar ao carrinho e bug de cookie no EE CONFIRMED
• Multishipping quebrado após o patch CONFIRMADO
• Correção de erro ausente emhead-simple.phtml CONFIRMADO E CORRIGIDO NA V2
• O aviso Symlink do administrador não é exibido no 1.9.2 CONFIRMADO E CORRIGIDO NA V2
• A marca d'água obtém um fundo preto quando transparente CONFIRMADO E CORRIGIDO NA V2
• Não foi possível atualizar via Magento Connect
• Loop de redirecionamento infinito na 1.6.0.0

Problemas com falha no pedaço

Observe que todos esses problemas podem ser simplesmente porque você modificou o arquivo original, para verificar se não é esse o caso:

• Faça backup do arquivo em que você obtém o erro Hunk Failed
• Baixe o arquivo original da sua versão do Magento
• Compare os dois arquivos

Se os arquivos forem diferentes, você deverá aplicar o patch ao arquivo original e reaplicar as alterações personalizadas da maneira mais limpa, como:

• modelo personalizado em uma pasta de temas personalizados
• local.xml
• aplicativo / código / arquivo local

Se os arquivos não forem diferentes, é um problema de permissão ou um "bug" no patch.

• aplicação de arquivo de patch / design / frontend / rwd / default / layout / page.xml Hunk # 1 falhou em 36.
• aplicação de arquivo de patch / design / front-end / empresa / padrão / modelo / persistente / checkout / onepage / billing.phtml Hunk # 1 FALHOU em 225.
• aplicação de arquivo de patch / code / core / Enterprise / PageCache / Model / Observer.php Hunk # 6 FALHOU em 1093.
• aplicação de arquivo de correção / code / core / Mage / Core / etc / system.xml Hunk # 3 FALHOU em 1355.
• aplicação de arquivo de patch / code / core / Mage / Sales / Model / Quote / Item.php Hunk # 1 FALHOU em 500.
• Hunk falhou em 1.8.0.0

Problema1: form_key inválido no checkout uma página

Magento adiciona form_keyna maioria dos formulários.

se você tiver using default onepage and using custom theme, começará a receber ** form_keyproblemas no checkout em cada etapa **;

você deve adicionar a chave do formulário em <?php echo $this->getBlockHtml('formkey') ?>

para formar os arquivos de cada etapa de checkout, se houver saída dos arquivos abaixo,

• 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

se os arquivos de modelo estiverem chamando do tema base , isso não criará problema. Porque o patch atualizará automaticamente esses arquivos.

Além disso, note: <?php echo $this->getBlockHtml('formkey') ?>deve sempre dentro da tag form

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

** Se você estiver usando o check-out de várias remessas do Magento, precisará fazer isso em

arquivos abaixo:

Issue2: problema form_key no formulário de estimativa de remessa na página do carrinho:

Adicionar form_key no formulário de envio estimado na página do carrinho

Em seguida, deve adicionar a chave do formulário <?php echo $this->getBlockHtml('formkey') ?>

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

Problema3: Erro do Magento onepage checkout opcheckout.js

Se você estiver usando o checkout de uma página padrão e tiver opcheckout.js verificado

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {está disponível em opcheckout.js

Caso contrário, substitua

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

com

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

No caso dos problemas 1, 2, 3, o problema pode ser corrigido facilmente usando o script add-checkout-form-key.sh do @FabianSchmengler . Isso corrigirá o problema nos arquivos de tema receptivo

Problema4: chave de formulário inválida após o login do cliente quando Mage_Customer_Model_Session reescreve

Se a Mage_Customer_Model_Sessionclasse reescrever ou tiver chamado de

app/code/local/Mage/Customer/Model/Session.phpvocê pode ter um problema form_key quando configuramos um cliente para a sessão usando setCustomerAsLoggedIn()/ ou depois de um cliente definido na sessão.

Nesse caso, você deve adicionar

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

em setCustomerAsLoggedIn () antes da chamada 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;
    }

Problema5: problema com Form_key após o logout

Após o logout do cliente da sessão , você poderá iniciar o problema da sessão se a Mage_Customer_Model_Sessionclasse Se reescrever ou tiver chamado de

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

Na mesma necessidade deste 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;
    }

Recomendação:

Recomendação1: Para corrigir o problema do supee-9767 , você pode usar o patch https://github.com/experius/Magento-1-Experius-Patch-Helper

Esta é uma melhor solução por enquanto.

Observe que , antes disso, é altamente recomendável fazer backup de arquivos e bancos de dados ou backup completo do sistema.

Recomendação2: Use o recurso de correção em seu ONESTEP CHECKOUT

Sabemos que a versão do patch supee-9767 para fins de segurança, se você estiver usando ONESTEP CHECKOUT, deverá adicionar a validação de form_key à ação SAVE do seu controlador de checkout onestep .

Suponha que, para salvar os detalhes do método de envio, seu check-out único use saveShippingmethod (). Em seguida, adicione

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

Também você deve adicionar uma chave de formulário <?php echo $this->getBlockHtml('formkey') ?> em sua seção de arquivos phtml do check-out da onestep

Algum link relacionado

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

Com base no meu primeiro passe na revisão do arquivo de correção ...

• Uma nova configuração admin/security/validate_formkey_checkoutfoi adicionada. Quando ativado, os formulários de checkout são verificados quanto à presença de uma chave de formulário. Se os arquivos de modelo forem substituídos no tema, eles precisarão ser atualizados lá. Essa configuração parece estar desativada por padrão
• Os links simbólicos parecem não ser permitidos por padrão (in app/etc/config.xml). Além disso, a capacidade de permiti-los parece ter sido removida da configuração do administrador. No entanto, se o site ativasse explicitamente links simbólicos anteriormente, a configuração seria salva no banco de dados, substituindo essa alteração.
• Você precisa limpar o cache E o cache de página inteira ao aplicar esse patch. As exceções de design são salvas em um formato incompatível com a decodificação. Você verá um erro como este "Falha na decodificação: erro de sintaxe" se você não liberar o cache da página.

Abaixo do base/defaultarquivo afetado com este patch, se esses arquivos estavam no seu tema, faça as alterações necessárias

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

em todos os phtmlarquivos acima, a linha de chave do formulário é adicionada; portanto, adicione essa linha no seu respectivo arquivo phtml.

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

Para a questão acima, o @fabian criou um script que adicionará a chave do formulário mesmo no seu arquivo de tema

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

depois de aplicar o patch de segurança, se você receber um erro para a chave do formulário, poderá aplicar esse patch, pois aplicar esse processo de patch é o mesmo que patch de segurança

  sh filename.sh

e uma base/defaultmudança no Jsarquivo

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

portanto, se este jsarquivo estiver carregando do seu tema, siga as etapas abaixo

remover linha de sopro

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

e adicione abaixo da linha em vez de acima

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

EDITAR

E se você estiver usando qualquer extensão de checkout que substitua os arquivos abaixo, adicione a linha de chave do formulário no arquivo phtml da extensão de checkout.

EDIT2 - Edições

1) Erro em saveBillingAction () ou obtenção de chave de formulário nula Ou problema com chave de formulário: Patch 9767 obtendo chave de formulário inválida

2) Hunk # 1 FALHOU em 225. 1 em 1 hunk FAILED - salvar rejeições no arquivo app / design / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtml: SUPEE-9767 - Hunk # 1 FAILED em 225. 1 de 1 pedaço FAILED

3) salvar rejeições no arquivo app / code / core / Enterprise / PageCache / Model / Observer.php.rej: SUPEE-9767 ERRO: O patch não pode ser aplicado / revertido com êxito

4) SUPEE-9767, modman e links simbólicos: SUPEE-9767, modman e links simbólicos

5) app / design / frontend / rwd / padrão / layout / page.xml Hunk # 1 FALHOU em 36. Hunk # 2 FALHOU em 54. 2 em 2 blocos FAILED: Erro SUPEE-9767

6) 1 de 1 pedaço falhou - salvar rejeições no arquivo app / code / core / Mage / Sales / Model / Quote / Item.php: Magento 1.9.2.2 SUPEE-9767 Patch ERROR

7) erro de check-out do onestep (novamente, este é o problema principal do formulário): SUPEE-9767 Magento CE 1.9.3.3 O check-out do Onestep não funciona com a validação de chave do formulário no check-out ativada

8) problema de registro de cliente com checkout em uma etapa: SUPEE-9767 Patch / CE 1.9.3.3 - Check-out de uma 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 falha no Image.php

Observe que os links simbólicos sempre foram desativados por padrão nas novas instalações do Magento. Administre os valores de configuração YES / NO como padrão 'NÃO'. A atualização agora desativa explicitamente os links simbólicos no config.xml e, como precaução extra, também remove a seção de modelo do admin-> developer que continha a opção de configuração.

Isso não afetará as configurações atuais do link simbólico; se você ativou manualmente os links simbólicos anteriores à 1.9.3.2, eles permanecerão ativados, embora você não possa mais ver a configuração no admin.

Os usuários que usam o modman para gerenciar os módulos Magento 1.x devem garantir que eles não desabilitem os links simbólicos, pois isso desabilitará os módulos do modman.

Os administradores responsáveis podem ativar a seção de administrador do link simbólico novamente, procurando as alterações de diferenças na seção do modelo em app / code / core / Mage / Core / etc / system.xml e adicionando a seção ao system.xml por volta da linha 600. Ou links simbólicos de verificação dupla ainda estão ativados com

configuração do n98-magerun.phar: despejo | link simbólico grep

Aqui está o arquivo diff para magento1933 e magento1932 para ajudar na identificação de alterações no tema padrão que podem afetar seus temas estendidos / personalizados.

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

Problema: Usar o php7 às vezes gera o seguinte erro:

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}

É quase certo que a versão do Zend tem a ver com isso. Uma solução rápida é essa, mas com certeza não está correta:

-> app / code / core / Enterprise / PageCache / Model / Observer.php: 244 substitua-o por:

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

-> e app / code / core / Enterprise / PageCache / Model / Observer.php: 177 com:

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

É claro que crie um complemento para reescrever isso. Mas tenho certeza de que há algo melhor a ser feito aqui.

ATUALIZAÇÃO (Melhor solução)

-> Vá para: lib / Zend / Json.php e depois da linha 76 adicione isso:

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

Crie sua extensão para substituí-la e não edite o arquivo principal.

Problema: código dinâmico ou css desativa o elemento de entrada da chave do formulário no check-out

Um problema que eu vi é que o código dinâmico (paypal plus) no processo de check-out de uma página substitui o elemento fieldset no formulário de método de pagamento em uma etapa html - excluindo ou desabilitando (com css) o elemento form_key oculto.

A correção é garantir que o elemento formkey não esteja sendo desativado por nenhum código dinâmico ou css. Mover o código do formkey para fora do elemento fieldset também pode ajudar

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

Você pode confirmar facilmente se o form_key está sendo detectado e enviado ao controlador de uma página, inspecionando as solicitações de rede ajax em seu navegador à medida que você percorre os métodos de pagamento, cada método deve incluir a chave de formulário nos dados do formulário ajax, se o formulário A chave não está lá, mas o código fonte do Magento foi corrigido. Verifique se há código externo que afeta o elemento-chave do formulário, ou seja, css ou alterações dinâmicas no lado do cliente.

Problema: correções ausentes no head-simple.phtml

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

precisa das mesmas correções que

app/design/adminhtml/default/default/template/page/head.phtml

PROBLEMA: O registro do cliente falha ao usar a verificação genérica de cinco etapas do Magento.

Esse problema é apresentado apenas quando habilitamos a autenticação de chave. Versão usada: 1.7.0.2, mas parece que alguém postou o mesmo problema também na versão 1.9.3. Patch SUPEE-9767 / CE 1.9.3.3 - Pagamento em uma página - Problema no registro do cliente

Quando Ir para a finalização da compra, são apresentadas duas opções: VERIFICAR COMO UM HÓSPEDE OU REGISTRAR Uma vez clique em "Registrar" e preencha o formulário junto com a senha, siga todas as etapas e conclua o pedido. O pedido é feito, mas o cliente nunca é registrado no magento. Parece que o pedido foi feito por convidado.

Quando voltei e Desabilitei a autenticação de chave de formulário, e tentei fazer um pedido durante o registro como cliente, ele foi feito sem problemas e o cliente foi registrado no back-end.

ATUALIZAÇÃO 13/07/2017 [O PROBLEMA É CONSOLIDADO]

A equipe Magento lançou o SUPEE-9767 V2 nesta versão do patch, o problema com gifs transparentes e pngs foi corrigido.

Você deve reverter todas as alterações no arquivo discutido neste segmento. Em seguida, reverta o patch V1 aplicado e, finalmente, aplique a nova versão V2.

PRE - SUPEE-9767 V2

Por favor, não use o código discutido abaixo; em vez disso, aplique V2 do patch, o problema discutido abaixo já foi corrigido nesta versão

Se alguém tiver problemas com png transparentes, quando carregado no painel de administração, o fundo fica preto. (Sobre os produtos) está relacionado ao retorno de chamada do Upload de imagens apresentado em:

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

No momento, não tenho certeza do que exatamente está causando esse comportamento, mas estou tentando descobrir, posso confirmar que, quando o retorno de chamada é removido, o comportamento estranho está desaparecendo.

ATUALIZAR

Ok, achei a função que também é atualizada a partir do SUPEE-9767, que na verdade está quebrando a transparência nos png. Uma cópia da imagem original é criada sem transparência.

+++ 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.'));

ATUALIZAR

Aqui está a versão atualizada da função para preservar a transparência png

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

essas duas linhas precisam ser adicionadas ao patch. Atualize a função emapp/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.'));
}

ATUALIZAÇÃO 23/06/17

Esta versão atualizada da função corrige a transparência PNG e 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.'));
}

Problema: permitir notificação de link simbólico não mostrada aos administradores

A notificação de link simbólico não será mostrada na área de notificação do administrador, pois não está incluída no <block type="core/text_list" name="notifications" as="notifications">

O patch para CE e EE abaixo:

--- 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() -->

O problema é que </block>está no final de checkout_formkey(que é auto-finalizável) e, portanto, fecha o pai notifications. Isso faz com que o notification_symlinknão seja incluído no core/text_liste não seja renderizado.

Pequena dica para #patchday; depois de copiar 1.9.3.3 na sua instalação, execute git diff -w --stat | grep -v " 2 +" | grep -v " 0"para ver rapidamente alterações maiores nos arquivos.

Problema: modelo de remessa EE não corrigido

Corrigi uma instalação do EE 1.13.1.0 e o modelo de envio corporativo ( app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) não tinha a chave de formulário adicionada, mas os modelos de cobrança e pagamento.

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

Há um problema nas versões do Magento EE que são corrigidas com SUPEE-9767 (portanto, não com atualizações para 1.14.3.3). A chave do formulário nessa página será armazenada em cache. Portanto, quando libero meu cache e, em seguida, vou para uma página de produto e verifique se a página está completamente em cache (atualize algumas vezes), devo poder adicionar esse produto ao meu carrinho.

Agora, quando abro um navegador diferente (ou modo de navegação anônima), abra a mesma página e tente adicionar o produto ao carrinho novamente. O produto não será adicionado ao carrinho, devido à chave do formulário. Agora, quando você libera o cache novamente, o produto pode ser adicionado ao carrinho novamente.

Obrigado a Jasper Zeinstra

Para desenvolvedores que usam o Magento Composer Intaller, você pode alterar a estratégia de implantação para Copiar em vez de Symlink. Você também pode configurar para anexar os arquivos do módulo ao seu .gitignore, para que seu repositório fique limpo.

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 } }

Eu tive um problema no EE 1.14.2.2 com o FPC ativado e esse patch foi aplicado.

Intermitentemente, os usuários não puderam adicionar ao carrinho.

Explicação e correção aqui: Problema com o SUPEE-9767: problema com o carrinho no carrinho, cache de página inteira da empresa

Problema: o Patch estava trabalhando no Magento 1.7.0.0 de baunilha [editado]

Durante o teste do nosso script de patch, descobrimos um problema no patch para Magento 1.7.0.0. Não sei se alguém ainda o usa, mas de qualquer forma é um problema no SUPEE-9767. Usamos uma instalação de baunilha e instalamos todos os patches anteriores primeiro.

Arquivo de correção utilizados: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh O arquivo de patch não funcionar para Magento 1.7.0.1 e 1.7.0.2

Resumo dos 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 constar, no 1.7.0.0 tentamos o patch:

$ 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

Eu apenas tive que reverter esse patch devido a algum comportamento estranho. Por qualquer motivo, certos usuários não puderam adicionar determinados itens ao carrinho.

Suponho que isso tenha algo a ver com cotações antigas colidindo com a cotação atual desse cliente. Eu verifiquei esse problema efetuando login como usuário para garantir que não era apenas um 1D10T.

Tem sido um problema desde que tirei a vida do patch na última sexta-feira. Estamos usando o 1.14.2.4 . Estamos fortemente modificados para que funcione bem para outros usuários. Apenas um aviso!

Problema: loop de redirecionamento infinito na 1.6.0.0

Conserto rápido

Encontre as linhas abaixo na função protegida método _checkBaseUrl ($ request) no arquivo 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
 ) {  

Mude estas linhas para

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

Depois disso, salve o arquivo (confirme no seu REPO), limpe o cache (remova tudo dentro da pasta var / cache) e recarregue a frente da sua loja. Você deve encontrar o site carregado sem mais problemas de redirecionamento 302 após aplicar o patch SUPEE 9767.

Causa raiz

A diferença no valor do ESQUEMA entre a Solicitação real e o URI após o redirecionamento. Por exemplo: a solicitação real retorna o esquema HTTP, mas o esquema no URI pode ser HTTPS.

Possíveis razões subjacentes

1. É provável que você tenha uma regra de redirecionamento no arquivo .htaccess para redirecionar todas as solicitações http para https. O usuário solicita http://seudominio.com e você pode ter alterado o esquema e o redirecionou para https: // seudominio, em vez de http://seudominio.com, que ele realmente havia solicitado.

2. Os URLs básicos, seguros e não seguros, começam com https

O erro confirmado "O registro do cliente falha no check-out" ocorreu um pouco diferente do meu lado.

Se o cliente escolher se registrar no check-out, sua senha não será armazenada corretamente. O cliente foi criado corretamente, apenas para que a senha não seja armazenada. Eu detectei isso pelo fato de a senha não ter sido mostrada no email de boas-vindas. As pessoas não podem fazer login por causa disso também.

Correção de bug vinculada no SUPEE-9767 Patch / CE 1.9.3.3 - Uma página de pagamento - O registro do cliente também fez o trabalho por mim.

Alguém pode me dizer para que serve isso ... no supee-9767?

O patch não funciona mesmo para um Magento 1.7.0.2 de baunilha.

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

mesmo depois de aplicar os patches mais antigos 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

A solução / problema que encontrei é que algumas das alterações no patch para 1.7.0.2 são para arquivos que não existiam antes da 1.9.2.3. Então, eu copiei os seguintes arquivos de uma nova instalação 1.9.2.3 antes executar o script de patch:

• app / code / core / Mage / Core / Model / File / Validator / Image.php
• app / code / core / Mage / Sales / Model / Quote / Item.php

Basta adicionar um https://magento.stackexchange.com/a/176930/46249

Observe que os links simbólicos sempre foram desativados por padrão nas novas instalações do Magento. Administre os valores de configuração YES / NO como padrão 'NÃO'. A atualização agora desativa explicitamente os links simbólicos no config.xml e, como precaução extra, também remove a seção de modelo do admin-> developer que continha a opção de configuração.

Isso não afetará as configurações atuais do link simbólico; se você ativou manualmente os links simbólicos anteriores à 1.9.3.2, eles permanecerão ativados, embora você não possa mais ver a configuração no admin.

O texto em negrito não está correto. Se a atualização para 1.9.3.4 (SUPEE-9767 V2) ou as configurações atuais mais recentes forem excluídas:

# 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'
    ))
);

Os administradores responsáveis ​​podem ativar a seção de administrador do link simbólico novamente, procurando as alterações de diferenças na seção do modelo em app / code / core / Mage / Core / etc / system.xml e adicionando a seção ao system.xml por volta da linha 600. Ou links simbólicos de verificação dupla ainda estão ativados com

Basta tornar a opção de configuração visível novamente, não resolve o problema. A opção aparece, mas você não pode alterar a configuração, pois o modelo de back-end recém-introduzido evita salvar o valor. Vejo:

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

e

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

Para remover ou substituir esse modelo de back-end, consulte Como habilitar links simbólicos após a instalação do SUPEE-9767 V2?