Патч безпеки SUPEE-10570 - Можливі проблеми?

Magento випустив новий патч безпеки для M1 та оновлення для M1 та M2.

На які проблеми слід звертати увагу при оновленні чи застосуванні цього виправлення?

SUPEE-10570

SUPEE-10570, Magento Commerce 1.14.3.8 та Open Source 1.9.3.8 містять кілька покращень безпеки, які допомагають закрити віддалене виконання коду (RCE), сценарій крос-сайтів (XSS та інші проблеми). Ці випуски містять також невеликі функціональні виправлення, перелічені у розділі випустити нотатки.

MAGENTO 2.2.3, 2.1.12 І 2.0.18 ОНОВЛЕННЯ БЕЗПЕКИ

Magento Commerce та Open Source 2.2.3, 2.1.12 та 2.0.18 містять декілька вдосконалень безпеки, які допомагають закрити міжсайтовий сценарій (XSS), автентифіковане виконання віддаленого коду адміністратора користувача (RCE) та інші вразливості. Випуски включають додаткові функціональні виправлення. Щоб дізнатися більше про функціональні виправлення, будь ласка, перегляньте Примітки до випусків Magento Commerce 2.0.18, 2.1.12, 2.2.3 та Magento Open Source 2.0.18, 2.1.12, 2.2.3.

Ось список модифікованих файлів за допомогою патча SUPEE-10570:

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

EDIT

Нарешті, після розгортання на своєму веб-сайті prod (CE 1.7.0.2), я помітив критичну проблему блокування (процес оформлення замовлення заблокований).

Контекст: після кроку 1 адреси я безпосередньо створюю І реєструю клієнта, він повинен бачити лише наступний крок оформлення замовлення.

Проблема: після supee-10570 процес оформлення замовлення порушується після кроку 1 (у випадку створення облікового запису), і клієнт перенаправляється на домашню сторінку (з кошиком порожній + вийшов) = неможливо досягти замовлення.

Виправлення у надзвичайних ситуаціях: Якщо у вас виникли подібні проблеми з вашим сеансом оформлення замовлення / клієнта, прокоментуйте рядки 414-430 з програми / код / ​​core / Mage / Core / Model / Session / Abstract / Varien.php (ті, які додає патч , Дивіться нижче).

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

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

EDIT (2)

Я думаю, що наступна умова завжди повернеться хибною (Mage_Core_Model_Session_Ab абстракт_Varien у рядках 414-419, особливо рядках 417 + 418).

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

VALIDATOR_PASSWORD_CREATE_TIMESTAMP завжди буде більше VALIDATOR_SESSION_EXPIRE_TIMESTAMP. Позначення часу "закінчення сеансу" переосмислюється при створенні облікового запису, тому неминуче старше сесії init.

Так, наприклад, якщо ви створили клієнта під час оформлення замовлення, він повернеться помилковим, і клієнт буде просто викинутий (= завершити замовлення, перенаправити на домашню сторінку та кошик порожній). Досить погано.

Я повідомив про це питання команді magento. Я дам тут відгуки якнайскоріше.

EDIT (3)

Новий патч - Wip (на сторінці завантаження патчу magento написано "SUPEE-10570 для CE 1.7.0.0 - ОНОВЛЕНИЙ ПАТЧ ОЧАКОВАНО, НЕ ВИКОРИСТОВУЙТЕ (0,06 МБ)").

EDIT (4) ~ 1 місяць після повідомлення про початкове блокування

Привіт! Сподіваємось, що ви всі товари (і сподіваємось, що ви до цього часу не зберігали початковий стан виправлення, якщо дохід вашого бізнесу, ймовірно, серйозно не зменшився ^^).

Я помітив наступне речення з офіційної сторінки: "Magento тепер надає оновлений патч (SUPEE-10570v2), який більше не викликає цю проблему. Однак зауважте, що цей новий патч більше не захищає від двох серій з низьким ризиком, пов'язаних з обробкою. проблеми безпеки, від яких патч SUPEE-10570 захищений. " з офіційної сторінки supee-10570.

На сторінці релізу ми можемо нарешті знайти файл v2 (PATCH_SUPEE-10570_CE_v1.7.0.2_v2-2018-03-29-08-52-37.sh).

Я детально дослідив модифікації. Нарешті, здається, команда magento просто вирішила скинути частину безпеки. Сподіваємось, що ця дірка в безпеці не спричинить серйозних пошкоджень (вона є критичною, згідно офіційної записки).

