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

108

Новое исправление безопасности для Magento 1 устраняет 16 проблем APPSEC: https://magento.com/security/patches/supee-9767

Семь уязвимостей имеют оценку 8,0 или выше для CVSSv3 Severity , и они эксплуатируются в дикой природе, так что это критический патч. Сайты могут применять SUPEE-9767 или обновлять до новой версии CE 1.9.3.3 / EE 1.14.3.3.

На какие общие проблемы или подводные камни стоит обратить внимание при применении SUPEE-9767?


ОБНОВЛЕНИЕ 2017-07-12:

Magento выпустила SUPEE-9767 V2 и CE 1.9.3.4 для решения многих проблем из первоначального патча. Если вы применили V1, вы должны вернуться, а затем применить V2. Если вы еще не установили исправления, просто примените V2, и большинство вопросов, поднятых здесь, не будут актуальны.

Райан Херр
источник
«Семь уязвимостей имеют оценку 8,0 или выше для CVSSv3 Severity, и они эксплуатируются в дикой природе, так что это критический патч». Я просто хотел проверить, «атакующему» нужно войти в админку, чтобы совершить любой из этих подвигов?
PaddyD
3
да, вы должны иметь доступ администратора для использования ...
MagenX
Похоже, что патч не останавливает общую конечную точку перебора (т.е. / rss / order / new), которая, кажется, является наиболее распространенным способом, которым ботеры пытаются получить доступ к административным областям?
Рики Один Мэттьюс
1
Я использую это для RSS @RickyOdinMatthews в .htaccess RewriteRule ^/?(index.phprss|index.php/rss/catalog|index.php/rss/order|rss/catalog|rss/order).*$ /no-route [R=301,L,NC]
Ричард Фераро
@RichardFeraro Я использую nginx, но уже использую подобное решение. Я заметил, что боты, как правило, сканируют, и грубо форсируют эти конечные точки.
Рики Один Мэттьюс

Ответы:

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, вам также придется их обновить.

СОХРАНИТЕ ВРЕМЯ :

Фабиан Шменглер написал хороший маленький сценарий, чтобы обновить все эти вещи для вас, вы можете найти его здесь:

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

Symlinks

Этот патч удаляет поле конфигурации системы, которое позволяет вам разрешить использование символьных ссылок в бэкэнде. Раньше это было в Системе> Конфигурация> Разработчик> Шаблон> Разрешить символические ссылки . Теперь весь раздел Шаблонов пропал.

Кроме того, это поле теперь отключено по умолчанию через app/etc/config.xml

Самое смешное в том, что вы получите уведомление в бэкэнде, если у вас было включено это поле конфигурации до патча, но вы не сможете его отключить, так как поле пропало.

Единственный способ сделать это - выполнить следующий запрос SQL

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

осветление

Сначала я настоятельно рекомендую вам проверить эти два сообщения, которые помогут вам понять цель этой модификации Symlink:

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

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

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

Что делать : если вы, как и я, используете modman или composer с шаблонными символическими ссылками, вы столкнетесь с некоторыми проблемами. Я все еще пытаюсь выяснить, что лучше делать здесь, кроме работы с SQL-запросами.

Основной пост по этому вопросу: SUPEE-9767, modman и символические ссылки

Список возможных проблем

V2 был выпущен с того самого поста. Не забудьте обновить

ошибки

Слово «подтверждено» используется для подтвержденных ошибок. Если его там нет, значит, это может быть ошибка, но она еще не подтверждена.

Hunk Failed Issues

Обратите внимание, что все эти проблемы могут быть вызваны тем, что вы изменили исходный файл, чтобы дважды убедиться, что это не так:

  • Сделайте резервную копию файла, в котором вы получили ошибку Hunk Failed
  • Загрузите оригинальный файл из вашей версии Magento
  • Сравните оба файла

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

  • пользовательский шаблон в папке пользовательских тем
  • local.xml
  • приложение / код / ​​локальный файл

Если файлы не отличаются, то это либо проблема с правами доступа, либо «ошибка» в патче.

