Dlaczego PATCH_SUPEE-6788 wydaje się nie mieć wpływu na instalację 1.7.0.2?

Uwaga: Wydaje się, że ten problem dotyczy wszystkich wersji Magento, które otrzymały łatkę SUPEE-6788. Zobaczysz w mojej odpowiedzi , że zarówno .htaccess i .htaccess.samplemuszą być przywrócone do poprawki, aby odnieść sukces.

Pracuję nad zastosowaniem poprawki SUPEE-6788 do witryny CE 1.7.0.2 przy użyciu skryptu powłoki dostarczonego przez magentocommerce.com/downloads . Na stronie zastosowano wszystkie poprzednie poprawki bezpieczeństwa.

Skrypt nazywa się PATCH_SUPEE-6788_CE_1.7.0.2_v1-2015-10-27-12-00-16.shi ma sumę md5 cfc0cf533fe36a5f573414f0feeb1590(ta łatka była niezwykła, ponieważ została wydana bez kompresji - chociaż plik nie wydaje się uszkodzony lub obcięty).

Po uruchomieniu tego skryptu wydaje się, że dane wyjściowe konsoli wskazują, że co najmniej jedna z dołączonych łat uległa awarii lub została pominięta, ale że wiele części łatki zakończyło się pomyślnie, jednak gitnie wykazuje żadnych zmian. Skrypt został przetestowany w dwóch różnych środowiskach z tą samą bazą kodową - jedna na stacji roboczej Ubuntu GNOME 14.04 LTS, druga na wspólnym serwerze nexcess.com (z systemem CentOS).

Interesujące jest to, że wydajność obu środowisk jest nieco inna. Zwróć uwagę na linie zaczynające się od „sprawdzania” vs „łatania”.

Przykład danych wyjściowych ze środowiska Ubuntu:

bash PATCH_SUPEE-6788_CE_1.7.0.2_v1-2015-10-27-12-00-16.sh                                              [19:27:10]
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

checking file .htaccess
Hunk #1 FAILED at 207.
1 out of 1 hunk FAILED
can't find file to patch at input line 38
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git .htaccess.sample .htaccess.sample
|index 546f18e..3e79c77 100644
|--- .htaccess.sample
|+++ .htaccess.sample
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
checking file app/code/core/Mage/Admin/Model/Block.php
checking file app/code/core/Mage/Admin/Model/Resource/Block.php
checking file app/code/core/Mage/Admin/Model/Resource/Block/Collection.php
checking file app/code/core/Mage/Admin/Model/Resource/Variable.php
checking file app/code/core/Mage/Admin/Model/Resource/Variable/Collection.php
checking file app/code/core/Mage/Admin/Model/Variable.php
...

Przykład ze środowiska CentOS:

bash PATCH_SUPEE-6788_CE_1.7.0.2_v1-2015-10-27-12-00-16.sh 
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file .htaccess
Hunk #1 FAILED at 207.
1 out of 1 hunk FAILED -- saving rejects to file .htaccess.rej
can't find file to patch at input line 38
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git .htaccess.sample .htaccess.sample
|index 546f18e..3e79c77 100644
|--- .htaccess.sample
|+++ .htaccess.sample
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
patching file app/code/core/Mage/Admin/Model/Block.php
patching file app/code/core/Mage/Admin/Model/Resource/Block.php
patching file app/code/core/Mage/Admin/Model/Resource/Block/Collection.php
patching file app/code/core/Mage/Admin/Model/Resource/Variable.php
...

Będę zagłębiał się w błąd na górze wyjścia i możliwe ręczne nakładanie łatek - ale miałem nadzieję, że ktoś może mieć wgląd w przyczynę lub względnie prostą naprawę.

Wygląda .htaccessna .htaccess.sampleto, że winowajcami są zmiany zarówno mojego, jak i zaginionego . Po przywróceniu kopii zapasowej obu plików (oba były wymagane) poprawka wydaje się działać.

Aby rozwiązać ten problem, nie tracąc (potrzebnych) modyfikacji, wykonałem następujące kroki:

1. Tworzenie kopii zapasowej .htaccessi .htaccess.sample-either z systemu kontroli wersji lub kopiując pliki