Після відновлення v1 + застосувати v2, будь ласка, подбайте, щоб наступні файли були повернені як їх початковий стан (до того, як v1 було застосовано):

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

PS: очевидно, деякі інші файли також змінені, будь ласка, перевірте їх.

(не впевнений, чи це було у примітках до випуску від початку)

Відомі проблеми

Ці дві відомі проблеми пов'язані з використанням тегів HTML в атрибуті SKU продукту:

• Якщо ви намагаєтеся імпортувати продукти, що містять HTML-теги в атрибуті SKU, Magento відображає цю помилку на етапі перевірки даних (тобто, коли ви натискаєте Перевірити дані ):
 Invalid value in SKU column. HTML tags are not allowed.
• Якщо ви намагаєтеся створити або відредагувати продукт на панелі адміністратора, а значення атрибута SKU продукту містить теги HTML, Magento видає цю помилку, намагаючись зберегти продукт: HTML tags are not allowed in SKU attribute.

З патч-нот :

Якщо патч не вдасться застосувати під час виправлення lib/Zend/Mail/Transport/Sendmail.php, це може означати, що ваша установка Magento була попередньо виправлена ​​з SUPEE-9652v1 замість SUPEE-9652v2. Рекомендоване рішення полягає в тому, щоб відновити виправлення SUPEE-9652v1 та застосувати SUPEE-9652v2 перед застосуванням SUPEE-10570.

У мене був такий самий випуск, що і у @DarkCowboy після застосування патчу до Magento CE 1.7.0.2.

Після вибору зареєструватися як новий клієнт під час оформлення замовлення, замовлення створює як замовлення, так і замовника, але замість відображення сторінки успіху замовлення я переадресовуюсь на головну сторінку та виходжу з системи.

Я знайшов рішення - змінити порядок блоків коду в змінах app/code/core/Mage/Core/Model/Session/Abstract/Varien.php.

Порівнюючи виправлену версію з тим самим файлом у Magento CE 1.9.3.8, я знайшов нові блоки для перевірки терміну дії сеансу, а часові позначки паролів у іншому порядку.

Magento CE 1.9.3.8 - лінії 476-491:

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

Magento CE 1.7.0.2 - лінії 414-430:

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

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

Це призводить до того, що значення $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]перевищує $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()значення, тобто метод завжди повертає помилкове значення, а перевірка завершується невдало.

Зміна коду в Magento CE 1.7.0.2 відповідно до версії Magento CE 1.9.3.8 виправляє проблему.

Отриманий код для Magento CE 1.7.0.2 - рядки 414-430:

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

Я б запропонував створити власний файл виправлення та застосувати безпосередньо до основного файлу (саме так я зазвичай підходжу до виправлення помилок у ядрі). Це дозволить легко відновити, якщо Magento видає версію 2 виправлення.

Ми побачили порожню сторінку в / касі / кошику після застосування SUPEE-10570 та компіляції. Просто для уточнення: з деактивованим компілятором все пішло добре, при активованому компіляторі ми бачили лише порожню сторінку кошика при вході в систему без записів журналу (навіть після активації всіх можливих журналів та режиму розробника).

Рішення було змінити функцію getPasswordTimestamp()в app/code/core/Mage/Customer/Helper/Data.php(звичайно ж з допомогою: app/code/local/Mage/Customer/Helper/Data.php!) І використовувати Mage::getSingleton('core/resource')замість Mage::getModel('customer/customer')або Mage::getSingleton('customer/session'). Тому замініть цілу функцію, наприклад, цими рядками коду:

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

Після перекомпіляції проблеми не було. Ще хтось із цією проблемою?

Пояснення німецькою мовою тут .

1.7.0.0

Патч: PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh

Ця помилка трапляється, якщо ви раніше не застосовували SUPEE-9652 або SUPEE-9767

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

Застосуйте ці виправлення для виправлення проблеми.

1.7.0.0

Патч- PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh файлapp/code/core/Mage/Core/Model/Session/Abstract/Varien.php

Патч для 1.7.0.0 додає лише одну константу:

+    const VALIDATOR_PASSWORD_CREATE_TIMESTAMP   = 'password_create_timestamp';

Однак він додає використання двох нових констант, особливо цієї:

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

Це призводить до помилки:

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

