安全补丁SUPEE-9767-可能的问题?


108

Magento 1的新安全补丁已发布,解决了16个APPSEC问题:https ://magento.com/security/patches/supee-9767

CVSSv3严重性中的七个漏洞得分为8.0或更高,并且它们正在野外被利用,因此这是一个关键补丁。站点可以应用SUPEE-9767或更新到新版本的CE 1.9.3.3 / EE 1.14.3.3。

应用SUPEE-9767时需要注意哪些常见问题或陷阱?


更新2017-07-12:

Magento发布了SUPEE-9767 V2CE 1.9.3.4,以解决最初补丁中的许多问题。如果应用了V1,则应先还原然后再应用V2。如果尚未修补,请仅应用V2,此处提出的大多数问题都将无关紧要。


“有七个漏洞的CVSSv3严重等级得分为8.0或更高,并且正在被野外利用,因此,这是一个关键补丁。” 我只是想检查一下,“攻击者”需要进入管理员才能进行这些攻击?
PaddyD

3
是的,您必须具有管理员权限才能利用漏洞利用
MagenX

但是,该补丁似乎并没有阻止通用的暴力终结点(即/ rss / order / new),这似乎是恶意软件试图访问管理区域的最常见方式?
Ricky Odin Matthews

1
我将其用于.htaccess中的RSS @RickyOdinMatthews RewriteRule ^/?(index.phprss|index.php/rss/catalog|index.php/rss/order|rss/catalog|rss/order).*$ /no-route [R=301,L,NC]
理查德·费罗

@RichardFeraro我使用nginx,但已经使用了类似的解决方案。我注意到,机器人通常会扫描这些端点并对其进行暴力破解。
里奇·奥丁·马修斯

Answers:


107

这是我深入研究补丁后的概述

节省时间:Experius提供了一个修补程序帮助程序,可以帮助您查找自定义主题,自定义模块或本地覆盖中的文件,这些文件也可能需要手动进行修补,您可以在此处找到:https : //github.com/experius/Magento- 1-Experius-Patch-Helper#magento

结帐表单键

如另一篇文章中所述,此修补程序将表单密钥添加到以下表单:

运输车表格:

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

多货运计费结帐表格:

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

多货运输结帐表格:

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

多货地址结帐表格:

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

帐单结帐表格:

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

发货结帐表格:

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

付款结帐表格:

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

送货方式结帐表格:

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

永久结算结帐表格:

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

最重要的是,以下JS文件已更新为与该更改兼容:

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

该怎么办:

如果您使用这些模板的自定义版本,则必须通过向其中添加以下代码来更新它们:

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

如果您使用的是第三方结帐模块,则必须与他们联系,以便他们可以提供其模块的更新版本。

另外,如果您具有先前列出的JS文件的自定义版本,则也必须对其进行更新。

节省您的时间

Fabian Schmengler编写了一个不错的小脚本来为您更新所有这些内容,您可以在这里找到它:

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

重要说明:可以在后端通过“ 系统”>“配置”>“管理”>“安全性”>“在结帐时启用表单密钥验证”下的新配置字段来更改结帐表单密钥验证默认情况下未启用此功能,因此您必须启用它才能从此安全功能中受益!!!请注意,如果未启用后端,则会在后台收到通知。

图片上传回调

图片库控制器已更新,以添加验证回调。

该怎么办

如果您使用的自定义模块使用如下代码执行图像上传:

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

我强烈建议您通过在代码之后添加以下代码来更新该代码:

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

符号链接

此补丁删除了系统配置字段,该字段允许您在后端允许模板符号链接。它曾经位于系统>配置>开发人员>模板>允许符号链接下。现在整个模板部分都消失了。

最重要的是,默认情况下,通过 app/etc/config.xml

有趣的是,如果您在补丁程序之前启用了配置字段,则会在后端收到通知,但是随着该字段消失,您将无法禁用它。

唯一的方法是运行以下SQL查询

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

澄清度

首先,我强烈建议您检查这两篇文章,以帮助您了解Symlink修改的目的:

此修改实际上是关于通过模板指令调用可上传内容(例如图像)。