Рафаэль в цифровом пианизме
источник
1
@ Иконка Нет. Для двойной проверки используйте инструмент, на который я ссылался в верхней части моего ответа
Рафаэль в Digital
1
просто чтобы добавить в список «другие проблемы»: похоже, что magento.stackexchange.com/questions/167616/… не исправлен и в последней версии
Антон Борицкий
1
@RaphaelatDigitalPianism: magento.stackexchange.com/q/177560/51361
1
Еще одно дополнение к списку: патч ломает мультишиппинг для темы по умолчанию magento.stackexchange.com/questions/177681/…
Аад Матейссен
1
«Водяной знак становится черным, когда он прозрачный» - может подтвердить, что это правильно. Это происходит, когда вы загружаете любой прозрачный png в cms
pixiemedia
42

Issue1: 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, необходимо сделать это на

ниже файлы:

Issue2: form_key выдает форму оценки доставки на странице корзины:

Добавить form_key в оценочную форму доставки на странице корзины

Затем необходимо добавить ключ формы <?php echo $this->getBlockHtml('formkey') ?>

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

Проблема 3: Ошибка Magento Onepage Checkout opcheckout.js

Если вы используете одностраничный заказ по умолчанию и opcheckout.js затем должны проверить

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {доступно на opcheckout.js

Если не выходить то заменить

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

с участием

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

Для случая проблема 1, проблема 2, проблема 3 проблема может быть легко решена с помощью скрипта @FabianSchmengler add-checkout-form-key.sh . Это исправит проблему с вашими восприимчивыми файлами темы.

Проблема 4: неверный ключ формы после входа в систему клиента при перезаписи Mage_Customer_Model_Session

Если Mage_Customer_Model_Sessionкласс переписать или позвонили из

app/code/local/Mage/Customer/Model/Session.phpтогда у вас может возникнуть проблема с form_key, когда мы назначаем клиента для сеанса, используя setCustomerAsLoggedIn()/ или после того, как клиент установил сеанс.

В этом случае вы должны добавить

Mage :: getSingleton ( 'ядро / сессия') -> 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: проблема с ключом формы после выхода из системы

После выхода клиента из сеанса вы можете начать выпуск сеанса, если 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 CHECKOUT

Мы знаем, что патч 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 "checkout / onepage / (выставление счетов | оплата | доставка | shipping_method) .phtml" | grep -v "base / default" | grep -v "rwd / default"
Питер Яап Блакмир
6
или немедленно обновите их, добавив
Фабиан Шменглер,
это волшебство @FabianSchmengler !!! :)
Амит Бера
@FabianSchmengler потрясающе, это сработало!
Питер Яап Блакмер
1
@AmitBera FYI: некоторые плагины оформления заказа используют AJAX для отправки биллинга / доставки / и т. Д. Я просто должен был исправить один. Самый простой способ сделать это - положить <script> var formKey = "<? Php echo Mage :: getSingleton ('core / session') -> getFormKey ();?>"; </ script> в голову темы. Затем вы можете добавить form_key: formKey в качестве параметра для представления AJAX. Конечно, проверьте формы после, чтобы подтвердить отправку нового параметра и отредактируйте контроллер, чтобы обработать его, как вы упомянули в своем посте.
Кальвин Клиен
26

Основываясь на моем первом проходе при просмотре файла патча ...

  • Новый параметр admin/security/validate_formkey_checkoutбыл добавлен. При включении формы проверки проверяются на наличие ключа формы. Если файлы шаблонов переопределены в теме, их нужно будет обновить там. Эта настройка по умолчанию отключена
  • Симлинки, по-видимому, запрещены по умолчанию (в app/etc/config.xml). Кроме того, возможность разрешить их, похоже, была удалена из конфигурации администратора. Однако, если на вашем сайте ранее были явно включены символические ссылки, настройка будет сохранена в базе данных, отменяя это изменение.
  • При применении этого патча вам необходимо очистить как кеш, так и кеш полной страницы. Исключения дизайна сохраняются в формате, несовместимом с декодированием. Вы увидите ошибку типа «Ошибка декодирования: синтаксическая ошибка», если вы не очистите кэш страницы.
mpchadwick
источник
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') {

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

