J'ai utilisé le module Configparavacement pour écrire des fichiers de configuration pendant un certain temps. Cependant, une pensée m'a récemment frappé; Pourquoi ne pas simplement utiliser python pur à la place? Prenez cet exemple Fichier de configuration: Pour lire ces valeurs dans mon code, je fais d'autre part, si j'avais un fichier de config, comme celui-ci: dans mon code principal, je pourrais faire ceci: alors que dois-je Gain de l'utilisation du module ConfigparaSer? Quels sont les avantages et les inconvénients de chaque approche?
3 Réponses :
Un potentiel "CON" de l'approche de fichier Python est que votre utilisateur peut mettre du code arbitraire dans le fichier qui sera exécuté dans le contexte de votre application. Comme S. Lott souligne dans les commentaires à cette réponse (lorsque j'étais un peu plus énergique dans mon avertissement), ce n'est généralement pas un problème car l'utilisateur (ou un pirate informatique) aura généralement accès à votre code source entier et peut faire des changements souhaités.
Cependant, je peux certainement imaginer des situations dans lesquelles l'approche pourrait entraîner un nouveau trou de sécurité, telle que lorsque les fichiers de script principaux sont inscriptions uniquement par l'administrateur système et le fichier de configuration par utilisateur est le seul fichier modifiable par le fichier. utilisateur final. À moins que vous soyez certain que votre code ne fonctionnera jamais dans un tel environnement, je ne recommanderais pas l'approche du module Python. Il y a de bonnes raisons que "ne pas exécuter de code donné par les utilisateurs" est largement considérée comme une meilleure pratique.
Exécution du fichier de configuration permet également de manipuler des erreurs problématiques. Si l'utilisateur introduit une erreur de syntaxe, vous voudrez le piéger et vous pouvez le faire facilement en lançant un Si, malgré tout cela, vous souhaitez toujours utiliser la syntaxe Python dans votre fichier de configuration, vous pouvez utiliser le module essayer autour de votre importer , mais rien après l'erreur sera réalisé. Dans un fichier de configuration, l'analyse habituellement continuera avec la ligne suivante, l'utilisateur manquera donc au plus un paramètre au lieu de (dire) la moitié d'entre eux. Il existe des moyens de faire fonctionner un module Python plus comme un fichier de configuration (vous pouvez lire le fichier sous forme de texte et exécuté () chaque ligne, par exemple), mais si vous devez faire n'importe quel travail du tout, Il devient plus facile d'utiliser configparyser .
ast (voir fonction littéral_eval () ). < / p>
-1: "Votre utilisateur peut mettre un code arbitraire dans le fichier qui sera exécuté dans le contexte de votre application". Une considération stupide. L'utilisateur dispose de tout le code Python disponible. Ils peuvent pirater n'importe quel code Python qu'ils veulent pirater. Le fichier de configuration n'est pas une cible utile lorsque vous enregistrez les mots de passe en cours d'édition de Hashlib est tellement plus simple.
Je supposais plutôt que si vous alliez distribuer une application Python, vous l'enveloppez à l'aide de PY2EXE ou d'un outil similaire, rendant les fichiers source d'origine un peu moins accessibles. Cependant, votre point est pris.
@Kindall: "L'utilisateur manquera au plus un paramètre" Comment va-t-il bien? Cela pourrait être fatalement mauvais, en effet, cela pourrait entraîner des violations de sécurité horribles ou pire. Je préférerais ne rien faire fonctionner si la configuration est erronée que d'avoir une configuration partielle faire quelque chose d'horrible. Je ne peux pas croire que vous tinérez cela comme un "avantage". La configuration partielle est un problème très grave.
Dépend de la situation. Je préférerais peut-être obtenir autant que je peux et essayer de fournir des valeurs défauts sûres pour des valeurs manquantes en fonction de ce que je pouvais lire ou donner des messages spécifiques sur ce qui manque quand je ne peux pas faire cela. Je peux voir façons de le faire avec l'approche du module, mais cela semble être plus utile de ce type et implique une certaine réinvention des roues.
@Kindall: "Sûr défaut" n'est jamais une réponse appropriée à une erreur de syntaxe. L'erreur de syntaxe peut être dans le paramètre le plus important, celui qui remplace les paramètres d'aucune sécurité à la sécurité réelle. Manquant qu'un paramètre - en raison d'une erreur de syntaxe - est impensable. Bad Syntaxe dans les paramètres désigne que l'application ne peut pas (et ne devrait pas) commencer à fonctionner dans un mode compromis à l'aide des défauts "Safe". Il devrait refuser de courir - c'est-à-dire crash. C'est la seule réponse judicieuse et les fichiers .ini ne sont pas meilleurs (ni pires) que d'autres formats.
Je vois la tradition Microsoft de crash lorsqu'un réglage trivial ne peut pas être lu est vivant et bien. ;-) Tous les paramètres ne sont pas tout aussi importants et que le programmeur peut utiliser son intelligence et son jugement en décidant quoi faire si on ne peut pas être lu. Je conviens que le format réel n'est pas important; Le fait qu'il existe une bibliothèque standard bien conçue, riche en fonctionnalités, testée et documentée pour un format particulier pour .ini est bien, cependant. Je suppose que vous pouvez utiliser XML, mais CONFIGPARY a des fonctionnalités agréables spécifiquement pour le boîtier d'utilisation de fichier de configuration et est probablement plus léger que DOM.
CONFIGAYSER analyse une configuration simple et plate D'accord, plus détaillé: le code peut faire toutes sortes de choses, y compris la rupture plus facilement - surtout lors de la modification des non-programmeurs (essayez d'expliquer .ini moddeurs qu'ils doivent utiliser des citations correspondantes et Échappez des choses ...) - ou provoquer des conflits d'espace de noms avec d'autres parties de votre application (surtout si vous Import * ). Voir également le règle du moins d'énergie .
@delnan Bonne explication, mais la dernière partie de votre réponse sonne comme si vous vous ridiculisez le SO pour ne pas connaître la réponse (bien que je doute que c'est ce que vous vouliez dire). Je voterai pour votre réponse avec une petite édition à son ton.
@delnan +1. Mon commentaire posté après votre modification mais a fait référence à la réponse avant la modification.
@Steven: Le ton a toujours besoin de l'OMI polonais.
-1: "Affaire fermée." Loin de vrai. Le code d'exécution de la configuration simplifie beaucoup de choses. Le Sociopath maléfique qui pourrait "exploiter" votre configuration a un accès complet à tout votre code Python. Pourquoi arrêter de faire forcer la configuration? Pourquoi pas seulement adultérate Tout le code?
@ S.Lott: reviens? Oui, si le code malicieux devient modifier le fichier de configuration, il pourrait aussi bien modifier le code réel. Mais je n'ai pas prétendu que la proposition de l'OP est une vulnérabilité de sécurité (discuter avec @kindall). Mon raisonnement est différent.
@delnan: Essayez d'expliquer .ini les modders qu'ils doivent correspondre aux [] "sur les paragraphes [nom]. La syntaxe est la syntaxe. Une configuration Python qui utilise un sous-ensemble sensible de Python est aussi simple qu'un fichier de configuration. Pas plus simple. Et pas plus complexe, non plus. Il y a une complexité potentielle, mais vous n'apprenez pas à des modders .ini tous de Python pour modifier une seule valeur de chaîne.
@ S.Lott: .ini (-ike) Syntaxe est très répandu et la plupart des utilisateurs qui osent éditer un fichier de configuration le savent de manière proprablement (sans oublier qu'ils doivent rarement à toucher les en-têtes de section). Mais OTOH, quelques-uns d'entre eux seraient trébuchés par des choses comme la nécessité de citer les choses. Et ceux qui savent peuvent encore se plaindre - "Pourquoi exiger des citations de Friggin 'si .ini s'entend sans?" - "Parce que la grammaire de Python le dit." - " super raison ..."
@delnan: Pourquoi avoir besoin de friggin [] est en premier lieu lorsque Python n'en a-t-il pas besoin? Je ne comprends pas ton point. Ini Syntaxe n'est pas magiquement plus simple. Pourquoi continuer à prétendre que c'est plus simple?
@ S.Lott: Un parseur ini est beaucoup plus simple (comme dans, plus petit) en tant qu'alser Python, tout simplement parce que le premier n'est qu'un format de données très simple pendant que ce dernier est un langage de programmation complet. Mais ce n'est pas le point, et je ne discute pas que la syntaxe est "plus simple". Je suppose juste que des personnes qui pourraient éditer le fichier de configuration, beaucoup connaîtront INI Syntaxe tandis que peu connaîtront la syntaxe Python - corrigez-moi si vous avez la preuve que ce n'est pas le cas - et que cela spécifie donc les données du format INI Soyez plus facile pour les utilisateurs .
@Delnan: Je ne comparais pas tous les python à INI. Juste l'attribution d'entiers et de cordes. Qui semble aussi simple que les fichiers ini. Je prétends que la syntaxe .ini est également obscure. Avez-vous des preuves? Je n'ai aucune raison de croire que les gens connaissent comme par magie .ini tout meilleur que les déclarations d'affectation de Python. Je pense que la syntaxe est plus ou moins égale à des problèmes. C'est pourquoi le cas n'est pas "fermé".
@ S.Lott: Je ne discute pas que la syntaxe X est de quelque manière que ce soit techniquement supérieure / inférieur. Cela ne me dérange pas de ne pas être d'accord avec moi, mais s'il vous plaît au moins répondre à ce que j'écris réellement. Et je viens d'écrire que les utilisateurs (qui éditeront ces fichiers) seront proprement davantage familiarisés avec la syntaxe de type INI. <--- Ceci. Raison contre cette hypothèse, ou cette discussion est inutile.
@delnan: "Les utilisateurs (qui éduqueront ces fichiers) seront proprement davantage familiarisés avec la syntaxe de type ini". Faux. Les utilisateurs qui modifient ces fichiers sont confrontés à une variété de syntaxe. Notation étrange de Apache. Fichiers de configuration Java. Python et Ini sont également le déroutant. L'affaire n'est pas "fermée". Ceci est mon point. L'affaire n'est pas "fermée". Pas fermé". Ouvert à une certaine possibilité qu'il y ait une chance que .ini n'est pas magiquement meilleur mais aussi mauvais que tous les autres.
Alors, qu'est-ce que je gagne à partir de l'utilisation du module Configparaer?
Compatibilité avec les fichiers Windows .ini. Rend certaines personnes heureuses.
Quels sont les avantages et les inconvénients de chaque approche?
CONFIGARY a une syntaxe limitée et certaines choses relativement simples sont très artificielles. Regardez
enregistrement pour des exemples.La syntaxe Python est plus simple et beaucoup plus facile à utiliser. Il n'y a pas de trou de sécurité, car personne ne perdra de temps à pirater un fichier de configuration lorsqu'il peut simplement pirater votre code source. En effet, ils peuvent pirater la plupart de la bibliothèque de Python intégrée. Pour cette affaire, ils pourraient cuisiner l'interpréteur de Python lui-même.
Personne ne gaspille du temps piratage de fichiers de configuration lorsqu'il y a beaucoup, des exploits beaucoup plus faciles ailleurs dans votre code source d'application.