与符号链接有关的问题仅可通过管理员访问来利用,Magento还在图像上传周围添加了更多保护。

请注意,除了设置本身以外,它们还提供了一些防止已知方法利用它的保护措施。

怎么办:如果像我一样,您正在使用带有模板符号链接的modman或作曲家,那么您将面临一些问题。除了处理SQL查询之外,我仍在尝试找出最好的方法。

有关此问题的主要文章:SUPEE-9767,modman和symlinks

可能的问题清单

V2是从该原始帖子发布的。别忘了升级

虫子

“已确认”一词用于已确认的错误。如果不存在,则意味着它可能是一个错误,但尚未得到确认。

大块失败的问题

请注意,所有这些问题可能仅仅是因为您修改了原始文件,请仔细检查是否存在这种情况:

  • 将文件备份到出现“失败失败”错误的位置
  • 从您的Magento版本下载原始文件
  • 比较两个文件

如果文件不同,则必须将修补程序与原始文件一起应用,然后重新应用自定义更改,例如:

  • 自定义主题文件夹中的自定义模板
  • local.xml
  • 应用/代码/本地文件

如果文件没有不同,则这是权限问题或补丁中的“错误”。


1
@图标不行。要
再次

1
只是添加到“其他问题”列表中:似乎magento.stackexchange.com/questions/167616/…也未在最新版本中修复
Anton Boritskiy

1
@RaphaelatDigitalPianism:magento.stackexchange.com/q/177560/51361

1
列表的另一个补充:该补丁打破了默认主题magento.stackexchange.com/questions/177681/…的多船运输
Aad Mathijssen

1
“水印透明时会变成黑色背景”-可以确认这是正确的。当您在cms中上传任何透明png时,就会发生这种情况
pixiemedia

42

问题1:form_key在结帐页面无效

Magento添加form_key最多的表格。

如果有的话using default onepage and using custom theme,那么您将form_key在结帐的每一步开始** 问题; **

您应该在以下位置添加表单密钥 <?php echo $this->getBlockHtml('formkey') ?>

如果以下文件退出,则形成每个结帐步骤文件的形式,

  • 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

如果模板文件是从基本主题调用的,则不会产生问题。因为补丁会自动更新那些文件。

另请注意: <?php echo $this->getBlockHtml('formkey') ?>应始终在表单标签内

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

**如果您使用Magento多次结帐,则需要在

以下文件:

问题2:在购物车页面上发给“装运估算”表的form_key:

在购物车页面的预计运送表格中添加form_key

然后必须添加表单密钥 <?php echo $this->getBlockHtml('formkey') ?>

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

问题3:Magento单页结帐opcheckout.js错误

如果您使用默认的一页结帐功能opcheckout.js 则应检查

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

如果没有退出,则更换

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

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

对于issue1,issue2,issue3,可以使用@FabianSchmengler的脚本add-checkout-form-key.sh轻松解决Issue的问题。它将解决您的接受主题文件上的问题

问题4:重写Mage_Customer_Model_Session后,客户登录后的表单密钥无效

如果Mage_Customer_Model_Session类已重写或已从调用

app/code/local/Mage/Customer/Model/Session.php那么当我们使用session设置了一个客户,setCustomerAsLoggedIn()或在session设置了一个客户之后,您可能会遇到form_key问题。

在这种情况下,您必须添加

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

在 调用setCustomerAsLoggedIn()之前

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

问题5:注销后出现Form_key问题

之后从会话注销客户,你可能会启动会话的问题,如果如果Mage_Customer_Model_Session类重写或已经从所谓的

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

在这种情况下同样需要:

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

建议:

建议1: 要解决supee-9767的问题,可以使用补丁https://github.com/experius/Magento-1-Experius-Patch-Helper

这是目前最好的解决方案。

注意,在此之前,强烈建议我进行文件和数据库备份或完整系统备份。


建议2:在ONESTEP结帐单上使用补丁功能

我们知道该补丁supee-9767是出于安全目的而发布的,如果您使用 ONESTEP CHECKOUT,则应将form_key验证添加到您的单步签出控制器的SAVE操作中