И если вы используете какое-либо расширение checkout, которое переопределяет указанные ниже файлы, добавьте строку ключа формы в phtml-файл расширения checkout.

EDIT2 - Проблемы

1) Ошибка при saveBillingAction () или получении нулевого ключа формы или проблеме с ключом формы: исправление 9767 получает недопустимый ключ формы

2) Hunk # 1 FAILED на 225. 1 из 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, модман и символические ссылки : SUPEE-9767, модман и символические ссылки

5) app / design / frontend / rwd / default / layout / page.xml Hunk # 1 FAILED на 36. Hunk # 2 FAILED на 54. 2 из 2 блоков СБОЙ : ошибка SUPEE-9767

6) 1 из 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 Patch / CE 1.9.3.3 - оформление заказа на одной странице - проблема регистрации клиента

9) приложение / код / ​​ядро ​​/ маг / ядро ​​/ модель / файл / валидатор / Image.php: Magento SUPEE 9697 1.9.2.2 не работает в Image.php

Муртуза Забуавала
источник
1
Версия 2 патча должна быть доступна в ближайшее время. Ошибки должны быть исправлены.
Иконка
1
@icon ждет v2
Муртуза Забуавала
9

Обратите внимание, что символические ссылки всегда были отключены по умолчанию в новых установках Magento. Администратор ДА / НЕТ значения конфигурации по умолчанию «НЕТ». Обновление теперь явно отключает символические ссылки в config.xml и в качестве дополнительной меры предосторожности также удаляет раздел шаблона из раздела admin-> developer, в котором содержится параметр конфигурации.

Это не повлияет на ваши текущие настройки символических ссылок, если вы вручную включили символические ссылки до 1.9.3.2, они останутся включенными, хотя вы больше не сможете видеть настройки в admin.

Пользователи, использующие modman для управления модулями Magento 1.x, должны убедиться, что они не отключают символические ссылки, так как это отключит модули modman.

Ответственные администраторы могут снова включить раздел администрирования символической ссылки, выполнив поиск изменений в разделе шаблона в app / code / core / Mage / Core / etc / system.xml и добавив этот раздел в ваш system.xml примерно на строке 600. Или двойная проверка символьных ссылок все еще включена с

Конфигурация n98-magerun.phar: дамп | grep symlink

Вот файл diff для magento1933 и magento1932, чтобы помочь идентифицировать изменения в теме по умолчанию, которые могут повлиять на ваши пользовательские / расширенные темы.

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

PAJ
источник
Почему они удалили опцию 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);
    }

Конечно, создайте аддон, чтобы переписать это. Но я уверен, что здесь есть что-то лучше.

ОБНОВЛЕНИЕ (Лучшее решение)

-> Перейти к: lib / Zend / Json.php и после строки 76 добавить это:

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

Создайте свое расширение, чтобы переопределить его и не редактируйте основной файл.

folektoras133
источник
Кеш был очищен полностью. Это не та же проблема.
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 отключает элемент ввода ключа формы при оформлении заказа

Проблема, с которой я столкнулся, заключается в том, что динамический код (paypal plus) в процессе оформления одной страницы перезаписывает элемент fieldset в форме одностадийного способа оплаты html - удаление или отключение (с помощью css) скрытого элемента form_key.

Исправление состоит в том, чтобы гарантировать, что элемент formkey не отключен никаким динамическим кодом или CSS. Перемещение кода formkey за пределы элемента fieldset также может помочь

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

Вы можете легко проверить, обнаружен ли form_key и отправлен ли он на одностраничный контроллер, проверяя сетевые запросы ajax в вашем браузере, когда вы переходите через методы извлечения, каждый метод должен включать ключ формы в данные формы ajax, если форма Ключ не существует, но в исходном коде Magento была исправлена ​​проверка на наличие внешнего кода, влияющего на элемент ключа формы, то есть на css или динамические изменения на стороне клиента.

введите описание изображения здесь

PAJ
источник
2
Это исправление не помогло мне с EE. Я обнаружил, что файл также app/design/frontend/[package]/[theme]/template/giftcardaccount/onepage/payment/scripts.phtml должен быть обновлен: необходимо обновить строки 35-38, чтобы включить их || elements[i].name == 'form_key'вместе с другими селекторами, чтобы поле формы form_key было отключено.
Грег
Спасибо g-man1066! Это была именно та проблема, которая у меня была.
grafikchaos
9

