Проблема 1: ключ формы недействителен при оформлении заказа на странице

Magento добавляет form_key в большинство форм.

Если у вас есть using default onepage and using custom theme, то вы начнете получать **form_key проблему при оформлении заказа на каждом шаге **;

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

Для формирования файлов каждого шага проверки, если ниже указаны файлы выходы,

• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/billing.phtml
• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/payment.phtml

• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping.phtml

• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping_method.phtml

Если файлы шаблонов вызов из базовой темы тогда это не создает проблем. Потому что патч автоматически обновит эти файлы.

Также обратите внимание: <?php echo $this->getBlockHtml('formkey') ?> должен всегда находиться внутри тега формы

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

** Если вы используете заказ с несколькими отправками Magento, то это необходимо сделать по адресу

Файлы ниже:

Проблема 2: проблема с ключом form_key для формы оценки доставки на странице корзины:

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

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

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

Проблема 3: Проверка на странице Magento opcheckout.js ошибка

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

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

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

Если (элементы [i].имя=='платеж [способ]') {

С

Если (элементы [i].имя=='платеж [способ]'||элементы [i].имя== 'форм_кей') {

В случае проблемы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()/или после того, как клиент установлен на сеансе.

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

Маг::getSingleton('ядро/сессия')->Обновить ключ();

В setcustomerasлоггедин() перед вызовом

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

Мы знаем, что выпуск исправления supee-9767 в целях безопасности, если вы используете проверку ONESTEP, вам следует добавить проверку form_key, чтобы СОХРАНИТЬ действие вашего контроллера проверки onestep.

Предположим, что для сохранения сведений о способе доставки в вашем заказе onestep используется метод saveShippingmethod(), затем вы должны добавить

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

Также на вы должны добавить ключ формы <?php echo $this->getBlockHtml('formkey') ?> на твоем месте проверка файлов phtml в соответствующем разделе

Некоторая связанная ссылка

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

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

• Добавлена новая настройка admin/security/validate_formkey_checkout. При включении формы оформления заказа проверяются на наличие ключа формы. Если файлы шаблонов переопределены в теме, их необходимо будет обновить там. Этот параметр, похоже, отключен по умолчанию
• Символические ссылки, похоже, запрещены по умолчанию (в app/etc/config.xml). Кроме того, возможность разрешить их, похоже, была удалена из конфигурации администратора. Однако, если ваш сайт ранее явно включенные символические ссылки, настройка будет сохранена в базе данных, переопределяя это изменение.
• При применении этого исправления вам необходимо очистить как кэш, так и полный кэш страницы. Конструктивные исключения сохраняются в формате, несовместимом с декодированием. Вы увидите ошибку, подобную этой "Ошибка декодирования: синтаксическая ошибка", если вы не очистите кэш страницы.

Ниже base/default файл, затронутый этим исправлением, если эти файлы были в вашей теме, пожалуйста, внесите соответствующие изменения

app/design/frontend/base/default/template/checkout/cart/shipping.phtml

app/design/frontend/base/default/template/checkout/multishipping/billing.phtml

app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/billing.phtml

app/design/frontend/base/default/template/checkout/onepage/payment.phtml

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

app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml

app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml

Во всех вышеперечисленных phtml файлах ниже добавлена строка ключа формы, поэтому, пожалуйста, добавьте эту строку в ваш соответствующий файл phtml.

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

Для вышеуказанной проблемы @fabian создал скрипт, который добавит ключ формы даже в ваш файл темы

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

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

  sh filename.sh

И одно base/default изменение в Js файле

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

Поэтому, если этот js файл загружается из вашей темы, выполните следующие действия

Удалить линию обдува

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

И добавьте строку ниже вместо строки выше

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

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

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

ПРАВКА2 -- Проблемы

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

2) Ломоть №1 НЕ УДАЛСЯ на 225,1 из 1 ломоть НЕ УДАЛСЯ - сохранение отклонений в файл приложение/дизайн/интерфейс/предприятие/по умолчанию/шаблон/постоянный/проверка/onepage/выставление счетов.phtml: SUPEE-9767 - Ломоть №1 НЕ УДАЛСЯ на 225,1 из 1 ломоть ПОТЕРПЕЛ НЕУДАЧУ

3) сохранение отклонений в файле приложение/код/ядро/Предприятие/Кэш страниц/Модель/Наблюдатель.php.rej: ОШИБКА SUPEE-9767: Исправление не может быть успешно применено/отменено

4) SUPEE-9767, модман и символические ссылки: SUPEE-9767, модман и символические ссылки

5) app/design/frontend/rwd/default/layout/page.xml Красавчик № 1 ПОТЕРПЕЛ НЕУДАЧУ в 36 лет. Кусок №2 НЕ УДАЛСЯ в 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) Ошибка проверки onestep (опять же, это проблема с ключом формы): SUPEE-9767 Magento CE 1.9.3.3 Проверка Onestep не работает с включенной проверкой ключа формы При оформлении заказа