假设要保存运输方法的详细信息,您的一步结帐已使用saveShippingmethod(),则应在此添加

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

另外<?php echo $this->getBlockHtml('formkey') ?> ,您还必须在一步结帐phtml文件的相应部分添加表单密钥

一些相关链接

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


1
方便快捷地在结帐时查找表单键的自定义模板文件;查找应用程序/设计/前端| grep -E“结帐/单页/(计费|付款|发货| shipping_method).phtml” | grep -v“基本/默认” | grep -v“ rwd / default”
Peter Jaap Blaakmeer


那就是@FabianSchmengler魔法!!! :)
阿米特·贝拉

@FabianSchmengler太棒了,它起作用了!
Peter Jaap Blaakmeer

1
@AmitBera仅供参考:某些结帐插件使用AJAX提交账单/运输/ etc。我只需要修补一个。简单的方法是<script> var formKey =“ <?php echo Mage :: getSingleton('core / session')-> getFormKey();?>”; </ script>放入主题标题。然后,您可以将form_key:formKey作为参数添加到AJAX提交中。当然,请在测试表单后确认是否提交了新参数,然后像在帖子中提到的那样编辑Controller以对其进行处理。
Kalvin Klien

26

基于我对补丁文件的第一次审查...

  • 新设置admin/security/validate_formkey_checkout已添加。启用后,将检查结帐表单是否存在表单密钥。如果模板文件在主题中被覆盖,则需要在那里进行更新。默认情况下,此设置为关闭状态
  • 默认情况下(app/etc/config.xml)中似乎不允许符号链接。另外,允许它们的功能似乎已从管理员配置中删除。但是,如果您的站点先前明确启用了符号链接,则该设置将保存在数据库中,从而覆盖此更改。
  • 应用此修补程序时,您需要同时清除缓存和整个页面缓存。设计例外以与解码不兼容的格式保存。如果您不刷新页面缓存,则会看到类似“解码失败:语法错误”的错误。

1
您也可以只使用十六进制编辑器,然后自己将其添加到数据库中,但这对大多数人来说可能有点太多了
猫猫(猫)

1
如果您中的某些人正在使用CDN(例如cloudflare),请确保清除缓存。我尝试通过CDN激活进行结帐,并且无法通过“付款”页面。当我清除缓存并启用“开发”模式时,一切进展顺利。
图标

14

base/default受此补丁影响的文件下方,如果该文件位于您的主题中,请相应地进行更改

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

在上述所有以上phtml文件中,都添加了表单关键行,因此请将此行添加到您各自的phtml文件中。

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

对于上述问题,@ fabian创建了一个脚本,该脚本即使在主题文​​件中也将添加表单键

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

在应用安全补丁之后,如果您遇到表单密钥错误,则可以应用此补丁,因为应用此补丁的过程与安全补丁相同

  sh filename.sh

还有一个文件base/default更改Js

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

因此,如果此js文件是从您的主题加载的,请执行以下步骤

删除吹线

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

并在行下方而不是上方添加

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

编辑

并且,如果您使用的是任何覆盖以下文件的结帐扩展名,请在结帐扩展名的phtml文件中添加表单关键行。

EDIT2-问题

1)saveBillingAction()错误或获取表单密钥为空或表单密钥问题:补丁9767获取无效的表单密钥

2)Hunk#1 FAILED失败,为225。1个Hunk FAILED失败-将拒绝保存到文件app / design / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtml:SUPEE-9767-Hunk#1失败225。1个大块中有1个失败

3)将拒绝保存到文件app / code / core / Enterprise / PageCache / Model / Observer.php.rej:SUPEE-9767错误:补丁无法成功应用/恢复

4)SUPEE-9767,modman和符号链接:SUPEE-9767,modman和符号链接

5)app / design / frontend / rwd / default / layout / page.xml Hunk#1失败,达到36。Hunk#2失败,达到54。2之2失败:失败:SUPEE-9767错误

6)1个大块失败-将拒绝保存到文件app / code / core / Mage / Sales / Model / Quote / Item.php:Magento 1.9.2.2 SUPEE-9767补丁错误

