Pourquoi tant de fonctions PHP sont-elles interdites dans la norme de codage Magento ECG?

La norme de codage ECG Magento semble être (au moins une sorte) officielle en tant que norme pour les extensions Magento 1:

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

Mais je ne comprends pas le raisonnement derrière toutes les règles, et les règles de renifleur de code avec leurs seuls messages n'aident pas beaucoup. Existe-t-il une documentation détaillée sur la norme? Je connais les meilleures pratiques courantes et le guide du développeur, mais je ne trouve rien de spécifique sur ces normes de codage.

Ce qui me dérange le plus, c'est la rigueur de ne pas utiliser les fonctions PHP.

Par exemple: Pourquoi chaque fonction PHP liée au système de fichiers est-elle interdite ?

Je suppose que vous êtes censé utiliser Varien_Io_File, Varien_File_Objectetc. mais même les développeurs principaux ne connaissent pas toutes les classes Varien et vous trouvez souvent des choses comme dans Mage_ImportExport_Model_Import_Adapter_Csv:

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

Ainsi, le noyau n'est pas le meilleur exemple, comme souvent.

Autres fonctions interdites contestables à mon humble avis:

• mb_parse_str
• parse_str
• parse_url

• base64_decode

  • oui, il est utilisé dans les portes dérobées mais l'interdiction evaldevrait être suffisante et il existe des cas d'utilisation légitimes, comme le codage de données binaires. Et à part json_decode(ce qui n'est pas interdit), aucun assistant de base n'est disponible pour cela.

Source: https://github.com/magento-ecg/coding-standard/blob/master/Sniffs/Security/ForbiddenFunctionSniff.php

Essentiellement, ma question se résume à: Où cette norme est-elle documentée? Et / ou existe-t-il une liste de "choses à utiliser à la place de ces fonctions PHP natives"?

J'ai obtenu une réponse non officielle de l'équipe ECG à ce sujet:

Tout d'abord, les fonctions signalées ne sont pas nécessairement interdites - elles devraient déclencher une révision manuelle de l'utilisation pour garantir une utilisation légitime. C'est un outil d'aide à la révision, pas un bon / mauvais outil de notation de code.

Deuxièmement, l'hypothèse était qu'il était préférable d'utiliser les wrappers Magento (fonctions / classes) s'ils existent car ils pourraient offrir des fonctionnalités ou une protection supplémentaires.

Troisièmement, comme pour des appels spécifiques, base64_decode est souvent utilisé pour le code injecté malveillant, et les autres comme parse_str peuvent être vulnérables, en particulier la gestion des entrées inconnues ou fournies par l'utilisateur - voir par exemple http://php-security.org/2010/05/ 31 / mops-2010-049-php-parse_str-interruption-memory-corruption-vulnérabilité /

Encore une fois, cela le signale pour examen, sans rejeter le code comme mauvais.

J'espère que ça aide.

La norme de codification a deux objectifs.

1. faciliter la recherche de pièces potentiellement problématiques. Un développeur expérimenté sait déjà quelles parties d'un nouveau module il doit examiner, et cette norme les marque et les répertorie pour lui. Ce n'est pas pour qu'il puisse retirer ces pièces, mais pour vérifier si elles sont nécessaires, problématiques ou les deux.

2. soutenir les développeurs inexpérimentés sur les choses qu'il devrait éviter. Bien que toutes les fonctions marquées puissent être de bonnes solutions pour des problèmes spécifiques, elles sont très faciles à utiliser de manière problématique. Cela conduit les développeurs à réfléchir davantage au problème, et souvent à de meilleures solutions qui n'entrent pas en conflit avec la norme.

Et parfois, même les développeurs les plus expérimentés suivent aveuglément la norme et créent les solutions de contournement les plus cruelles, juste pour ne pas offenser une norme forcée de la communauté.

un peu d'informations supplémentaires

Les fonctions de fichier permettent souvent l'utilisation de wrappers de protocole, ce qui signifie qu'un chemin de fichier commençant par http: // conduit à une nouvelle demande http, qui est souvent utilisé pour "appeler à la maison", et tue de temps en temps un magasin, car le serveur n'est pas accessible (Délai d'attente par défaut de 30 secondes) et son intégré dans un endroit très central.

chaque sql realt, personne ne croit combien de trous d'injection sql existent encore là-bas. Un bon exemple était, comme la recherche sur le site Web Mysql en avait un.

il y a un assistant de base pour json_decode quelque part, mais il a une implémentation très ancienne, utilisez simplement json_decode. Aucune idée pourquoi cela devrait être interdit.

gettext est une partie php intéressante, je me souviens qu'il utilise une implémentation native du système d'exploitation qui pourrait avoir des problèmes, si vous l'utilisez en parallèle avec différentes langues (comme cela arrive généralement lorsque vous avez plus d'une langue dans votre boutique. Jamais vraiment enquêté autant , mais cela ne devrait pas non plus être nécessaire dans le contexte Magento.

En allant plus loin dans la liste, cela semble être juste une liste avec autant de fonctions que possible. L'histoire est en fait drôle, semble avoir supprimé certaines des fonctions de la liste, après l'avoir remarqué, ils s'en servent. :RÉ