8) проблема с регистрацией клиентов в один шаг: Исправление SUPEE-9767/CE 1.9.3.3 - Проверка одной страницы - Проблема с регистрацией клиентов

9) app/code/core/Mage/Core/Model/File/Validator/Image.php : Magento SUPEE 9697 1.9.2.2 сбой при Image.php

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

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

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

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

n98- магерун.конфигурация phar: символическая ссылка на дамп|grep

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

Разница -r magento1933 magento1932> https://pastebin.com/ADzMBLhr

Проблема: При использовании 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 должна что-то с этим сделать. Быстрое исправление заключается в следующем, но оно наверняка неверно:

->приложение/код/ядро/Предприятие/Кэш страниц/Модель/Наблюдатель.php:244 замените его на:

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

-> и приложение/код/ядро/Предприятие/Кэш страниц/Модель/Наблюдатель.php:177 с:

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

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

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

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

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

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

Проблема: Динамический код или css отключает элемент ввода ключа формы при оформлении заказа

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

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

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

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

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

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

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

app/design/adminhtml/default/default/template/page/head.phtml

ПРОБЛЕМА: Регистрация клиента завершается неудачно при использовании универсального 5-шагового оформления заказа Magento.

Эта проблема возникает только тогда, когда мы ВКЛЮЧАЕМ аутентификацию по ключу формы. Используемая версия: 1.7.0.2, но, похоже, кто-то опубликовал, что та же проблема возникает и в версии 1.9.3. Исправление SUPEE-9767/CE 1.9.3.3 - Оформление заказа на одну страницу - Проблема с регистрацией клиента

Когда мы переходим к оформлению заказа, нам предлагается 2 варианта: ОФОРМИТЬ ЗАКАЗ В КАЧЕСТВЕ ГОСТЯ ИЛИ ЗАРЕГИСТРИРОВАТЬСЯ один раз нажмите "Зарегистрироваться" и заполните форму вместе с паролем, вы выполните все шаги и завершите заказ. Заказ размещается, НО клиент никогда не регистрируется в magento. Похоже, что гость сделал заказ.

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

ОБНОВЛЕНИЕ 13.07.2017 [ПРОБЛЕМА ИСПРАВЛЕНА]

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

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

ПРЕДВАРИТЕЛЬНАЯ ВЕРСИЯ-9767 V2

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

Если у кого-то возникли проблемы с прозрачными 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.'));
}

Проблема: Разрешить уведомление о символической ссылке, не показываемое администраторам

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

Маленький совет для #patchday; после копирования 1.9.3.3 поверх вашей установки запустите git diff -w --stat | grep -v " 2 +" | grep -v " 0", чтобы быстро увидеть большие изменения в файлах.

Проблема: Шаблон доставки 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 был исправлен.

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

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

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

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

У меня была проблема с EE 1.14.2.2 с включенным FPC, и этот патч был применен.

Периодически пользователи не могли добавлять в корзину.

Объяснение и исправление здесь: Проблема SUPEE-9767: Проблема добавления в корзину, Кэш полной страницы предприятия

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

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

Используемый файл исправления: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh Файл исправлений действительно работает для Magento 1.7.0.1 и 1.7.0.2

Краткое описание проблем:

ERROR: Patch can't be applied/reverted successfully.
...
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
...
checking file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED
...

Для записи, это на 1.7.0.0, на котором мы опробовали патч:

$ grep SUPEE app/etc/applied.patches.list
2017-06-01 12:59:49 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
-e 2017-06-01 12:59:49 UTC | SUPEE-1049 | EE-1.12.0.2 | v1 | 6d06f286f461562fa6d6573349f1491f7bf89859 | Wed Feb 13 17:46:13 2013 -0800 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-01 12:59:49 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-01 12:59:49 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-01 12:59:49 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-01 12:59:49 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-01 12:59:49 UTC | SUPEE-6788 | CE_1.7.0.1 | v1 | 04d237d56b116989e46839c41691585d927f99db | Fri Oct 23 13:52:50 2015 +0300 | f69136a
2017-06-01 12:59:49 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-01 12:59:50 UTC | SUPEE-8788 | CE_1.7.0.0 | v2 | 6b5ef4fc5b09af74d0fd401440948d0a54dd203d | Fri Oct 14 19:27:22 2016 +0300 | 84fa3dd598466fa5c482965a3f8e5395af33bf9d
2017-06-01 12:59:50 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-01 12:59:50 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523

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

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

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

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

Быстрое Решение

Найдите следующие строки внутри метода защищенная функция _checkBaseUrl($запрос) в файле 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
 ) { 

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

Первопричина

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

Возможные Глубинные Причины

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

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

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

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

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

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

Патч не работает даже для ванильного Magento 1.7.0.2.

[email protected]:/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 перед запуском патча сценарий:

• app/code/core/Mage/Core/Model/File/Validator/Image.php
• app/code/core/Mage/Sales/Model/Quote/Item.php

Является дополнением к https://magento.stackexchange.com/a/176930/46249

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

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

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

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