2. Skopiowałem standardową wersję 1.7.0.2 .htaccessi .htaccess.sampledo mojej bazy kodu, zastępując mój dostosowany.htaccess

3. Zastosowałem łatkę. Wyjście było znacznie krótsze niż wcześniej (2 linie).

4. Zatwierdzone wszystkie zmiany, w tym .htaccess(dla potomności)

5. Sprawdziłem poprzednią wersję .htaccessbez łatki i ręcznie zastosowałem łatkę do tego pliku.

Oto git diffpoprawka pokazująca dodane linie:

diff --git a/.htaccess b/.htaccess
index 60e1795..aca7f55 100644
--- a/.htaccess
+++ b/.htaccess
@@ -207,3 +207,28 @@
 ## http://developer.yahoo.com/performance/rules.html#etags

     #FileETag none
+
+###########################################
+## Deny access to cron.php
+    <Files cron.php>
+
+############################################
+## uncomment next lines to enable cron access with base HTTP authorization
+## http://httpd.apache.org/docs/2.2/howto/auth.html
+##
+## Warning: .htpasswd file should be placed somewhere not accessible from the web.
+## This is so that folks cannot download the password file.
+## For example, if your documents are served out of /usr/local/apache/htdocs
+## you might want to put the password file(s) in /usr/local/apache/.
+
+        #AuthName "Cron auth"
+        #AuthUserFile ../.htpasswd
+        #AuthType basic
+        #Require valid-user
+
+############################################
+
+        Order allow,deny
+        Deny from all
+
+    </Files>

Próbowałem pobrać wersje standardowe .htaccessi .htaccess.samplełatka nadal nie będzie działać, nawet po użyciu wersji podstawowych.

Dla każdego, kto ma ten problem, zapoznaj się z tym artykułem, w którym wyjaśniono, jak usunąć części .htaccessi htaccess.samplez samej poprawki, a następnie ręcznie dodać je po: http://www.atwix.com/magento/security-patch-supee-6788 -Problemy z instalacją/

POPRAWKA - edytuj plik łatki usuwając linie 163-195 zaczynające się od linii

diff --git .htaccess .htaccess 

i kończy się na

+    </Files>

Konieczne może być również usunięcie części związanej z htaccess.sampletym

diff --git .htaccess.sample .htaccess.sample

i kończy się na

+    </Files>

Po wykonaniu tej czynności spróbuj ponownie zastosować łatkę i tym razem powinna ona zostać z powodzeniem zastosowana.

Następnie musimy dodać następujące elementy na końcu naszego .htaccessi .htaccess.sampleplików, aby były aktualne zgodnie z łatką

###########################################
## Deny access to cron.php
    <Files cron.php>

############################################
## uncomment next lines to enable cron access with base HTTP authorization
## http://httpd.apache.org/docs/2.2/howto/auth.html
##
## Warning: .htpasswd file should be placed somewhere not accessible from the web.
## This is so that folks cannot download the password file.
## For example, if your documents are served out of /usr/local/apache/htdocs
## you might want to put the password file(s) in /usr/local/apache/.

        #AuthName "Cron auth"
        #AuthUserFile ../.htpasswd
        #AuthType basic
        #Require valid-user

############################################

        Order allow,deny
        Deny from all

    </Files>

Po wykonaniu tych kroków udało mi się pomyślnie zainstalować łatkę, mam nadzieję, że to pomoże!

To może ci pomóc, nawet jeśli jest to inna wersja - https://community.magento.com/t5/Security-Patches/1-9-1-0-applying-patch-6788-hunk-failed/td-p/ 20070

Miałem ten sam problem, ponieważ pobrałem niewłaściwą łatkę. Korzystam z Magento EE 1.13 i pobrałem łatkę CE ... Pobrałem łatkę dla CE 1.8, postępując zgodnie z samouczkiem, myśląc, że będzie działać dla EE 1.13. Upewnij się, że pobierasz łatkę do swojej wersji Magento.

1. Utwórz kopię zapasową plików .htaccess i .htaccess.sample
2. Prześlij oryginalne pliki .htaccess i .htaccess.sample zgodnie z wersją Magento.
3. Wykonaj łatkę.