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

108

O patch de segurança mais recente Magento 1 SUPEE-8788 contém 17 atualizações do APPSEC , por isso é muito importante aplicá-lo o mais rápido possível. Por outro lado, existem muitas quebras de compatibilidade com versões anteriores e, dado o histórico de patches no último ano, eu não a aplicaria descuidada.

O bom é que desta vez não há modelos de front-end envolvidos, portanto parece que não precisamos corrigir todos os nossos temas. Isso só é verdade para o Magento 1.8 ou superior.

No entanto: você encontrou algum problema ou bug de compatibilidade após aplicar o patch?

Fabian Schmengler
fonte
6
"não há modelos de front-end envolvidos" - não está correto para versões mais antigas do Magento. Por exemplo, o patch 1.7.0.2 altera 9 arquivos de modelo frontend / base / padrão.
Kristof em Fooman
magento.stackexchange.com/questions/140571/… engana este? Talvez agrupar todas as informações aqui ...
7ochem
2
Para qualquer pessoa que tenha problemas com as atualizações .swf do patch, simplesmente remova as linhas 5951-9818 do patch e remova manualmente os arquivos .swf do /skin/adminhtml/default/default/media- já que é isso que o patch estava fazendo.
Liam McArthur
Não sei por que, mas após a instalação do 8788 no 1.8.0.0, o patch 7405 relata como NÃO instalado. enquanto a v1 e a v1.1 foram instaladas anteriormente
MagenX 13/10
2
@srinivas você removeu a pasta media deste caminho skin / adminhtml / default / default?
Priya Ponnusamy

Respostas:

107

Anotações importantes

Observe que 1.9.3 é diferente de 1.9.2.4 + SUPEE-8788. Aqui está a diferença entre os dois: https://gist.github.com/digitalpianism/14a15cd52baede0e5d600e8c653f33e9

Atualização em 14 de outubro: a versão 2 do patch foi lançada (veja abaixo) Em 13 de outubro, os patches de 1.5.x a 1.8.x foram retirados do site Magento devido à incompatibilidade com os patches anteriores (veja abaixo):

https://community.magento.com/t5/Security-Patches/SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error/td-p/50434/highlight/false/page/2

V3 do patch

Esta nova versão é apenas para Magento EE 1.13.0.x

Aplique a V3:

  • reverter SUPEE 1533 (se instalado)
  • instale o SUPEE 3941 (se não estiver instalado)
  • instalar SUPEE 8788 v3

V2 do patch

Aplique a V2:

  • reverter SUPEE 8788 v1
  • reverter SUPEE 1533 (se instalado)
  • instale o SUPEE 3941 (se não estiver instalado)
  • instalar SUPEE 8788 v2

A DemacMedia desenvolveu um script bash útil para automatizar o processo acima, você pode encontrá-lo aqui: https://github.com/DemacMedia/magento-SUPEE8788-patcher

Detalhes do patch

Depois de cavar o patch, aqui estão as partes interessantes (patching de 1.9.2.4):

  • Mage_Adminhtml_Block_Media_Uploaderfoi substituído Mage_Uploader_Block_Multiplepor um Mage_Uploadermódulo completo que dispensa o suporte ao Flash . O bloco antigo agora está obsoleto e estende o novo bloco.
  • Ainda com relação ao remetente, o Mage_Downloadablemódulo foi refatorado para lidar com o novo remetente não flash. Ele usa Mage_Uploader_Block_Singlecomo bloco de upload em vez de usar modelos.
  • Na sequência desta alteração, t ele arquivos SWF skin/adminhtml/default/default/media/flex.swf, skin/adminhtml/default/default/media/uploader.swfe skin/adminhtml/default/default/media/uploaderSingle.swfforam excluídos.
  • O controlador de exclusão de endereço agora está protegido com a chave do formulário diretamente via getDeleteUrldeMage_Customer_Block_Address_Book
  • Controlador de remoção de item de lista agora é protegido com chave forma através da getRemoveUrldeMage_Wishlist_Helper_Data
  • O método de pagamento Paypal Express agora garante que o email do cliente usado exista no Magento ao fazer check-out e registrar um novo usuário. (entenda: o novo usuário é criado antes do processamento da nova cotação)
  • Os métodos de pagamento que usam o cliente cURL / HTTP agora foram CURLOPT_SSL_VERIFYHOSTdefinidos como 2 (era 0 antes) e o CURLOPT_SSL_VERIFYPEERsinalizador agora é adicionado às chamadas cURL. O sinalizador Verificar pares pode ser ativado / desativado através da configuração do método de pagamento através do menu suspenso Ativar verificação SSL.
  • Mage_Http_Client_Curlagora CURLOPT_SSL_VERIFYPEERdefinido como true (era falso antes) , tenha cuidado se você tiver algum módulo personalizado usando-o.
  • As dimensões máximas das imagens do produto agora podem ser configuradas na configuração. Nota: pode resultar em uma mensagem de erro engraçada se você enviar imagens muito grandes: Formato de arquivo não permitido no Magento 1.9.2.2 após o upload do patch

Problemas conhecidos do SUPEE-8788 v2

Problemas conhecidos do SUPEE-8788 v1

Problemas conhecidos do 1.9.3.0

Edit: como a lista está ficando longa e está praticamente fora do tópico nesta resposta (como não relacionada ao SUPEE-8788), você pode consultar este post para obter a lista dos problemas conhecidos do 1.9.3.0: https: //magento.stackexchange. com / a / 140826/2380

Raphael na Digital Pianism
fonte
1
Obrigado pela extensa lista! Uma pergunta: você tem certeza de que o problema de pesquisa de texto completo se aplica ao patch SUPEE-8788? Não consigo encontrar alterações relacionadas a esta funcionalidade.
Aad Mathijssen
1
@MageDev consulte o terceiro comentário na pergunta;)
Raphael em Digital pianismo
1
Se o uploader produto não funcionar depois de aplicar com sucesso o patch e você estiver usando o plugin CreareSEO popular, então terá de ser aplicado também essa correção github.com/adampmoss/CreareSEO/pull/78
joesk
1
Notei que você mencionou "O método de pagamento Paypal Express agora garante que o email do cliente usado exista no Magento." Isso significa que o hóspede não pode fazer check-in com o PayPal Express? Você deve ser um usuário registrado? Estou esquecendo de algo.
13136 Ícone
1
Algumas extensões de terceiros que usaram o remetente antigo são quebradas após a aplicação do patch. Por exemplo, "Magic 360" está adicionando uma guia nas guias de detalhes do produto de back-end. Após o patch, você não poderá ver / editar os detalhes do produto. Percebi esse problema para o desenvolvedor de extensões no Magento connect ( magentocommerce.com/magento-connect/… ).
DarkCowboy
29

