Tại sao nhiều hàm PHP không được phép trong Tiêu chuẩn mã hóa Magento ECG?

Tiêu chuẩn mã hóa Magento ECG dường như (ít nhất là loại) chính thức là tiêu chuẩn cho các tiện ích mở rộng Magento 1:

https://github.com/magento-ecg/coding-st Chuẩn

Nhưng tôi không hiểu lý do đằng sau tất cả các quy tắc và quy tắc sniffer với các thông điệp của họ không giúp được gì nhiều. Có bất kỳ tài liệu chi tiết về tiêu chuẩn? Tôi biết các thực tiễn tốt nhất phổ biến và hướng dẫn của nhà phát triển nhưng không thể tìm thấy bất cứ điều gì cụ thể về các tiêu chuẩn mã hóa này.

Điều làm tôi lo lắng nhất là sự nghiêm ngặt về việc không sử dụng các hàm PHP.

Ví dụ: Tại sao mọi chức năng PHP liên quan đến hệ thống tệp bị cấm ?

Tôi đoán, bạn phải sử dụng Varien_Io_File, Varien_File_Objectv.v. nhưng ngay cả các nhà phát triển cốt lõi cũng không biết về tất cả các lớp Varien và bạn thường tìm thấy những thứ như trong Mage_ImportExport_Model_Import_Adapter_Csv:

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

Vì vậy, cốt lõi không phải là ví dụ tốt nhất, như thường lệ.

Các chức năng cấm nghi ngờ khác của IMHO:

• mb_parse_str
• parse_str
• parse_url

• base64_decode

  • vâng, nó được sử dụng trong các cửa hậu nhưng việc cấm evallà đủ và có những trường hợp sử dụng hợp pháp, như mã hóa dữ liệu nhị phân. Và ngoài json_decode(không bị cấm), không có người trợ giúp cốt lõi nào sẵn sàng cho việc này.

Nguồn: https://github.com/magento-ecg/coding-stiteria/blob/master/Sniffs/Security/ForbiddenFunctionSniff.php

Về cơ bản, câu hỏi của tôi tập trung vào: Tiêu chuẩn này được ghi nhận ở đâu? Và / hoặc có một danh sách "những thứ cần sử dụng thay cho các hàm PHP gốc" này không?

Nhận được câu trả lời không chính thức từ nhóm ECG về điều đó:

Trước hết, các chức năng được gắn cờ không nhất thiết không được phép - chúng nên kích hoạt đánh giá thủ công về việc sử dụng để đảm bảo sử dụng hợp pháp. Đây là một công cụ trợ giúp đánh giá, không phải là công cụ chấm điểm mã tốt / xấu.

Thứ hai, giả định là tốt hơn là sử dụng các hàm bao Magento (hàm / lớp) nếu chúng tồn tại vì chúng có thể cung cấp chức năng hoặc bảo vệ bổ sung.

Thứ ba, như đối với các cuộc gọi cụ thể, base64_decode thường được sử dụng cho mã được tiêm mã độc và phần còn lại như parse_str có thể dễ bị tổn thương, đặc biệt là xử lý đầu vào không xác định hoặc do người dùng cung cấp - xem ví dụ http://php-security.org/2010/05/ 31 / mops-2010-049-php-parse_str-gián đoạn-bộ nhớ-tham nhũng-lỗ hổng /

Một lần nữa, đây là đánh dấu nó để xem xét không từ chối mã là xấu.

Hy vọng nó giúp.

Tiêu chuẩn mã hóa có hai mục tiêu.

1. làm cho việc tìm kiếm các phần có thể có vấn đề dễ dàng hơn nhiều. Một nhà phát triển có kinh nghiệm đã biết những phần nào của mô-đun mới mà anh ta cần xem xét, và tiêu chuẩn này đánh dấu và liệt kê chúng cho anh ta. Nó không phải là để anh ta có thể loại bỏ các phần này, nhưng để xem xét nếu chúng là cần thiết, có vấn đề hoặc cả hai.

2. hỗ trợ các nhà phát triển thiếu kinh nghiệm về những điều anh ta nên tránh. Mặc dù tất cả các chức năng được đánh dấu có thể là giải pháp tốt cho các vấn đề cụ thể, chúng rất dễ sử dụng theo cách có vấn đề. Nó khiến các nhà phát triển suy nghĩ nhiều hơn về vấn đề và thường đưa ra các giải pháp tốt hơn không mâu thuẫn với tiêu chuẩn.

Và đôi khi, ngay cả những nhà phát triển giàu kinh nghiệm nhất cũng mù quáng tuân theo tiêu chuẩn và tạo ra những cách giải quyết tàn khốc nhất, chỉ để không xúc phạm một tiêu chuẩn bắt buộc của cộng đồng.

thêm một chút thông tin

Các chức năng tệp thường cho phép sử dụng trình bao bọc protocoll, có nghĩa là đường dẫn tệp bắt đầu bằng http: // dẫn đến một reaquest http, thường được sử dụng để "gọi về nhà" và đôi khi giết chết một cửa hàng, vì máy chủ không thể truy cập được (Thời gian chờ mặc định 30 giây) và được tích hợp vào một vị trí rất trung tâm.

allithing sql realted, noone tin rằng có bao nhiêu lỗ tiêm sql vẫn tồn tại ngoài đó. Một ví dụ tuyệt vời là, khi Tìm kiếm trên trang web Mysql có một.

có một trình trợ giúp cốt lõi cho json_decode ở đâu đó, nhưng nó có một triển khai rất cũ, chỉ cần sử dụng json_decode. Không có ý tưởng tại sao nó nên bị cấm.

gettext là một phần php thú vị, tôi nhớ nó sử dụng một số triển khai hệ điều hành gốc có thể có vấn đề, nếu bạn sử dụng song song với các ngôn ngữ khác nhau (như nó thường xảy ra khi bạn có nhiều ngôn ngữ trong cửa hàng của mình. , nhưng cũng không cần nó trong Bối cảnh Magento.

Đi xa hơn danh sách, đó dường như chỉ là một danh sách với càng nhiều chức năng càng tốt. Lịch sử thực sự buồn cười, dường như họ đã loại bỏ một số chức năng khỏi danh sách, sau khi họ nhận thấy, họ sử dụng nó. : D