7)单步签出错误(再次是表单密钥问题):SUPEE-9767 Magento CE 1.9.3.3单步签出在启用签出时无法使用表单密钥验证

8)一步结帐客户注册问题:SUPEE-9767补丁/ CE 1.9.3.3-一页结帐-客户注册问题

9)app / code / core / Mage / Core / Model / File / Validator / Image.php:Magento SUPEE 9697 1.9.2.2在Image.php失败


1
该修补程序的版本2应该很快就可用。错误应该得到修复。
图标

1
@icon等待v2
Murtuza Zabuawala

9

请注意,默认情况下,在新的Magento安装上,默认情况下始终禁用Symlinks 管理员YES / NO配置值,默认为“ NO”。现在,此更新显式禁用config.xml中的符号链接,并且作为额外的预防措施,还从admin-> developer中删除了包含配置选项的模板部分。

这不会影响您当前的符号链接设置,如果您在1.9.3.2之前手动启用了符号链接,它们将保持启用状态,尽管您无法在admin中看到该设置。

使用modman管理Magento 1.x模块的用户应确保他们不禁用符号链接,因为这将禁用modman模块。

负责的管理员可以通过以下方式再次启用symlink admin部分:在app / code / core / Mage / Core / etc / system.xml中查找对模板部分的差异更改,然后在第600行附近将该部分添加到system.xml中。仔细检查符号链接仍然启用

n98-magerun.phar config:dump | grep符号链接

以下是magento1933和magento1932的差异文件,可帮助您识别默认主题中可能影响自定义/扩展主题的更改。

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


他们为什么要删除“ Symlinks”选项?现在是否有一个漏洞向公众(管理员用户外部)开放,或者如果它在共享环境中只是一种风险?
PaddyD

这个线程似乎回答了我的问题:magento.stackexchange.com/questions/176952/…–
PaddyD

符号链接被禁用是有原因的。我建议复制而不是符号链接:magento.stackexchange.com/a/177149/54863
Barryvdh

9

问题:使用php7 有时会引发以下错误:

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}

可以肯定的是Zend版本必须要做一些事情。这是一个快速解决方案,但可以肯定不正确:

-> app / code / core / Enterprise / PageCache / Model / Observer.php:244将其替换为:

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

->和app / code / core / Enterprise / PageCache / Model / Observer.php:177,其中包含:

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

当然,创建一个插件来重写它。但是我敢肯定,这里还有更好的事情要做。

UPDATE(更好的解决方案)

->转到:lib / Zend / Json.php,在第76行之后添加:

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

创建扩展名以覆盖它,并且不编辑核心文件。


缓存已完全清除。这是不一样的问题。
folektoras133