Ao aplicar o patch, este erro pode ocorrer:

checking file skin/adminhtml/default/default/media/flex.swf
checking file skin/adminhtml/default/default/media/uploader.swf
checking file skin/adminhtml/default/default/media/uploaderSingle.swf
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
checking file skin/adminhtml/default/default/xmlconnect/boxes.css

O patch 8788 contém conteúdo binário. Como o Magento não fornece links de download direto (eu odeio essa política desde então), você deve baixar o patch no seu computador e carregá-lo com um aplicativo de transferência de arquivos (como o WinSCP no Windows) para o seu servidor. O WinSCP, por exemplo, será carregado no modo TEXTO (o WinSCP manipula arquivos * .sh como texto por padrão).

Portanto, a solução alternativa é compactar / tar o arquivo de correção e descompactar / descompactar novamente no servidor. et voila.


Desculpe, eu não tinha como responder isso

  1. Baixe a versão correta do magento (por exemplo: CE 1.9.1.0)
  2. Substitua os seguintes arquivos pelo local baixado

skin / adminhtml / padrão / padrão / mídia / flex.swf skin / adminhtml / padrão / padrão / mídia / uploader.swf skin / adminhtml / padrão / padrão / mídia / uploaderSingle.swf

  1. Execute o patch

Trabalhou para mim


infabo
fonte
10
Você leu a pergunta dos OPs? fschmengler perguntou: "No entanto: você encontrou algum problema ou bug de compatibilidade APÓS aplicar o patch?" Eu encontrei esse problema ao aplicar o patch. Eu acho que o sentido desse segmento é documentar os possíveis erros do SUPEE-8788. Isso inclui - IMHO - problemas com o próprio patch também.
infabo
Trabalhou um prazer, obrigado! É melhor fazer isso para TODOS os futuros patches Magento também?
KiwisTasteGood
ou você apenas dos2unix PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh
fbtb
Geralmente não era necessário antes e presumo que não será necessário no futuro. Eu acho que os SWFs de upload foram os únicos binários enviados com o Magento 1.x - agora eles se foram. Portanto, não espero problemas como este novamente no futuro.
infabo 13/10
3
Ao usar o FileZilla para fazer upload do .sharquivo de correção para a raiz do Magento, defina o tipo de transferência como binaryantes de fazer upload do arquivo de correção. Referência
ForMat 15/10/16
25

Se você aplicou o SUPEE-1533 anteriormente, o patch falhará app/code/core/Mage/Adminhtml/controllers/DashboardController.php.

Eu resolvi isso por ...

  1. Reverta manualmente as alterações introduzidas nesse arquivo por SUPEE-1533
  2. Aplicar SUPEE-8788
  3. Reintroduza manualmente as alterações introduzidas nesse arquivo por SUPEE-1533

Remover a alteração do SUPEE-8788 é perigoso porque o arquivo de correção contém dados binários e salvá-los em um editor pode causar problemas (outra dica).

mpchadwick
fonte
Pelo que entendi, você reverteu o patch 1533 original, instalou o SUPEE 8788 e instalou novamente 1533 ?? Eu compreendo corretamente?
Ícone
Também estou tendo problemas com o FAILED HUNK em 28 app / design / frontend / base / default / template / review / form.phtml
Ícone
9
Eu me pergunto por que, quando dedicamos um tempo para aplicar adequadamente os patches incrementais oficiais, somos penalizados por fazer isso fazendo correções manuais quando os patches não funcionam quando os patches fornecidos anteriormente foram aplicados. Uma abordagem muito estranha.
9136 Jon Holland
1
A maioria das versões abaixo de 1,9 que possuem o SUPEE 1533 instalado não pode instalar o patch corretamente. SUPEE 8788 não é compatível com 1533
Ícone
2
@ JonHolland Porque, bem, é Magento.
Agop 17/10
25

Aqui está um resumo do que eu (e outros) encontrei até agora, estou tentando mantê-lo organizado, sinta-se à vontade para adicionar ou vincular qualquer coisa que estiver faltando, a postagem é um Wiki da comunidade:

Razões para falha na correção

Se você vir "ERRO: O patch não pode ser aplicado / revertido com êxito", procure "Hunk # 1 FAILED" nas mensagens de log para verificar em qual arquivo o patch falhou.

  • Aparentemente, a v2 do patch do Magento 1.7 espera que o SUPEE-3941 seja apresentado, embora exista apenas para o Magento 1.8 e 1.9 . Se você estiver no Magento 1.7 e downloadervir erros relacionados aos arquivos , faça o download do SUPEE-3941 para 1.8 e aplique-o no 1.7, ele deve funcionar. Consulte o tópico de comentários aqui: Problema no patch de segurança SUPEE 8788
  • Nas versões Magento que tiveram o SUPEE-1533 aplicado anteriormente, o patch falha app/code/core/Mage/Adminhtml/controllers/DashboardController.phpporque o arquivo é afetado pelos patches e o SUPEE-8788 (incorretamente!) Assume que a versão sem patch está presente. Isso ainda é verdade com a versão 2 do patch! A versão 2 inclui as alterações do SUPEE-1533, portanto, se você o instalou antes, ainda precisará revertê-lo, mas não precisará aplicá-lo manualmente novamente posteriormente.

  • Se você excluiu ou renomeou o diretório "downloader", o patch falhará porque corrige um arquivo dentro do downloader. A solução mais fácil é restaurar o diretório original do downloader, aplicar o patch e excluir o diretório novamente. Como alternativa, você também pode remover as instruções downloader/lib/Mage/HTTP/Client/Curl.phpdo patch.

  • Outras mensagens "Hunk FAILED" geralmente ocorrem devido a alterações nos arquivos principais ou à falta de patches anteriores. Verifique se todos os patches anteriores da sua versão do Magento estão instalados e se você não fez alterações nos arquivos principais.

  • Outro problema comum é que o patch falha ao excluir .swfarquivos devido ao seu conteúdo binário. O erro terá a seguinte aparência:

    checking file skin/adminhtml/default/default/media/uploaderSingle.swf
    Reversed (or previously applied) patch detected!  Assume -R? [n]
    Apply anyway? [n]
    Skipping patch.
    1 out of 1 hunk ignored
    

    ou assim

    Patching file skin/adminhtml/default/default/media/uploader.swf using Plan A...
    No such line 2 in input file, ignoring
    Empty context always matches.
    Hunk #1 failed at 0.
    1 out of 1 hunks failed while patching skin/adminhtml/default/default/media/uploader.swf
    Hmm...  The next patch looks like a unified diff to me...
    The text leading up to this was:
    --------------------------
    

    ou assim:

    Checking if patch can be applied/reverted successfully...
    /bin/patch: **** malformed patch at line 5790: ?rM]M??????&X㔮??v??Q;r?N?qJ??Y???I0?Y??4??'?????9?.??X?Ǒ?{??ax!G???I???q?u|????թ??????|
                                                   h??o?V@??|? ?g?H aꪭ??Ю???,I"?ğ????.??    yI?I\????)?X?
                         ?p???*?e?q?K8<DqD?H;|?
    ERROR: Patch can't be applied/reverted successfully.
    

    As possíveis soluções são dadas nesta resposta por @infabo. O download do patch diretamente no sistema em que eu quero aplicá-lo, usando curl, conforme explicado em https://gist.github.com/piotrekkaminski/9bc45ec84028611d621e, sempre funcionou para mim, exceto quando eu tentei no Cygwin