Проблема: отсутствуют исправления в head-simple.phtml

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

нужны те же исправления, что и

app/design/adminhtml/default/default/template/page/head.phtml
Уильям Тран
источник
Для тех, кто ищет, это исправить; github.com/nathandcornell/magento-patches/blob/…
Питер Яап Блакмир
8

ПРОБЛЕМА: Сбой регистрации клиента при использовании универсальной 5-ступенчатой ​​проверки Magento.

Эта проблема возникает только тогда, когда мы включаем аутентификацию с помощью ключа формы. Используемая версия: 1.7.0.2, но похоже, что кто-то опубликовал эту же проблему и в версии 1.9.3. Патч SUPEE-9767 / CE 1.9.3.3 - оформление заказа на одной странице - проблема с регистрацией клиента

При переходе к оформлению заказа у нас есть 2 варианта: ВЫБЕРИТЕ В КАЧЕСТВЕ ГОСТЯ ИЛИ РЕГИСТРАЦИИ После того, как вы нажмете «Зарегистрироваться» и заполните форму вместе с паролем, вы пройдете все этапы и выполните заказ. Заказ размещается, НО клиент никогда не регистрируется в magento. Похоже, Гость разместил заказ.

Когда я вернулся и отключил проверку подлинности с помощью ключа формы и попытался разместить заказ при регистрации в качестве клиента, он был размещен без каких-либо проблем, и клиент был зарегистрирован в бэкэнде.

Икона
источник
1
Вот более подробный пост об этой проблеме magento.stackexchange.com/questions/177035/…
Рафаэль в Digital
8

ОБНОВЛЕНИЕ 13/07/2017 [ПРОБЛЕМА ИСПРАВЛЕНА]

Команда Magento выпустила SUPEE-9767 V2 в этой версии патча, проблема с прозрачными GIF и PNG исправлена.

Вы должны отменить все изменения в файле, который обсуждался в этой теме. Затем отмените примененный патч V1 и, наконец, примените новую версию V2.


PRE - SUPEE-9767 V2

Пожалуйста, не используйте код, описанный ниже, вместо этого примените V2 патча, проблема, обсуждаемая ниже, уже исправлена ​​в этой версии

Если у кого-то возникают проблемы с прозрачными 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 просто запомните это изменение на тот случай, если команда Magento не исправит патч, вам придется отменить его, когда вы будете делать следующий патч. Я отправил эту проблему сообществу на bugcrowd.com, надеюсь, они скоро выпустят исправление.
Даниэль Йовчев
это исправляет это для pngs, но не для прозрачных gif-файлов. GIF-файлы требуют немного другой обработки с использованием imagecolortransparent
чередуйте
Спасибо за указание на это, смотрите обновленную функцию, которая также исправляет прозрачность GIF.
Даниэль Йовчев
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и не отображаются.

mwylde
источник
Это на самом деле не проблема, уведомление было удалено, потому что символические ссылки были явно отключены, а раздел конфигурации symlink удален. Невозможно вручную изменить значение символической ссылки в admin в v1933, поэтому показывать уведомление администратора довольно бессмысленно. Эта проблема будет касаться новых установок 1933 года, когда пользователи, которым требуются символические ссылки, например, для modman, больше не могут включать его вручную. Можно сделать вывод, что Magento не ожидает каких-либо новых установок 1.x ...
Пай
Я не согласен, этот патч явно не отключает конфигурацию, если она уже установлена ​​- он отключает ее, только если она еще не установлена. Следовательно, если для экземпляра dev / template / allow_symlink установлено значение yes в DB / local.xml до этого исправления и они применяют исправление, они ДОЛЖНЫ получить предупреждение о том, что символические ссылки разрешены, поскольку они потенциально уязвимы.
Mwylde
Я вижу вашу точку зрения, и вы правы. Но для обычного пользователя, что бы они тогда делали - невозможно вручную отключить его от администратора, так как опция конфигурации была удалена. Это что-то вроде
уловки
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) не был добавлен ключ формы, но в шаблонах биллинга и оплаты это было сделано.

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
Грег
4

