Исправление безопасности SUPEE-10570 - Возможные проблемы?

45

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.

Райан Херр
источник
1
Для Open Source / Community Edition 1.x изменения шаблона внешнего интерфейса, по- видимому, не включены, поэтому, по крайней мере, это не должно создавать слишком много проблем. Тем не менее, резервное копирование базы данных настоятельно рекомендуется, поскольку в этот патч включены два сценария установки (обновления). Больше подробностей может последовать после того, как я исправлю первые среды.
Кристоф Фарнляйтнер
1
Если у вас есть магазины, использующие настраиваемую сетку adminhtml, которая включает имя магазина, патч теперь ускользает от него, вероятно, для исправления некоторых потенциальных эксплойтов, основанных на изменении имени магазина и рендеринга.
Эндрю Какенбос
Я до сих пор патчил 2 сайта на 1.9.0.1 без проблем.
asdfasdfasf
1
Я применил патч к 1.9.3.0, 1.9.0.1 и 1.9.1.0, пока никаких проблем
Дэвид,
2
Это из блога по безопасности: magento.com/security/patches/supee-10570 ПРИМЕЧАНИЕ. У некоторых клиентов возникают проблемы при оформлении заказа при попытке создать учетную запись при оформлении покупки. Обновление патча или обходной путь для исправления этой проблемы будут доступны в ближайшее время. Если вы столкнулись с этой проблемой прямо сейчас, рассмотрите возможность возврата части кода, вызвавшей эту проблему, применив следующий патч: invalid_sesssion_fix.patch из архива выпуска, раздел SUPEE-10570
Tankgirl,

Ответы:

29

Вот список измененных файлов патчем 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

РЕДАКТИРОВАТЬ

Наконец, после развертывания на моем сайте prod (CE 1.7.0.2), я заметил критическую проблему с блокировкой (процесс проверки заблокирован).

Контекст: после адреса шага 1, я непосредственно создаю И регистрирую клиента, он должен видеть только следующий шаг оформления заказа.

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

Аварийное исправление: в случае, если вы столкнулись с похожей проблемой при оформлении заказа / сеансе клиента, прокомментируйте строки 414-430 из app / code / 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];
//         }

РЕДАКТИРОВАТЬ (2)