Maneira avançada de lidar com patches com falha: @PeterOCallaghan sugeriu comentar a linha de execução a seco e lidar manualmente com os arquivos * .rej. Dessa forma, o patch pode ser parcialmente aplicado e, se não conseguir excluir os arquivos swf, você poderá fazer isso manualmente. Ou, se ele não atualizar os arquivos downloaderporque você excluiu esse diretório, você pode simplesmente ignorá-lo.

  1. vi PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh(ou nome de arquivo semelhante) altere _apply_revert_patch dry-runpara se parecer #_apply_revert_patch dry-run

  2. execute o patch emitindo ./PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh

Isso irá corrigir seus arquivos

  1. Comentar _apply_revert_patchpara#_apply_revert_patch

  2. execute o patch novamente, para adicionar a app/etc/app/etc/applied.patches.listentrada

  3. grep para todos os arquivos .rej com

    git status | grep *.rej

  4. trabalhar manualmente nessas mudanças

Problemas após a aplicação do patch

Chaves de formulário

  • Para versões do Magento anteriores à 1.8, há alterações nos frontend/base/defaultmodelos. Certifique-se de aplicar manualmente as mesmas alterações no seu tema, se ele substituir esses arquivos

    Mais especificamente, uma chave de formulário foi adicionada para ações de front-end, como:

    • Removendo um item da lista de desejos
    • Excluindo um endereço de cliente da visualização da loja
    • Atualizando um item de cotação em sua cesta

    Veja esta resposta de @LukeRogers se você encontrar problemas com essas ações.

Uploader personalizado

O Unirgy_Rapidflow e outras extensões com formulários de upload personalizados não estão mais funcionando.

Veja esta resposta por @mpchadwick e comentário por @lloiacono

Eu fixo-lo substituindo $this->getUploader()->getConfig()com $this->getUploader()->getUploaderConfig()noUnirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload

Para descobrir se alguma das suas extensões usa isso, você pode executar o seguinte na linha de comando:

grep -R 'getUploader()->getConfig();' app/code/community

Mensagens de erro relatadas

  • Erro fatal do PHP: Chamada para a função indefinida hash_equals ()

    acontece se você estiver em uma versão PHP antes de 5.6 e substituir code/core/Mage/core/functions.phpno code/local/Mage/core/functions.php(que poderia ser o caso se você usar extensões Fishpig). Veja esta resposta por @ClaudiuCreanga


Problemas resolvidos na v2 do patch

Se você encontrar algum desses problemas, provavelmente usa a versão 1 do patch ("v1" no nome do arquivo). Faça o download do patch novamente para obter a "v2", que corrige estes problemas:

  • Houve um problema de compatibilidade com SUPEE-3941 e downloader/lib/Mage/HTTP/Client/Curl.php

  • 'Exceção' com a mensagem 'Tipo de dados não suportado N' em /lib/Unserialize/Reader/ArrValue.php

  • O patch para o EE 1.14.2.0 acidentalmente continha um novo arquivo test_oauth.php que você deveria excluir! Veja esta resposta por @MatthiasZeis

Fabian Schmengler
fonte
Chave de Form adicionado ao atualizar item de citação na cesta não é algo que tenha sido adicionado com SUPEE-8788 (não de 1.9.2.4, pelo menos)
Raphael em Digital pianismo
O @RaphaelatDigitalPianism, no mínimo, o patch 1.13.0.1 adiciona validação de chave de formulário a Mage_Checkout_CartController::updatePostAction, potencialmente outras versões de patch também.
Luke Rodgers
23

Se você pegar

Call to undefined function hash_equals() error

mesmo se o seu patch foi bem-sucedido, isso pode significar que você copiou o functions.php app/code/local/Mage/Core.

Você também precisará inserir essa função porque esse arquivo substitui a principal.

Então insira no app/code/local/Mage/Core/functions.phpfinal:

if (!function_exists('hash_equals')) {
    /**
     * Compares two strings using the same time whether they're equal or not.
     * A difference in length will leak
     *
     * @param string $known_string
     * @param string $user_string
     * @return boolean Returns true when the two strings are equal, false otherwise.
     */
    function hash_equals($known_string, $user_string)
    {
        $result = 0;

        if (!is_string($known_string)) {
            trigger_error("hash_equals(): Expected known_string to be a string", E_USER_WARNING);
            return false;
        }

        if (!is_string($user_string)) {
            trigger_error("hash_equals(): Expected user_string to be a string", E_USER_WARNING);
            return false;
        }

        if (strlen($known_string) != strlen($user_string)) {
            return false;
        }

        for ($i = 0; $i < strlen($known_string); $i++) {
            $result |= (ord($known_string[$i]) ^ ord($user_string[$i]));
        }

        return 0 === $result;
    }
}
Claudiu Creanga
fonte
1
De antemão eu sei que Fishpig exige que você faça isso. Portanto, se você tiver instalado, isso será um problema para você.
mpchadwick
1
Nota: Eu estava confuso e é MWI que lhe pede para substituir functions.php, não Fishpig mwi-plugin.com/documentation/installation
mpchadwick
18

Em PATCH_SUPEE-8788_EE_1.14.2.0_v1-2016-10-10-02-27-03.sh, um arquivo test_oauth.phpé criado no diretório raiz do Magento. Você deseja excluir este (ou pelo menos não implementá-lo na produção) porque pode expor um rastreamento completo da pilha de exceções à pessoa que chama o URL https: //thedomain.tld/test_oauth.php .