Существует проблема с версиями Magento EE, которые исправлены с SUPEE-9767 (поэтому не с обновлениями до 1.14.3.3). Ключ формы на этой странице будет кэширован. Поэтому, когда я очищаю свой кэш, а затем перехожу на страницу продукта и проверяю, что страница полностью кэширована (обновите пару раз), я смогу добавить этот продукт в свою корзину.

Теперь, когда я открываю другой браузер (или режим инкогнито), открываю ту же страницу и пытаюсь снова добавить товар в корзину. Товар не будет добавлен в корзину из-за ключа формы. Теперь, когда вы снова очистите кеш, товар можно снова добавить в корзину.

Благодаря Джасперу Зейнстре

Арьен Мидема
источник
3

Для разработчиков, использующих Magento Composer Intaller, вы можете изменить стратегию развертывания на Копировать вместо 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 } }

Barryvdh
источник
Мы узнали, что с копией "magento-force": true,становится важным
Jeroen
2

Проблема: патч работал на ванильном Magento 1.7.0.0 [отредактировано]

Во время тестирования нашего патча мы обнаружили проблему в патче для Magento 1.7.0.0. Не знаю, использует ли кто-нибудь еще, но в любом случае это проблема в SUPEE-9767. Мы использовали ванильную установку и сначала установили все предыдущие патчи.

Patch файл используется: 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
Йерун Вермейлен - MageHost
источник
4
Если вам не хватает этого файла, скорее всего, вы не применили исправление безопасности SUPEE-7405.
Райан Херр
@RyanHoerr вы правы, SUPEE-7405 был пропущен, потому что официальный файл PATCH_SUPEE-7405_CE_1.7.0.2_v1-2016-01-20-04-58-44.shне работает для 1.7.0.0. Я создал фиксированную версию файла. Если кому-то это нужно, пришлите мне сообщение.
Йерун Вермёлен - MageHost
2

Мне просто пришлось отменить этот патч из-за странного поведения. По какой-то причине определенные пользователи не могут добавлять определенные товары в свою корзину.

Я предполагаю, что это как-то связано со старыми цитатами, сталкивающимися с текущей цитатой для этого клиента. Я подтвердил эту проблему, войдя в систему как пользователь, чтобы убедиться, что это был не просто 1D10T.

Это было проблемой с тех пор, как я взял этот патч в прошлую пятницу. Мы используем 1.14.2.4 . Мы сильно изменены, поэтому он может отлично работать для других пользователей. Просто предупреждение!

Ученик одного
источник
Это верно, патч не работает, добавьте в корзину действие для EE-версии Magento. По сути, проблема возникает из-за того, что у модуля PageCache есть одна версия логики генерации form_key, в то время как у сеанса есть своя собственная. Когда FPC имеет кэшированную версию запрошенной страницы, но нуждается в регенерации мини-карты, запускается сеанс, который восстанавливает form_key одновременно с вызовом сохранения FPC, который генерирует свой собственный form_key. В этот момент значение сеанса form_key отличается от значения, хранящегося в файле cookie клиента (используется в процессоре FPC), поэтому вы получаете неверный ключ при добавлении в контроллер корзины.
Степан
Я также сталкиваюсь с этой проблемой. Я дам вам знать, если найду решение.
cmtickle
Я решил эту проблему, объяснение здесь: magento.stackexchange.com/questions/177942/…
cmtickle
Кто-нибудь знает, разрешается ли это в SUPEE-9767 v2?
Ученик 1
2

Проблема: бесконечный цикл перенаправления на 1.6.0.0

Быстрая починка

Найдите следующие строки внутри защищенной методом метода _checkBaseUrl ($ request) в файле app / code / core / Mage / Core / Controller / Varien / Front.php

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

Измените эти строки на

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

После этого сохраните файл (подтвердите свое REPO), очистите кеш (удалите все, что находится в папке var / cache) и перезагрузите ваш магазин. После применения исправления SUPEE 9767 вы должны найти, что сайт загружается без проблем с перенаправлением 302.