2
我们遇到了同样的问题-恢复app / code / core / Enterprise / PageCache / Model / Observer.php消除了问题,但显然这不是正确的解决方法,只是预防 a:5:{i:0;s:29:"Decoding failed: Syntax error";i:1;s:1376:"#0 app/code/core/Enterprise/PageCache/Model/Observer.php(177): Zend_Json::decode('a:0:{}')
Judder

9

问题:动态代码或CSS在结帐时禁用了表单键输入元素

我看到的一个问题是,一页结帐过程中的动态代码(贝宝加上)在一步付款方式html 中覆盖fieldset元素-删除或禁用(使用CSS)隐藏的form_key元素。

解决方法是确保formkey元素不会被任何动态代码或CSS 禁用。将formkey代码移到fieldset元素之外也可能有帮助

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

您可以通过在检查方法移动时检查浏览器中的ajax网络请求来轻松确定是否检测到了form_key并将其发送到一页控制器,如果该表单,则每个方法都应在ajax表单数据中包含form键键不存在,但已对Magento源代码进行了修补,检查是否有影响表单键元素(即CSS或动态客户端更改)的外部代码。

在此处输入图片说明


2
这种修复似乎不适用于EE。我发现该文件也app/design/frontend/[package]/[theme]/template/giftcardaccount/onepage/payment/scripts.phtml 需要更新:第35-38行需要更新以包括|| elements[i].name == 'form_key'其他选择器,以保持禁用form_key表单字段。
Greg Nickoloff

谢谢g-man1066!那正是我遇到的问题。
grafikchaos


8

问题: 使用通用的Magento 5步骤结帐时,客户注册失败。

仅当我们启用表单密钥身份验证时才会出现此问题。使用的版本:1.7.0.2,但似乎有人发布了在1.9.3版本上也发生相同的问题。 SUPEE-9767补丁/ CE 1.9.3.3-一页结帐-客户注册问题

当转到结帐时,我们为您提供2个选项:作为来宾或登记者结帐单击“注册”,然后填写表格和密码,您将通过所有步骤并完成订单。下订单,但客户永远不会在magento中注册。看起来像客人下的订单。

当我回去并禁用了表单密钥身份验证,并尝试在注册为客户时下订单时,它被顺利放置,并且客户已在后端注册。


1
这里有一个关于这个问题的更详细的岗位magento.stackexchange.com/questions/177035/...
拉斐尔在数码钢琴艺术

8

更新13/07/2017 [问题已解决]

Magento团队已在此版本的补丁程序中发布了SUPEE-9767 V2,该问题解决了透明gif和png的问题。

您应该将所有更改还原到该线程中讨论的文件。然后还原已应用的V1补丁,最后应用新版本V2。


前-SUPEE-9767 V2

请不要使用下面讨论的代码,而是应用补丁的V2版本,此版本中讨论的问题已得到解决

如果有人遇到透明png的问题,那么当从管理面板上传透明png时,背景会变成黑色。(在产品上)与以下图片引入的回调有关:

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

目前,我不确定到底是什么导致了此行为,但是我试图弄清楚,我可以确认删除回调后,奇怪的行为将会消失。

在此处输入图片说明

更新

好的,我发现从SUPEE-9767也进行了更新的功能实际上破坏了png的透明度,即创建的原始图像的副本没有透明度。

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

更新

这是该功能的更新版本,用于保留png透明度

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

这两行需要添加到补丁中。更新功能app/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.'));
}

更新23/06/17

此功能的更新版本修复了PNG和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.'));
}

1
这解决了我在Magento 1.7安装中的问题。谢谢!
吉尔吉斯(Tjitse)

没关系,Tjitse只需记录下此更改,以防万一Magento团队不修复该补丁,则在下一个补丁时您必须将其还原。我已通过bugcrowd.com向社区提交了该问题,希望他们能尽快引入补丁修复。
Daniel Yovchev

这确实可以修复png,但不能修复透明的gif文件。gif文件需要使用imagecolortransparent进行稍微不同的处理
交替

感谢您指出这一点,请参见更新的功能,该功能还可以修复gif透明度。
Daniel Yovchev

7

问题:允许符号链接通知不显示给管理员

符号链接通知不会显示在管理通知区域中,因为它不包含在 <block type="core/text_list" name="notifications" as="notifications">

CE和EE的补丁如下:

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

问题</block>在的结尾checkout_formkey(这是自我终止的),因此关闭了父对象notifications。这导致notification_symlink不会包含在中core/text_list并且不会呈现。


这并不是真正的问题,通知已删除,因为已明确禁用符号链接,并删除了符号链接配置部分。无法在v1933中的admin中手动更改符号链接值,因此显示admin通知是毫无意义的。问题将出现在1933年的新安装中,在这些安装中,需要符号链接的用户(例如modman)不再可以手动启用它。一个人可以推断出Magento不会安装任何新的1.x版本...
paj

我不同意,如果此补丁已设置,则不会显式禁用该配置-仅在尚未设置的情况下才禁用它。因此,如果在此修补程序之前,实例在DB / local.xml中将dev / template / allow_symlink设置为yes,并且他们应用了修补程序,则它们应该收到警告,允许符号链接,因为它们可能会受到攻击。
mwylde

我明白你的意思,你是正确的。但是对于普通用户,他们将如何处理-由于已删除config选项,因此无法从管理员手动禁用它。22情况有点
麻烦

7