Matthias Zeis
fonte
Boa captura, Matthias! Seria uma forma um tanto ruim implantar 17 patches APPSEC e abrir outro vetor ao mesmo tempo. Você já denunciou isso ao Magento?
Bryan 'BJ' Hoffpauir Jr. -
Eu abri um ticket sobre isso com o Suporte Magento, como eu tenho certeza que outros têm neste momento. Ainda não ouvi falar de uma versão v2 do patch, mas eles devem estar cientes do problema.
quasiobject
1
Haverá uma v2, deve ser publicada muito em breve. Sim, relatei quando postei aqui.
Matthias Zeis
1
Parece que é fixo agora
Erfan
18

ISTO SE APLICA A 1.7 VERSÕES MAGENTO


Se você estiver executando a 1.7.0.2, a versão 2 do SUPEE 8788 falhará na linha 372, tentando aplicar as alterações em Curl.php:

patching file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client

As instruções dizem que devemos reverter o SUPEE-1533 e instalar o SUPEE-3941

PROBLEMA: SUPEE-3941 está disponível apenas para Magento CE 1.8-1.9. Você pode tentar aplicá-lo para 1.7, e ele será aplicado. eu acho quedesenvolvedores de patches O Magento deve lançar uma versão 3 do SUPEE-8788 para aqueles que executam o magento abaixo de 1,8 ou criar um patch SUPEE-3941 adicional projetado para a versão abaixo de 1,8.

A versão 1 do SUPEE-8788 não teve o Curl.phperro no 1.7.0.2 (eu testei em muitas instalações)

Dica: se você estiver enfrentando erros .swf no final, certifique-se de compactar seu patch, fazer o upload para o servidor e descompactar o erro.SWF desaparecerá.

ATUALIZAR:

Magento disse que basicamente não há problema em instalar o patch SUPEE-3941 em uma versão Magento 1.7.0.2 para evitar erros na aplicação do SUPEE-8788

Ícone
fonte
Fomos desistidos
datasn.io 16/10
@ kavoir.com você também recebe o mesmo erro CURL.PHP ao instalar no 1.7.0.2 ??
Ícone
1
O mesmo problema aqui instala o 8788 V2 no 1.7.0.2, embora seja interessante obter o mesmo erro curl.php em nossos sites mais recentes da versão 1.9.2.1, que não têm o SUPEE-3941 disponível. revertendo 1533 não ajuda o problema seja
Jon Holland
@JonHolland eu escrevi para a equipe magento ... Espero que eles respondam #
Icon
2
Eu tenho uma resposta do líder da comunidade magento, basicamente, é ok para instalar 3941 patch 1.7.0.2 versão ..
Ícone
15