Я думаю, что следующее условие всегда будет возвращать false (Mage_Core_Model_Session_Abstract_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 init.

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

Я сообщил об этой проблеме команде magento. Я дам отзыв здесь как можно скорее.


РЕДАКТИРОВАТЬ (3)

Новый патч - wip (на странице загрузки патента magento написано «SUPEE-10570 для CE 1.7.0.0 - ОБНОВЛЕНО ОБНОВЛЕНИЕ ПАТЧА, НЕ ИСПОЛЬЗУЙТЕ (0,06 МБ)»).


РЕДАКТИРОВАТЬ (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: очевидно, что некоторые другие файлы также изменены, пожалуйста, проверьте соответственно.

DarkCowboy
источник
1
@Icon: я только что сообщил об этой ошибке в magento. Я опубликую ответ, как только получу официальный отзыв.
DarkCowboy
4
@Icon / Soleil: К сожалению, пока нет официального ответа или исправления относительно моего запроса на исправление.
DarkCowboy
1
@DarkCowboy Я только что заметил, что как только вы перейдете на страницу загрузки патча, вы увидите, что команда Magento добавила заметку в патче 1.7.0.0 и 1.7.0.2. Похоже, идет новый патч.
Иконка
3
Привет всем. Я видел, что был добавлен новый патч ("PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-28-04-54-53.sh"). Вы можете увидеть разницу здесь (на левой панели 1-й патч "PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-23-06-28-18.sh"): diffchecker.com/uGON91aR . Так что не исправить на новом патче ?! Кроме того, уведомление «ОБНОВЛЕНО ПАТЧИК ОБНОВЛЕНО, НЕ ИСПОЛЬЗУЙТЕ» исчезло. Так что я немного путаю то, что делает основная команда magento с этой проблемой.
DarkCowboy
1
FYI, V2 патча по-прежнему перечисляет «SUPEE-10570_CE_v1.9.2.4 | CE_1.9.2.4 | v1» вapp/etc/applied.patches.list
Moose
9

(не уверен, что это было в примечаниях к выпуску с самого начала)

Известные проблемы

Эти две известные проблемы связаны с использованием тегов 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.

sv3n
источник
7

У меня была та же проблема, что и у @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()значение, означающее, что метод всегда возвращает значение false, и проверка завершается неудачно.

Изменение кода в 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 патча.

Дейв Герберт
источник
Привет Дейв. Кажется, вы столкнулись с той же проблемой, что и я. Что касается вашего исправления, с вашей инверсией второе условие вообще не будет проверяться ... Я исследую эти данные сеанса.
DarkCowboy
4
Обновление для 1.7.0.2 ожидается в середине марта. (v2 патча), проблема подтверждена.
Петр Каминский
Кто-нибудь проверял, поддерживает ли это решение проверку метки времени смены пароля, или же вновь открывается дыра в безопасности, которую они пытались исправить? Примечание. Если вы не заботитесь о преимуществах безопасности, вы можете просто отключить проверку отметки времени смены пароля, выполнив useValidateSessionPasswordTimestamp()возврат false. (изменение одной строки в одном файле)
Эрик Сеастранд,
Здравствуй. Мы оценили, что проблема «перенаправление с пустой корзиной» все еще существует с измененным порядком проверки. Мы отключили проверку «useValidateSessionPasswordTimestamp» до тех пор, пока magento не создаст обновление.
Стивен Фрицше
6

Мы увидели пустую страницу в / checkout / cart после применения 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.9.3.9 у меня работает нормально.
ТонкБерлин
4

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.

Примените эти исправления, чтобы исправить проблему.

Тайлер В.
источник
2
Убедитесь, что у вас установлены 9652 и 9767
Icon
Действительно, мы протестировали SUPEE-10570 на всех ванильных версиях Magento начиная с 1.6.0.0, и все это работает. Но только если вы применили все предыдущие патчи. Здесь вы можете посмотреть, какие исправления требуются: docs.google.com/spreadsheets/d/…
Йерун Вермёлен - MageHost
4

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, потому что они определяют константу правильно.

Тайлер В.
источник
Это было исправлено путем добавления const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';в начало файла, как это делается в большинстве других версий этого патча.
Тайлер В.
Да, похоже, что это специфично для патча
1.7.0.0
Тайлер может добавить исправление к вашему актуальному ответу, а не к разделу комментариев.
danmentzer
1
Также я хотел бы только отметить, что это также влияет на патчи для EE-версии патча, а также EE 1.12.0.0
danmentzer
3

Прежде всего вы должны проверить, если вы ранее применяли правильную версию SUPEE-6788 или SUPEE-7405, если нет, отменить неправильную версию, а затем применить правильную версию SUPEE-6788 / SUPEE-7405.

Затем попробуйте снова применить SUPEE-10570.

Vio
источник
2

Приведенные ниже файлы обновляются / добавляются после примененного патча 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атрибут создается в вашей таблице атрибутов клиента, а правильное значение сохраняется в этой таблице.

Рама Чандран М
источник
Я не смог найти password_created_at в базе данных CE, где также указана проблема.
ТонкБерлин
проверьте этот файл app / code / core / Mage / Customer / sql / customer_setup / upgrade-1.6.2.0.5.1.1-1.6.2.0.5.1.2.php
Рама Чандран М
2

Моя версия magento вер. 1.9.1.0.

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

Причина:

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

  2. отключен компилятор, оба вызова работают.

  3. включить компилятор только первый вызов работы, второй вызов не удалось.

Кто-нибудь может объяснить и дать хорошее решение?

июнь
источник
2

Проблемы с 1.7.0.2, которые я заметил, заключаются в следующем:

  1. Добавить продукт в корзину и перейти к оформлению заказа

  2. Нажмите «Зарегистрироваться»

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

ПРОБЛЕМА НАЧИНАЕТСЯ ЗДЕСЬ

5. Автоматически перенаправляется на ГЛАВНУЮ СТРАНИЦУ. Вы не видите подтверждение номера заказа. Но на самом деле заказ размещен и счет клиента создан.

Икона
источник
Вы нашли какое-нибудь решение для этого? Я сталкиваюсь с той же проблемой.
Парф Туммар
1
V2 патча вышел, проблема решена
Icon
2

Я столкнулся с той же проблемой, 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;
}

Если вы переопределите этот класс внутри локальной папки (не лучшая практика), у нас могут быть ошибки, сгенерированные этим классом.

phanvugiap
источник
2

Этот патч сломал часть менеджера иерархии 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 справа. Если вам действительно нужна эта функциональность, вы должны сделать запрос безопасности против функциональности, которая невелика.

показать нарушенную иерархию

Люк Роджерс
источник
0

Та же самая ошибка, что и у Тайлера, в 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
Рой Толедо
источник
проверьте, что вы установили предыдущий патч. конкретный патч 9767
Рама Чандран М
Запустил проверку на www.magereport.com, и он подтвердил, что все исправления были установлены.
Рой Толедо
Я проверю и предоставлю ответ
Рама Чандран М
1
@royToledo Убедитесь, что вы применили патч SUPEE-9652
Тайлер В.
0

Если у вас есть какой-либо инструмент обнаружения патчей, вам, вероятно, нужно изменить обнаружение, SUPEE-9562 потому что он SUPEE-10570изменяет тот же файл:

lib/Zend/Mail/Transport/Sendmail.php
Ozzie
источник
0

Патч был изменен Magento молча. Здесь показано с патчем для 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

Diff показывает, что предыдущий файл содержит файлы из Magento Enterprise Edition, которые содержат неправильную лицензию «Лицензионное соглашение конечного пользователя Magento Enterprise Edition». Это было исправлено в "Open Software License (OSL 3.0)".

fheyer
источник
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 не был применен.

Мукеш
источник