#patchday的小提示;在安装过程中复制1.9.3.3之后,请运行git diff -w --stat | grep -v " 2 +" | grep -v " 0"以快速查看文件中的较大更改。


7

问题:EE运输模板未修补

我修补了EE 1.13.1.0的安装,而企业发货模板(app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml)没有添加formkey,但是计费和付款模板却添加了。

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


我还需要(对于EE 1.14.2)将form_key添加到 /app/design/frontend/enterprise/default/template... .../checkout/cart/coupon.phtml.../giftcardaccount/cart/block.phtml .../giftcardaccount/cart/check.phtml
Greg Nickoloff

4

用SUPEE-9767修补的Magento EE版本存在问题(因此升级到1.14.3.3时不存在)。该页面上的表单键将被缓存。因此,当我刷新缓存并转到产品页面并确保页面已完全缓存(刷新两次)时,我应该能够将该产品添加到购物车中。

现在,当我打开其他浏览器(或隐身模式)时,打开同一页面并尝试将产品再次添加到购物车。由于有表单键,因此该产品不会添加到购物车中。现在,当您再次刷新缓存时,可以将产品再次添加到购物车中。

感谢Jasper Zeinstra


3

对于使用Magento Composer Intaller的开发人员,您可以将部署策略更改为Copy而不是Symlink。您还可以配置将模块文件附加到.gitignore,这样您的存储库将保持干净。

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


我们发现复制"magento-force": true,非常重要
Jeroen


2

问题:补丁正在开发香草Magento 1.7.0.0 [编辑]

在测试补丁脚本期间,我们发现Magento 1.7.0.0的补丁存在问题。不知道是否有人仍在使用它,但是无论如何在SUPEE-9767中是一个问题。我们使用原始安装,并且首先安装了所有以前的补丁。

使用PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh 的补丁文件:该补丁文件确实适用于Magento 1.7.0.1和1.7.0.2

问题摘要:

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

作为记录,在1.7.0.0上我们尝试在以下修补程序上进行:

$ 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

4
如果缺少该文件,则很可能尚未应用安全补丁SUPEE-7405。
Ryan Hoerr

@RyanHoerr,您是对的,因为官方文件PATCH_SUPEE-7405_CE_1.7.0.2_v1-2016-01-20-04-58-44.sh不适用于1.7.0.0 ,所以已跳过SUPEE-7405 。我创建了文件的固定版本。如果有人需要,请给我发消息。
Jeroen Vermeulen-MageHost

2

由于某些奇怪的行为,我只需要还原此修补程序。无论出于何种原因,某些用户都无法将某些商品添加到他们的购物车中。

我假设这与旧报价与该客户的当前报价冲突。我通过以用户身份登录来验证此问题,以确保它不仅是1D10T。

自从我上周五打了补丁以来,这一直是一个问题。我们正在使用1.14.2.4。我们已进行了大量修改,因此它可能对其他用户有效。只是警告!


没错,对于Magento的EE版本,补丁确实会中断添加到购物车的操作。基本上,由于PageCache模块具有一个版本的form_key生成逻辑,而会话具有其自己的版本,因此会发生此问题。当FPC具有所请求页面的缓存版本,但需要重新生成微型购物车时,将触发会话,该会话重新生成form_key,同时调用FPC保存并生成其自己的form_key。那时,form_key的会话值不同于存储在客户cookie(用于FPC处理器)中的会话值,因此您在添加到购物车控制器时获得了无效的密钥。
Stjepan

我也遇到这个问题。如果找到解决方法,我会通知您。
cmtickle

我解决了这个问题,在这里解释:magento.stackexchange.com/questions/177942/…–
cmtickle

有人知道SUPEE-9767 v2是否解决了这个问题?
一个门徒

2

问题: 1.6.0.0上的无限重定向循环

快速解决

在文件app / code / core / Mage / Core / Controller / Varien / Front.php中的方法受保护的函数_checkBaseUrl($ request)中找到以下几行

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

将这些行更改为

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

保存文件后(提交到REPO),清除缓存(删除var / cache文件夹中的所有内容)并重新加载店面。在应用SUPEE 9767修补程序后,您应该发现站点负载不再出现302重定向问题。