Original DashboardController.php (1.7.0.2- Não em cache, fresco do magento)

  if ($params = unserialize(base64_decode(urldecode($gaData)))) {

1533 Patched DashboardController.php contém a seguinte alteração

 if ($newHash == $gaHash) {
            $params = json_decode(base64_decode(urldecode($gaData)), true);
            if ($params) {

O patch 8788 faz a seguinte alteração no DashboardController.php

 if (hash_equals($newHash, $gaHash)) {
            if ($params = unserialize(base64_decode(urldecode($gaData)))) {

Como você pode ver, o 8788 possui uma alteração modificada em comparação com 1533, NÃO tenho certeza de qual é o ideal para modificar o arquivo, como sugere o mpchadwick, substituindo manualmente a alteração 8788 por 1533 após a instalação do 8788. Removendo basicamente a alteração 8788.

Alguma sugestão?

Ícone
fonte
2
OMI O resultado final desejado é uma mistura dos dois. Deve ser json_decode, mas deve usar os hash_equals em vez de ==. Isso evita um ataque de tempo (o que seria extremamente difícil de explorar).
Peter O'Callaghan
Concorde com @Peter. Se você usa Git, reverta a confirmação para SUPEE-1533, aplique o novo patch, confirme e, em seguida, reverta a confirmação de reversão novamente. O conflito DashboardController.phpdeve ser resolvido automaticamente então.
Fabian Schmengler 13/10
1
Você poderia fornecer um código para o DashboardController.php que devemos substituir após a instalação do 8788? Não sei exatamente o que editar, como mencionei acima, as linhas patchd 1533 e 8788 parecem diferentes. Você poderia fornecer como deve ser uma versão modificada manualmente?
13136 Ícone
É assim que o código 8788 deve aparecer após a modificação manual com a atualização 1533? if (hash_equals ($ newHash, $ gaHash)) {if ($ params = json_decode (base64_decode (urldecode ($ gaData))))) {
Ícone
1
Nota sobre a reversão de confirmações duas vezes: você pode usar git revert -n 123456abe git cherry-pick -n 123456abdesfazer temporariamente o SUPEE-1533 sem criar confirmações extras para ele.
Matthias Zeis
14

Meio tentado a sinalizar este post como principalmente baseado em opiniões ou sem uma resposta clara;)

As chaves de formulário foram adicionadas a alguns controladores, o número varia dependendo da sua versão do magento.

Se você tiver problemas

  • Removendo um item da lista de desejos
  • Excluindo um endereço de cliente da visualização da loja
  • Atualizando um item de cotação em sua cesta

Você precisará verificar o .phtmlarquivo de temas e verificar o POSTparâmetro chave do formulário para que ele passe na verificação nas ações do controlador, como:

class Mage_Checkout_CartController extends Mage_Core_Controller_Front_Action

     public function updatePostAction()
     {
+        if (!$this->_validateFormKey()) {
+            $this->_redirect('*/*/');
+            return;
+        }
+

Esses problemas provocaram muitas pessoas em patches anteriores; os temas de front-end personalizados com modelos substituídos são facilmente perdidos ao aplicar os patches.

As chaves do formulário são frequentemente adicionadas ao .phtmlmodelo que contém o formulário como um extra, inputcomo

<input name="form_key" type="hidden" value="<?php echo $this->getFormKey() ?>" />
Luke Rodgers
fonte
Existe uma lista completa de formulários que isso afeta? Para que eu possa testar e consertá-los TODOS de uma vez por todas. Não queira disfunções secretamente estúpidas como essa para incomodar os clientes ou reduzir a taxa de conversão.
Datasn.io
Se um SUPEE 8788 é instalado perfeitamente no 1.7 e faz alterações em (app / design / frontend / base / padrão / modelo .....). Mas, apesar da lista de desejos do front-end do site de alterações, os botões "Remover" funcionam perfeitamente. Ainda precisamos corrigir manualmente os arquivos de tema? Ou, desde que o patch não quebre nada no frontend, podemos deixar como estão?
23416 Icon
11

Eu encontrei o mesmo problema no swf em 1.9.2.4.

Fox Fixed - Siga os passos abaixo.

Etapa 1. Faça o download do arquivo SSH do patch de segurança 8788 para este link: - https://magento.com/tech-resources/downloads/magento/

Etapa 2. Após o download do arquivo SSH do patch de segurança 8788, coloque em uma pasta e faça o mesmo arquivo zip da pasta.

Etapa 3. Faça o upload da pasta Zip para a pasta magento raiz e descompacte através do SSH Putty.

Etapa 4. Execute o patch: - $ bash PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh

* Nota: o arquivo de patch contém arquivos binários inteiros em formato de texto. É por isso que quando você envia o arquivo SSH do patch de segurança 8788 sem o arquivo zip, o mesmo arquivo estará corrompido. *

Randhir Yadav
fonte
10

Depois de aplicar a SUPEE-8788, não era mais possível carregar perfis "Importar" usando o Unirgy_RapidFlow 2.0.0.18, obtendo um erro 500 (nada nos logs do Apache ou HTTPD).

Ainda estou no processo de depuração e trabalhando com o Unirgy para resolver, mas parece que o bloco de upload está causando o problema ( Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload).

O patch introduziu várias alterações Mage_Adminhtml_Block_Catalog_Product_Helper_Form_Gallery_Contentno pai.

Além do uRapidFlow, outros módulos de terceiros que permitem o upload de arquivos podem ser interrompidos como resultado do SUPEE-8788.

mpchadwick
fonte
você já encontrou uma solução para isso? Eu fixo-lo substituindo $ this-> getUploader () -> GetConfig () com $ this-> getUploader () -> getUploaderConfig () in Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload
lloiacono
Bom agora. Unirgy também parece ter corrigido isso em 2.0.0.23. secure.unirgy.com/release-notes.php?m=1#RapidFlow Estou trabalhando com um cliente para adquirir atualizações adicionais e não consegui validar.
mpchadwick
executar este em seu docroot para descobrir quais outros arquivos precisa ser corrigido: -r grep 'getUploader () -> GetConfig ()' ./
lloiacono
8

Recebi a seguinte mensagem ao executar o script de patch:

can't find file to patch at input line 4753
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
|index 6d0607e..5757be3 100644
|--- downloader/lib/Mage/HTTP/Client/Curl.php
|+++ downloader/lib/Mage/HTTP/Client/Curl.php

Acho que isso ocorreu porque renomeei a pasta "downloader", seguindo as recomendações de https://www.magereport.com .

Renomeei temporariamente a pasta para "downloader", apliquei o patch corretamente e o renomeei com seu nome secreto.

TheTrueTDF
fonte
8

O patch no 1.9.0.0 também falha (provavelmente 1.8.0.0 até 1.9.0.1 afetado) por causa do SUPEE-3941. 3941 corrige o downloader / lib / Mage / HTTP / Client / Curl.php e agora o 8788 falha.

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 378.
1 out of 1 hunk FAILED
checking file js/lib/uploader/flow.min.js

Solução alternativa para 1.9.0.1 abaixo. As alterações são muito completas, talvez seja necessário ajustar o próprio patch 8788.

edit: edite o patch, procure por Curl.php e substitua

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         }

         $this->curlOption(CURLOPT_URL, $uri);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, FALSE);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');

         // force method to POST if secured
         if ($isAuthorizationRequired) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js 

com

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         $uriModified = $this->getSecureRequest($uri, $isAuthorizationRequired);
         $this->_ch = curl_init();
         $this->curlOption(CURLOPT_URL, $uriModified);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, false);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');
         $this->getCurlMethodSettings($method, $params, $isAuthorizationRequired);

         if(count($this->_headers)) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js
infabo
fonte
Eu personalizei os arquivos de correção para trabalhar com todas as versões do Magento após a instalação de todas as correções anteriores: magentohosting.pro/files/MageHost.pro_fixed_SUPEE-8788_v2.zip
Jeroen Vermeulen - MageHost 13/16
8

Aqui está o que eu estou recebendo

Hunk #1 FAILED at 373.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client/Curl.php.rej
patching file js/lib/uploader/flow.min.js
patching file js/lib/uploader/fusty-flow-factory.js
patching file js/lib/uploader/fusty-flow.js
patching file js/mage/adminhtml/product.js
patching file js/mage/adminhtml/uploader/instance.js
patching file skin/adminhtml/default/default/boxes.css
patching file skin/adminhtml/default/default/media/flex.swf
patching file skin/adminhtml/default/default/media/uploader.swf
patching file skin/adminhtml/default/default/media/uploaderSingle.swf
patching file skin/adminhtml/default/default/xmlconnect/boxes.css
Haim
fonte
Obtendo exatamente o mesmo erro em uma instalação. Gostaria de saber se você descobriu alguma coisa.
TunaMaxx
Não, ainda à espera de alguém para descobrir isso
Haim
2
Veja magento.stackexchange.com/a/73957/9276 . Se o seu arquivo Curl.php tiver essa correção, desfaça essa alteração (reverta a linha para CURLOPT_SSL_CIPHER_LIST / 'TLSv1'), aplique o patch e refaça a alteração.
21416 Joe
Obrigado @ Joe. Estava voltando aqui para postar a mesma informação. Você chegou antes de mim! É o que eu ganho por ir dormir. :)
TunaMaxx 14/10
Teve o mesmo problema, isso resolveu. Obrigado!
dafyddPrys
8

Parece que o Magento estará lançando a versão atualizada do SUPEE 8788, para corrigir a compatibilidade do SUPEE 1533. Não tenho certeza se é uma boa idéia aplicar correções manuais agora. Alterações manuais podem comprometer futuras atualizações de patches. Gostaria de ouvir seus pensamentos.

Foi confirmado pelo Magento Community Manager. No dia 13 de outubro, às 15h EST. Todos os patches das versões abaixo de 1,9 são excluídos da lista de downloads https://www.magentocommerce.com/download?_ga=1.236497153.1889606568.1445610645 Veja o post: https://community.magento.com/t5 / Patches de segurança / SUPEE-8788-AND-SUPEE-1533-Erro incompatível de hunk / mp / 50514 / destaques / false # M1805

Ícone
fonte
1
Se o patch atualizado tiver exatamente o mesmo resultado que nossas correções manuais, e espero que seja esse o caso, não vejo problema. O patch atualizado não será necessário e os patches futuros não verão diferença.
Fabian Schmengler
1
@fschmengler bastante semelhante à incompatibilidade do PHP 5.5 para SUPEE-7405 IMO. O patch refletirá a correção manual.
Raphael no Digital Pianism
1
@fschmengler Que eu saiba, o magento lançará exatamente o mesmo patch novamente com correções. I gues seu melhor para remover mancha de idade (auto modificado) e instalar novo (provavelmente libere dia seguinte Amanhã devemos ter atualização Obrigado pela ajuda..!
Ícone
Não estou duvidando do valor dessa contribuição, mas seguindo o estilo de perguntas e respostas, essa resposta não me parece uma resposta, é mais uma atualização que o @fschmengler poderia adicionar à sua pergunta original (ou você pode adicioná-la à Resposta do Wiki da comunidade).
7ochem 14/10
8

Estamos recebendo relatórios dos seguintes novos problemas que não vejo em outras postagens:

  • Exceção nos novos releases em alguns casos - a chamada do método addCrumbs () (no caso de getStoreConfig (web / default / show_cms_breadcrumbs) ser indefinido). Não deve afetar o patch, apenas a versão 1.9.3 / 1.14.3

'Exceção' com a mensagem 'Tipo de dados não suportado N' em /lib/Unserialize/Reader/ArrValue.php na 1.9.1.0 e possivelmente versões anteriores quando o patch é aplicado. resolvido na versão 2 do patch.

Atualmente, não há soluções fáceis conhecidas para esses problemas. Estamos trabalhando para resolvê-los em uma nova versão do patch.

Piotr Kaminski
fonte
Correção possível para o erro N não suportado tipo de dados gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
Raphael em Digital pianismo
Alguma idéia de como superar o erro Curl.php ao instalar o SUPEE 8788 nas versões 1.6 e 1.7?
17166 Ícone
8

O remetente é interrompido quando você carrega o mesmo arquivo para amostras e links ao mesmo tempo para produtos para download. Observe que isso só acontece se você usar o mesmo arquivo nas duas áreas. (Ele costumava funcionar corretamente antes do patch.)

Para reproduzir, edite um produto para download e clique na guia Informações para Download :

  1. Abra a linha Amostras do acordeão e procure um arquivo de amostra.
  2. Na linha Links do acordeão, procure um link para download
  3. Clique em Upload de arquivos na seção Links.

O remetente carrega o arquivo de amostra em vez do arquivo de link para download, e o arquivo que você procurou na seção de link para download desaparece.

Consegui reproduzir isso em uma baunilha, com a instalação do 1.7.0.2 CE corrigido.

Laura
fonte
Acontece que este é o comportamento da lib JS subjacente usado para upload: github.com/flowjs/flow.js/issues/76
Laura
6

Sim, encontrei outro problema ao fazer o login, ele sempre retornará isso:

Descobri que é porque na classe 165 da linha Enterprise_Pci_Model_Observer,

Ao invés de:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPassword())) {

Isso irá corrigir:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPasswordHash())) {

Como não gosto de mudar o núcleo (nem mesmo mudar para o local), é melhor que o Magento conserte ou esclareça isso. No momento, o meu está criando novas extensões para estender isso e criar a função getPassword () (já que quero garantir que todos os desenvolvedores usem o modo Desenvolvedor).

dimasdwika
fonte
2
Depois de aplicar a V2 do patch, estou encontrando o mesmo problema do patch EE1.12. Parece que este arquivo foi alterado em algum ponto entre 1,12 e 1,14, mas não como parte das manchas
Chris
1
Levantei isso com o Magento e eles forneceram um patch adicional para resolver o problema. A mudança é idêntica à acima.
Chris
6

Editando arquivo de correção

Se alguém precisar editar o arquivo do patch, você não deve fazê-lo em um editor, pois isso quebrará os arquivos binários encapsulados no patch.

Se você tem uma linha de comando à mão, ou seja. linux / * unix tente usar o sedutilitário para remover linhas específicas.

Props para @fooman para obter a dica. Veja sua essência original

Exemplo sed -ie '101,111d' PATCH_SUPEE-8788_CE_1.7.0.2_v1-2016-10-11-06-36-18.sh

Isso excluirá as linhas 101 a 111 inclusive.

Problemas de envio de formulários.

Se você estiver vendo o problema acima mencionado, também poderá:

<?= $this->getBlockHtml('formkey'); ?>

Para obter mais informações, consulte este post. O que é getBlockHtml ('formkey')?

Sergei Filippov
fonte
4
Tenha cuidado com <?=isso não está habilitado em todas as configurações php
Raphael em Digital pianismo
@RaphaelatDigitalPianism você está correto. Embora <?=esteja ativado por padrão na maioria das configurações do php.ini, alguns hosts optam por desativá-lo.
Sergei Filippov
5

CE 1.6.2.0 e SUPEE-3941

Para aplicar o patch de segurança SUPEE-8788 (Versão 2), ( http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html#apply-8788-new ), é recomendável aplicar o SUPEE-3941 primeiro .

No entanto, na página de download do patch, não há patch SUPEE-3941 para o CE 1.6.2.0. O patch está disponível apenas para CE 1.8 e 1.9.

Conforme mencionado neste tópico, parece aceitável aplicar o patch SUPEE-3941 disponível (para CE 1.8 e 1.9) no CE 1.7.

Também é bom aplicar o SUPEE-3941 (para CE 1.8 e 1.9) no CE 1.6.2.0? Tentei aplicá-lo no CE 1.6.2.0 e obtive o seguinte erro:

Checking if patch can be applied/reverted successfully...
-e ERROR: Patch can't be applied/reverted successfully.

checking file downloader/Maged/Model/Connect.php
Hunk #1 succeeded at 489 (offset 3 lines).
checking file downloader/lib/Mage/Connect/Backup.php
checking file downloader/lib/Mage/Connect/Command.php
Hunk #1 FAILED at 64.
Hunk #2 succeeded at 205 with fuzz 2 (offset -44 lines).
Hunk #3 succeeded at 382 (offset -53 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Command/Install.php
Hunk #1 FAILED at 90.
Hunk #2 succeeded at 333 with fuzz 1 (offset 17 lines).
Hunk #3 succeeded at 363 (offset 17 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Packager.php
Hunk #4 FAILED at 268.
Hunk #5 FAILED at 290.
Hunk #6 succeeded at 369 with fuzz 2.
Hunk #7 FAILED at 377.
Hunk #9 FAILED at 428.
4 out of 10 hunks FAILED
checking file downloader/lib/Mage/Connect/Rest.php
Hunk #1 succeeded at 71 with fuzz 2 (offset -11 lines).
checking file downloader/lib/Mage/Connect/Singleconfig.php
Hunk #1 succeeded at 100 (offset -36 lines).
checking file downloader/lib/Mage/Connect/Validator.php
Hunk #1 succeeded at 418 (offset -41 lines).
Hunk #2 succeeded at 431 (offset -41 lines).
checking file downloader/lib/Mage/HTTP/Client/Curl.php
checking file downloader/template/settings.phtml
Mukesh Chapagain
fonte
5

Um pouco tarde, mas encontramos um problema no patch SUPEE-8788 V2, que pelo menos se aplica aos arquivos de patch do Magento 1.7.0.2 e 1.7.0.1. Provavelmente, isso também se aplica a todas as versões anteriores para as quais existe uma versão de patch. A versão Magento da 1.8 em diante não é afetada, pois o patch não altera os modelos para eles.

Em detalhe

Falta ao patch uma chave de formulário para o arquivo app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml

Sem ele, o login não funciona no checkout de uma página (ele simplesmente não funciona sem erros).

Consertar

Uma chave de formulário deve ser inserida como no seguinte patch:

diff --git a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
index 9d15a577b..18483a3c5 100644
--- a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
+++ b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
@@ -71,6 +71,7 @@
         <h3><?php echo $this->__('Login') ?></h3>
         <?php echo $this->getMessagesBlock()->getGroupedHtml() ?>
         <form id="login-form" action="<?php echo $this->getPostAction() ?>" method="post">
+        <?php echo $this->getBlockHtml('formkey'); ?>
         <fieldset>
             <h4><?php echo $this->__('Already registered?') ?></h4>
             <p><?php echo $this->__('Please log in below:') ?></p>
fheyer
fonte
4

Para o site corrigido 1533, substitua a linha abaixo de PATCH_SUPEE-8788 *****. Sh:

diff --git app/code/core/Mage/Adminhtml/controllers/DashboardController.php app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index 09ffc4c..367bf8e 100644
--- app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,7 +91,7 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
+            if (hash_equals($newHash, $gaHash)) {
                 if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params) 

por:

diff --git a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index ab2d654..367bf8e 100644
--- a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,9 +91,8 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
-                $params = json_decode(base64_decode(urldecode($gaData)), true);
-                if ($params) {
+            if (hash_equals($newHash, $gaHash)) {
+                if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params)
                             ->setConfig(array('timeout' => 5))
diff --git a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
index da1b14a..b6d72c0 100644
--- a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
+++ b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
@@ -444,7 +444,7 @@ class Mage_Adminhtml_Block_Dashboard_Graph extends Mage_Adminhtml_Block_Dashboar
             }
             return self::API_URL . '?' . implode('&', $p);
         } else {
-            $gaData = urlencode(base64_encode(json_encode($params)));
+            $gaData = urlencode(base64_encode(serialize($params)));
             $gaHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
             $params = array('ga' => $gaData, 'h' => $gaHash);
             return $this->getUrl('*/*/tunnel', array('_query' => $params));

Basicamente, apenas reverteu o 1533 e deixou 8788 junto.

William Zhao
fonte
Pelo que entendi, o 8788 substitui as alterações no DashboardController.php e as alterações 1533 originais serão eliminadas?
Ícone
2
Sim, o objetivo de 1533 substituir o serialize () por json_encode () foi reduzir a chance de aprovação do ataque ($ newHash == $ gaHash). Enquanto 8788 acrescenta hash_equals () para o mesmo fim
William Zhao
Ótimo, eu estava pensando em agir de outra maneira. No site de teste, enviei o DashboardController.php (arquivo magento) e instalei o SUPEE 8788. No entanto, li neste fórum e um cavalheiro mencionado para reintroduzir manualmente as alterações do supee 1533 no Supee 8988 arquivo modificado. O que você acha do meu método?
Ícone
Ícone, veja o meu diff acima. No seu caminho, você precisa alterar a linha atualizada pelo SUPEE 1533 em 'app / code / core / Mage / Adminhtml / Block / Dashboard / Graph.php' e também se você já possui o SUPEE 1533 remendado. Caso contrário Graph.php irá disparar para fora params formato JSON e você não será capaz de decodificá-lo por unserialize ()
William Zhao
4

A captura do Authorize.net é interrompida após a aplicação do patch. A autorização funciona bem, mas ao capturar o pagamento na fatura, é apresentado "Erro de gateway: é necessário o número do cartão de crédito" . O arquivo de log de pagamento mostra o x_typevalor do parâmetro passa auth_captureagora, mas antes do patch, o prior_auth_captureque funcionava bem. Alguém está com esse problema?

ATUALIZAÇÃO: Correção para este problema - Authorize.net não captura

Kalpesh
fonte
4

Consertei uma cópia do Magento 1.9.2.4 usando SSH com SUPEE-8788 Consertei outra cópia do Magento 1.9.2.4 usando ftp com SUPEE-8788 Consertei uma cópia do Magento 1.9.1.0 usando SSH com SUPEE-8788 usou uma nova cópia do magento 1.9.3.1

Em todos esses sites magento com SUPEE-8788, experimento o mesmo problema (talvez um bug do patch)

Usando produtos para download e acessando Informações para download-> Amostras quando tento Adicionar uma nova linha (uma ou mais) clicando no "X", não consigo mais remover a linhainsira a descrição da imagem aqui

Eu não sou tão especialista em Magento, estou tentando encontrar uma solução. Se eu achar que vou postar, se algum de vocês tiver alguma solução, será muito útil para mim

ATUALIZAÇÃO : usando o inspetor Chrome, vi este erro:insira a descrição da imagem aqui

******* ENCONTREI A SOLUÇÃO *******

Passei 2 dias e espero que isso possa ajudar outra pessoa, isso é um bug no SUPEE-8788

Abra samples.phtml dentro app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable

Encontre a função

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        element.down('div.flex').remove();
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

e substitua-o por

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        Element.select(element, 'div.flex').each(function(elm){
            elm.remove();
        });
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

Isso resolverá o erro

Ivan
fonte
3

O PATCH_SUPEE-8788_CE_1.9.2.1_v1-2016-10-11-07-00-43 foi aplicado na cópia de teste do site executando 1.9.2.1 e a verificação foi interrompida. Inverta o patch e o checkout funcionará normalmente novamente.

Ao enviar o pedido, você volta ao carrinho em vez do sucesso da finalização da compra. Acho que vou esperar a versão .1 antes de tentar novamente.

Adam Lavery
fonte
parece que uma exceção é lançada enquanto o pedido é salvo, você verificou seus registros?
simonthesorcerer
Parece que ... PHP Erro fatal: A classe 'Mage_Core_Helper_UnserializeArray' não foi encontrada em ... / public_html / app / Mage.php na linha 547
Adam Lavery
@AdamLavery Vá para Var / cache e exclua a pasta de cache. Eu recebo esse erro quando reverto os paches de volta ao original. É uma coisa de cache.
13136 Ícone
O novo patch deve sair em breve. Esta é uma grande atualização de patch que não espera erros ... Sim ... dedos cruzados.
13136 Ícone
1
Provavelmente porque está faltando. app/code/core/Mage/Core/Helper/UnserializeArray.phpIsso foi adicionado ao SUPEE-6788, que você pode não ter instalado. Parece que o SUPEE-8788 possui uma dependência não documentada do SUPEE-6788.
Tyler V.
3

Um novo e-mail do Magento nas primeiras horas da manhã indica que eles estarão produzindo novas versões de patches para lidar com os problemas de compatibilidade SUPEE-1533 e SUPEE-3941. Então, talvez apenas segure seus cavalos um pouco.

ENTERPRISE EDITION 1.14.3, COMMUNITY EDITION 1.9.3 e SUPEE-8788 Enterprise Edition 1.14.3 e Community Edition 1.9.3 oferecem mais de 120 melhorias de qualidade, além de suporte ao PHP 5.6. Eles também resolvem problemas críticos de segurança, incluindo: ...

... O patch SUPEE-8788 soluciona esses problemas de segurança nas versões anteriores do Magento. Infelizmente, descobrimos que os patches SUPEE-8788 para versões do Community Edition 1.8 e versões anteriores e Enterprise Edition 1.13 e versões anteriores falham se uma loja tiver aplicado anteriormente os patches de segurança SUPEE-1533 ou SUPEE-3941. Estamos trabalhando para corrigir esse problema e forneceremos novos patches nos próximos um a três dias. Até então, estamos removendo essas versões do patch SUPEE-8788 da distribuição ...

No entanto, estou preocupado que minhas versões ativas do Magento estejam entre o CE 1.9.3 que eles dizem que funciona e as novas versões em breve para a V1.8 e versões posteriores. Entrei em contato com eles, então vou esperar e ver o que eles dizem.

Jon Holland
fonte
Não é realmente uma "resposta", mas informações úteis, espero.
Jon Holland
Olá Jon, você também pode editar a pergunta original do @ fschmengler e adicioná-la na parte inferior como uma atualização . Eu acho que ele ficaria bem com isso e aprovaria essa edição.
7ochem 14/10
Boa ideia, mas alguém já acrescentou algo :)
Jon Holland
3

Eu não sou um grande fã de patches. Pessoalmente, removo todos os arquivos Magento de seus diretórios e carrego a nova versão (usando um script de shell). Todos os arquivos instalados ao longo dos anos, como módulos ou temas, ainda estão lá. Para o banco de dados, faço uma comparação entre novas versões instaladas. Uma maneira é criar ou remover as colunas / tabelas no banco de dados, a outra maneira é instalar novamente o Magento, apenas alterando o nome do arquivo /app/etc/local.xml. Eu prefiro o primeiro.

Se você não alterar a estrutura do banco de dados para a versão 1.9.3.0, ocorrerá alguns erros ou não poderá carregar a área de administração. Se alguém estiver interessado em algumas comparações de diretórios e bancos de dados Magento entre o Magento CE 1.9.2.4 e 1.9.3.0, basta baixar o arquivo aqui:

Comparação Magento: versões 1.9.2.4 - 1.9.3.0

Existem dois arquivos html com resultados visuais muito bons.

Atualizei 4 lojas hoje usando meu método em vez de aplicar patches. Todos estão funcionando sem problemas.

ADDISON74
fonte
Isso é legal se você estiver na versão mais recente e houver uma nova versão para o patch, como foi o caso de 1.9.2.2, 1.9.2.3 e 1.9.2.4 - no entanto, para este patch, não houve nova versão 1.9.2.5 . A versão 1.9.3.0 contém várias alterações adicionais que não estão relacionadas à segurança.
Fabian Schmengler
Com o meu método, obtive duas em uma, atualizações de segurança e novos recursos. O único problema é que você precisa entender o que está acontecendo no sistema de arquivos e no banco de dados entre as liberações. Não é grande coisa quando você sabe o que está fazendo. E você tem um controle melhor. Estou fazendo esse método desde a versão 1.7.
ADDISON74
3

Não tendo sorte na maioria das instalações do Magento CE (6 no total). Versões diferentes: 1.9.1, 1.9.0.1, 1.8.1.

Fiz o download do patch 8788 correspondente correto. Fiz questão de reverter 1533 quando aplicável.

Eu recebo as seguintes saídas importantes que são questionáveis:

Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

...

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.

... verificando arquivo app / code / core / Mage / Adminhtml / controllers / IndexController.php O pedaço 1 foi bem-sucedido em 373 (deslocamento -19 linhas). ...

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.ph

O mesmo que acima para: lib / Unserialize / Reader / Arr.php lib / Unserialize / Reader / ArrValue.php E diz que esses pedaços foram ignorados.

nota: não há nada no meu diretório Unserialized / Reader. Completamente vazio. nota: o Curl.php está no diretório do downloader. Não renomeado. Ele termina, mas não vejo os arquivos SWF removidos. Não vejo o patch aplicado na lista de applic.patches.list

Não faz sentido.

Rich Yessian
fonte
Ok .. entendi tudo. Definitivamente, é necessário trabalhar com TODOS os patches antigos, em ordem. Eu tinha alguns patches mais antigos que não haviam sido aplicados. Depois que eu puxei esses itens e apliquei na linha, as coisas começaram a consertar com sucesso. No entanto, descobri que sempre que recebia um erro de hunk em um arquivo para QUALQUER patch, precisava entrar no patch e encontrar o que estava tentando substituir e fazê-lo manualmente na instalação do magento. ENTÃO remova as linhas "diff" do patch e execute novamente. Essencialmente, sempre que vir um erro de hunk, entre no patch e veja o que ele está tentando +/- com ele, e faça você mesmo.
Rich Yessian
3

Eu atualizei cerca de 10 sites hoje e todos os sites em que o patch do SUPEE-8788 falhou tiveram o SUPEE-6788 MISSING .

Isso resultou em (exemplo) o seguinte erro:

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.php

Após a instalação do SUPEE-6788, o SUPEE-8788 foi corrigido corretamente.

Rann
fonte
3

Se você está recebendo Hunk #1 failederro xxx, foi o que eu fiz

Eu tenho Hunk #1 failed at 373. Erro !! depois da linha

verificando o downloader de arquivo / lib / Mage / HTTP / Client / Curl.php

Então, verifiquei o Curl.phparquivo e descobri que havia modificado o arquivo antes (comentei uma linha). Eu restaurei o arquivo original e executei o patch novamente. Então o patch foi bem sucedido. ;).

Então eu verifiquei:

/app/etc/applied.patches.list e tudo parece bom

Shan
fonte