Dlaczego tak wiele funkcji PHP jest niedozwolonych w Magento ECG Coding Standard?

Standard kodowania EKG Magento wydaje się (przynajmniej w pewnym sensie) oficjalny jako standard dla rozszerzeń Magento 1:

https://github.com/magento-ecg/coding-standard

Ale nie rozumiem, dlaczego kryją się za tym wszystkie reguły, a reguły sniffera kodu same w sobie z wiadomościami niewiele pomagają. Czy istnieje szczegółowa dokumentacja dotycząca normy? Znam najlepsze praktyki i przewodnik dla programistów, ale nie mogę znaleźć niczego konkretnego na temat tych standardów kodowania.

Najbardziej niepokoi mnie ścisłość związana z nieużywaniem funkcji PHP.

Na przykład: Dlaczego każda funkcja PHP związana z systemem plików jest zabroniona ?

Chyba, ci mają zastosowania Varien_Io_File, Varien_File_Objectitd. Ale nawet podstawowe deweloperzy nie są świadomi wszystkich klas Varien i można często znaleźć takie rzeczy jak w Mage_ImportExport_Model_Import_Adapter_Csv:

    $this->_fileHandler = fopen($this->_source, 'r');

Tak więc rdzeń nie jest tak często najlepszym przykładem.

Inne wątpliwe zabronione funkcje IMHO:

• mb_parse_str
• parse_str
• parse_url

• base64_decode

  • tak, jest używany w backdoorach, ale banowanie evalpowinno wystarczyć i istnieją uzasadnione przypadki użycia, takie jak kodowanie danych binarnych. Poza tym json_decode(co nie jest zabronione) nie ma do tego dostępnego podstawowego pomocnika.

Źródło: https://github.com/magento-ecg/coding-standard/blob/master/Sniffs/Security/ForbiddenFunctionSniff.php

Zasadniczo moje pytanie sprowadza się do: Gdzie udokumentowano ten standard? I / lub czy istnieje lista „rzeczy do użycia zamiast tych rodzimych funkcji PHP”?

Otrzymałem nieoficjalną odpowiedź od zespołu EKG na to:

Po pierwsze, oflagowane funkcje niekoniecznie są niedozwolone - powinny uruchomić ręczną kontrolę użycia, aby zapewnić prawidłowe użycie. Jest to narzędzie pomocnicze do przeglądu, a nie narzędzie do oceniania dobrego / złego kodu.

Po drugie, założono, że lepiej jest używać opakowań Magento (funkcji / klas), jeśli istnieją, ponieważ mogą one oferować dodatkową funkcjonalność lub ochronę.

Po trzecie, tak jak w przypadku określonych wywołań, kod base64_decode jest często używany w przypadku złośliwego wstrzykiwanego kodu, a reszta, np. Parse_str, może być podatna na atak, szczególnie w przypadku obsługi danych nieznanych lub dostarczonych przez użytkownika - patrz na przykład http://php-security.org/2010/05/ 31 / mops-2010-049-php-parse_str-interruption-memory-korupcja-podatność /

Ponownie oznacza to, że kod nie jest odrzucany jako zły.

Mam nadzieję, że to pomoże.

Standard kodowania ma dwa cele.

1. znacznie ułatwia znajdowanie potencjalnie problematycznych części. Doświadczony programista już wie, które części nowego modułu musi przejrzeć, a ten standard zaznacza i wymienia je dla niego. Nie jest tak, że może usunąć te części, ale sprawdzić, czy są one konieczne, problematyczne lub oba.

2. wspierać niedoświadczonych programistów, których rzeczy powinien unikać. Chociaż wszystkie oznaczone funkcje mogą być dobrym rozwiązaniem dla określonych problemów, są bardzo łatwe w użyciu w problematyczny sposób. Skłania programistów do większego zastanowienia się nad problemem, a często do lepszych rozwiązań, które nie są sprzeczne ze standardem.

A czasem nawet najbardziej doświadczeni programiści ślepo przestrzegają standardu i tworzą najbardziej okrutne obejścia, aby nie urazić standardu wymuszonego przez społeczność.

trochę dodatkowych informacji

Funkcje plików często pozwalają na użycie opakowań protokołu, oznacza, że ​​ścieżka pliku rozpoczynająca się od http: // prowadzi do żądania HTTP, które jest często używane do „dzwonienia do domu” i od czasu do czasu zabija sklep, ponieważ serwer jest nieosiągalny (Domyślny limit czasu to 30 sekund) i jest wbudowany w bardzo centralne miejsce.

co prawda, nikt nie wierzy, ile jest jeszcze otworów do iniekcji. Świetnym przykładem było to, że Search na stronie MySQL miał taki.

gdzieś jest pomocnik rdzenia dla json_decode, ale ma on bardzo starą implementację, wystarczy użyć json_decode. Nie mam pojęcia, dlaczego należy to zabronić.

gettext jest interesującą częścią php, pamiętam, że używa natywnej implementacji systemu operacyjnego, która może mieć problemy, jeśli używasz go równolegle z różnymi językami (tak jak zwykle dzieje się, gdy masz więcej niż jeden język w swoim sklepie. Nigdy tak naprawdę nie sprawdzałem zbyt wiele , ale też nie powinno być takiej potrzeby w kontekście Magento.

Przechodząc dalej przez listę, wydaje się, że jest to tylko lista z jak największą liczbą funkcji. Historia jest naprawdę zabawna, wygląda na to, że usunęli niektóre funkcje z listy, po tym, jak zauważyli, wykorzystują ją. :RE