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

30

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

Fabian Schmengler
la source
1
Magento basé sur Zend Framework. Pourquoi n'utilisez-vous pas les normes Zend?
zhartaunik
ECG effectue plus de vérifications spécifiques à Magento, comme s'il y avait des modèles chargés dans des boucles. Il ne s'agit pas de vérifications de style de base comme l'indentation et les crochets.
Fabian Schmengler le
1
La liste des "requêtes SQL brutes" comme interdites semble également naïve. Bien sûr, vous ne faites pas de SQL brut dans la plupart des situations, mais il y a certainement des moments où cela n'est pas seulement approprié, mais nécessaire (c'est-à-dire des importations / exportations complexes)
pspahn
1
@pspahn Je vois votre point, mais le Zend_Dbgénérateur de requêtes ne devrait-il pas être capable de générer des requêtes SQL?
Fabian Schmengler le
Bien sûr, mais ne pouvez-vous pas également créer une selectinstruction en Zend_Dbutilisant du SQL brut en entrée? J'ai supposé que c'est ce que github.com/kalenjordan/custom-reports fait dans le backend.
pspahn

Réponses:

28

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.

Piotr Kaminski
la source
Alors pourquoi écrivent-ils "la fonction est interdite" au lieu de "vous devriez revoir le code pour garantir son utilisation légitime"?!
noir
11

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É

Flyingmana
la source