Основная причина

Разница в значении SCHEME между фактическим запросом и URI после перенаправления. Например: фактический запрос возвращает схему HTTP, но схема в URI может быть HTTPS.

Возможные основные причины

  1. Скорее всего, в файле .htaccess есть правило перенаправления для перенаправления всех http-запросов в https. Пользователь запрашивает http://yourdomain.com, и вы, возможно, изменили схему и перенаправили его на https: // yourdomain вместо http://yourdomain.com, который он фактически запрашивал.

  2. Как базовые, так и незащищенные URL-адреса начинаются с https

Haijerome
источник
2

ПОДТВЕРЖДЕННАЯ ОШИБКА «Регистрация клиента не удалась при оформлении заказа» произошла немного по-другому с моей стороны.

Если клиент выбирает зарегистрироваться в кассе, его пароль хранится неправильно. Клиент создан правильно, просто пароль не сохраняется. Я обнаружил это по тому, что пароль не был показан в приветственном письме. Люди не могут войти из-за этого тоже.

Исправлена ошибка, связанная с патчем SUPEE-9767 / CE 1.9.3.3 - одностраничная проверка - проблема с регистрацией клиентов также выполнила эту работу и для меня.

ahe_borriglione
источник
2

Может кто-нибудь сказать мне, что это за ... это в supee-9767?

введите описание изображения здесь

Detzler
источник
1
Версия jQuery 1.10.2 считается уязвимой и помечена некоторыми сканерами PCI. Версия 1.12 - нет.
Райан Херр
@Detzler StackExchange не является форумом. Если вы хотите задать вопрос, вы должны опубликовать один, а не ответ на вопрос.
toon81
1
Райан Херр спросил о любых проблемах, связанных с патчем. Поэтому я рассказал ему о возможном критическом изменении, как вы видите на скриншоте. Я не могу объяснить причину этого изменения. Поэтому я саб спросил. Так в чем твоя проблема?
Детцлер
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 перед запуском сценария исправления:

  • Приложение / код / ​​ядро ​​/ Mage / Ядро / Модель / Файл / Оценщик / image.php
  • Приложение / код / ​​ядро ​​/ Mage / Sales / модель / Quote / Item.php
Рикардо Мартинс
источник
Патч предполагает, что все остальные патчи безопасности уже были применены. Файлы, о которых вы говорите, были добавлены / изменены предыдущими патчами. Вы пропускаете хотя бы SUPEE-7405.
Райан Херр
Привет Райан, На самом деле я тоже пытался применить 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 at 121. 1 из 1 hunk FAILED - сохранение отклонено в файл (..) Adminhtml / Helper / Sales.php.rej файл исправления (..) / Ядро Core / Model / Config.php # 1 СБОЙ в 1642. Сбои 1 из 1: Сбой при сохранении отклонений в файл (..) Файл исправления Config.php.rej (..) / Quote / Item.php Hunk # 1 Не удалось в 509 ....
Рикардо Мартинс
@RicardoMartins, как я могу решить эту ошибку: исправление файла app / locale / en_US / Mage_Adminhtml.csv Hunk # 2 FAILED на 36. 1 из 2 блоков FAILED - сохранение отклоняет в файл app / locale / en_US / Mage_Adminhtml.csv.rej ?
Zus
0

Просто дополнение к https://magento.stackexchange.com/a/176930/46249

Обратите внимание, что символические ссылки всегда были отключены по умолчанию в новых установках Magento. Администратор ДА / НЕТ значения конфигурации по умолчанию «НЕТ». Обновление теперь явно отключает символические ссылки в 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'
    ))
);

Ответственные администраторы могут снова включить раздел администрирования символической ссылки, выполнив поиск изменений в разделе шаблона в app / code / core / Mage / Core / etc / system.xml и добавив этот раздел в ваш system.xml примерно на строке 600. Или двойная проверка символьных ссылок все еще включена с

Просто сделайте опцию config видимой снова, это не решит проблему. Опция появляется, но вы не можете изменить конфигурацию, так как недавно представленная модель бэкэнда не позволяет сохранить значение. Видеть:

# 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?

sv3n
источник