Виправлення:

Додайте визначення цієї другої константи вище або нижче першої константи, доданої цим патчем.

const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';

Поки що я не бачив цього питання ні в одному з 1.9. або 1.14.x виправлення, тому що вони визначають константу правильно.

Перше, що вам слід перевірити, чи раніше ви застосували правильну версію SUPEE-6788 або SUPEE-7405, якщо не скасувати неправильну версію, а потім застосувати правильну версію SUPEE-6788 / SUPEE-7405.

Потім спробуйте застосувати SUPEE-10570.

Наведені нижче файли оновлюються / додаються після застосованого патчу SUPEE - 10570 в EE

@DarkCowboy надав перелік файлів, крім цих файлів EE :

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

Деякі важливі замітки

password_created_at створено в таблиці атрибутів клієнта.

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

Ці вище файли використовуються для створення та перевірки. Проблема сеансу виникає під час перевірки або перевірки входу користувача, перелічені вище файли перезаписуються у вашому локальному пулі, або будь-який password_created_atатрибут створюється в таблиці атрибутів клієнта, а відповідне значення зберігається в цій таблиці.

Моя версія magento - вер. 1.9.1.0.

Ми побачили порожню сторінку в / касі / кошику після застосування SUPEE-10570 та компіляції. Просто для уточнення: з деактивованим компілятором все пішло добре, при активованому компіляторі ми бачили лише порожню сторінку кошика при вході в систему без записів журналу (навіть після активації всіх можливих журналів та режиму розробника).

Причина:

1. функція getPasswordTimestamp буде викликати два рази під час входу в систему та відвідування / оформлення замовлення / кошика.

2. відключений компілятор і робота виклику.

3. увімкнути компілятор лише першого виклику, другий виклик не вдався.

хтось може пояснити і дати хороше рішення?

Проблеми з 1.7.0.2, які я помітив, такі:

1. Додати товар у кошик та перейти до каси

2. Натисніть "Зареєструватися"

3. Заповніть всю необхідну інформацію про замовлення, включаючи дані про оплату тощо.
4. Натисніть Повне замовлення.

ПРОБЛЕМА ЗАЧУТИ ТУТ

5. Автоматично перенаправляйтесь на ДОМАШНУ СТРАНИЦУ. Ви не можете переглянути підтвердження номера замовлення. Але насправді розміщується замовлення та створюється рахунок клієнта.

Я зіткнувся з тією ж проблемою, Magento 1.9.3.8 додав цей метод до класу Mage_Customer_Helper_Data

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

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

Якщо ви перекрили цей клас у локальній папці (не найкраща практика), у нас можуть виникнути помилки, згенеровані цим класом.

Цей патч порушив деякий диспетчер ієрархій CMS для користувачів EE.

Це пояснюється наступною лінією виправлень, яка відповідає за вимкнення назв магазинів / веб-сайтів та виправлення APPSEC-1873/1979/1980.

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

Він повинен показувати селектор магазину зліва, але замість нього відображається html справа. Якщо вам справді потрібна ця функціональність, вам потрібно здійснити виклик безпеки та функціональності, який не є великим.

Точна помилка, що і Тайлер, у Magento 1.9.2.4 Patch PATCH_SUPEE-10570_CE_v1.9.2.4_v1-2018-02-28-04-53-53.sh

checking file lib/Zend/Mail/Transport/Sendmail.php
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 129.
2 out of 2 hunks FAILED

Якщо у вас є інструмент виявлення патчів, вам, ймовірно, потрібно змінити виявлення, SUPEE-9562 оскільки він SUPEE-10570змінює той самий файл:

lib/Zend/Mail/Transport/Sendmail.php

Патч змінив Магенто мовчки. Тут показано патч для Magento 1.8.1.0-1.9.0.1. При першому завантаженні я отримав файл

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

Через кілька днів я отримав наступний файл

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

Діфф показує, що колишній файл містить файли Magento Enterprise Edition, які містять неправильну ліцензію "Ліцензійна угода кінцевого користувача Magento Enterprise Edition". Це було виправлено "Ліцензія на відкрите програмне забезпечення (OSL 3.0)".

Ви можете отримати наступну помилку

Hunk #3 FAILED at 17 після рядка

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

Це сталося зі мною на Magento 1.10.0.2EE версії. Це сталося тому, що патч SUPEE-6285 не застосовувався.