根本原因

重定向后,实际请求与URI之间的SCHEME值之差。例如:实际请求返回方案HTTP,但URI中的方案可以是HTTPS。

可能的潜在原因

  1. 您很可能在.htaccess文件中具有重定向规则,以将所有http请求重定向到https。用户请求http://yourdomain.com,您可能已更改了方案,并将其重定向到https:// yourdomain,而不是他实际请求的http://yourdomain.com

  2. 基本安全和不安全URL均以https开头



2

谁能告诉我在supee-9767中这是什么...?

在此处输入图片说明


1
jQuery 1.10.2版本被认为是易受攻击的,并被某些PCI扫描仪标记。不是1.12版本。
Ryan Hoerr

@Detzler StackExchange不是论坛。如果您想提一个问题,请张贴一个问题,而不是一个问题的答案。
toon81

1
Ryan Hoerr询问了该补丁程序带来的任何问题。因此,我告诉他一个可能的重大更改,如屏幕截图所示。我无法解释此更改的原因。所以我子问。那你怎么了
Detzler

2

该补丁甚至对于香草Magento 1.7.0.2也不起作用。

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

即使手动应用较旧的补丁程序也是如此。

$ 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

我发现的解决方案/问题是1.7.0.2补丁中的某些更改是针对1.9.2.3之前不存在的文件的。因此,运行修补程序脚本之前,我从全新的1.9.2.3安装中复制了以下文件:

  • 应用程序/代码/核心/法师/核心/模型/文件/验证器/Image.php
  • 应用/代码/核心/法师/销售/模型/报价/Item.php

该修补程序假定已应用所有其他安全修补程序。您正在谈论的文件是由以前的补丁程序添加/更改的。您至少缺少SUPEE-7405。
瑞安·霍尔

嗨,瑞安(Ryan),实际上我也尝试过申请7405,但也没有成功... $ ./PATCH_SUPEE-7405_CE_1.7.0.2_v1.1-2016-02-23-07-22-52 \(1) .sh正在检查是否可以成功应用/还原补丁...错误:无法成功应用/还原补丁。(..)Adminhtml / Helper / Sales.php Hunk#1 FAILED at121。1之1失败:失败-保存拒绝文件(..)Adminhtml / Helper / Sales.php.rej修补文件(..)/ Core / Model / Config.php Hunk#1失败,于1642年。1个Hunk FAILED失败-保存拒绝文件(..)Config.php.rej修补文件(..)/ Quote / Item.php Hunk#1在509 ....失败
里卡多·马丁斯

@RicardoMartins我如何解决此错误:修补文件app / locale / en_US / Mage_Adminhtml.csv Hunk#2 FAILED失败,为36。2个Hunk中的FAILED失败-将拒绝保存到文件app / locale / en_US / Mage_Adminhtml.csv.rej ?
zus

0

突出显示https://magento.stackexchange.com/a/176930/46249的附加内容

请注意,默认情况下,在新的Magento安装上,默认情况下始终禁用Symlinks管理员YES / NO配置值,默认为“ NO”。现在,此更新显式禁用config.xml中的符号链接,并且作为额外的预防措施,还从admin-> developer中删除了包含配置选项的模板部分。

这不会影响您当前的符号链接设置,如果您在1.9.3.2之前手动启用了符号链接,它们将保持启用状态,尽管您无法在admin中看到该设置。


粗体字不正确。如果更新到1.9.3.4(SUPEE-9767 V2)或更高版本,当前设置将被删除:

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

负责的管理员可以通过以下方式再次启用symlink admin部分:在app / code / core / Mage / Core / etc / system.xml中查找对模板部分的差异更改,然后在第600行附近将该部分添加到system.xml中。仔细检查符号链接仍然启用

只是使配置选项再次可见并不能解决问题。该选项显示出来,但是您不能更改配置,因为新引入的后端模型阻止保存该值。看到:

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

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

因此,您必须删除或覆盖此后端模型,请参阅在安装SUPEE-9767 V2之后如何启用符号链接?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.