Magento ইসিজি কোডিং স্ট্যান্ডার্ডে কেন এতগুলি পিএইচপি ফাংশন অনুমোদিত নয়?

Question

ম্যাজেন্টো ইসিজি কোডিং স্ট্যান্ডার্ডটি (কমপক্ষে কোনও ধরণের) ম্যাজেন্টো 1 এক্সটেনশনের মান হিসাবে অফিসিয়াল বলে মনে হচ্ছে:

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

তবে আমি সমস্ত নিয়মের পিছনে যুক্তি বুঝতে পারি না, এবং তাদের বার্তাগুলির সাথে কোড স্নিফার বিধিগুলি খুব বেশি সহায়ক হয় না। মান সম্পর্কে কোনও বিশদ নথি আছে কি? আমি সাধারণ সেরা অনুশীলন এবং বিকাশকারীদের গাইড জানি তবে এই কোডিং মানগুলির বিষয়ে সুনির্দিষ্ট কিছু খুঁজে পাচ্ছি না।

আমাকে সবচেয়ে বেশি কষ্ট দেয় পিএইচপি ফাংশন ব্যবহার না করার বিষয়ে কঠোরতা।

উদাহরণস্বরূপ: প্রতিটি একক ফাইল সিস্টেম সম্পর্কিত পিএইচপি ফাংশন নিষিদ্ধ কেন?

আমি, আপনি ব্যবহার অনুমিত হয় Varien_Io_File, Varien_File_Objectইত্যাদি কিন্তু কোর ডেভেলপারদের সব Varien ক্লাস সচেতন নয় এবং আপনি প্রায়ই মত জিনিষ খুঁজে পেতে Mage_ImportExport_Model_Import_Adapter_Csv:

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

সুতরাং, কোরটি সর্বোত্তম উদাহরণ নয়, প্রায়শই।

অন্যান্য আইএমএইচও প্রশ্নবিদ্ধ নিষিদ্ধ ফাংশন:

• mb_parse_str
• parse_str
• parse_url

• base64_decode

  • হ্যাঁ, এটি পিছনের ঘরে ব্যবহৃত হয় তবে নিষেধাজ্ঞাই evalযথেষ্ট হওয়া উচিত এবং বাইনারি ডেটা এনকোডিং করার মতো বৈধ ব্যবহারের মামলাও থাকতে পারে। এবং অন্যটি json_decode(যা নিষিদ্ধ নয়) এর জন্য কোনও মূল সহায়ক নেই।

সূত্র: https://github.com/magento-ecg/coding-standard/blob/master/Sniffs/Security/ ForbmittedFunctionSniff.php

মূলত, আমার প্রশ্নটি এখানে ফোটে: এই স্ট্যান্ডার্ড নথিটি কোথায়? এবং / অথবা "এই দেশীয় পিএইচপি ফাংশনগুলির পরিবর্তে ব্যবহার করার মতো জিনিসগুলির" তালিকা রয়েছে?

Comments

জেন্ডো ফ্রেমওয়ার্কে নির্মিত ম্যাজেন্টো। আপনি কেন জেন্ডার মান ব্যবহার করবেন না?

— জার্তৌনিক

ইসিজি আরও বেশি ম্যাজেন্টো সুনির্দিষ্ট চেক করে, যেমন লুপগুলিতে বোঝা মডেল থাকলে। এটি ইনডেন্টেশন এবং বন্ধনীগুলির মতো বেসিক স্টাইলের চেকগুলি সম্পর্কে নয়।

— ফ্যাবিয়ান শেমংলার

"কাঁচা এসকিউএল কোয়েরিগুলি" নিষিদ্ধ হিসাবে তালিকাবদ্ধ করাও নিষ্পাপ বলে মনে হয়। অবশ্যই আপনি বেশিরভাগ পরিস্থিতিতে কাঁচা এসকিউএল করেন না, তবে অবশ্যই এমন সময় রয়েছে যখন এটি কেবল

— উপযুক্তই

@ স্প্যাসন আমি আপনার পয়েন্টটি দেখতে পাচ্ছি, তবে Zend_Dbকোয়েরি নির্মাতাকে কোনও এসকিউএল অনুসন্ধান উত্পন্ন করতে সক্ষম হওয়া উচিত নয় ?

— ফ্যাবিয়ান শেমংলার

অবশ্যই, তবে আপনি কী কাঁচা এসকিউএলকে ইনপুট হিসাবে ব্যবহারের selectমাধ্যমে একটি বিবৃতি তৈরি করতে পারবেন না Zend_Db? আমি ধরে নিয়েছি github.com/kalenjordan/custom-report যা ব্যাকএন্ডে করে।

— pspahn

Answer 1

এতে ইসি দলের পক্ষ থেকে একটি অনানুষ্ঠানিক উত্তর পেয়েছেন:

প্রথমত, পতাকাযুক্ত ফাংশনগুলি অগত্যা অনুমোদিত নয় - বৈধ ব্যবহার নিশ্চিত করার জন্য তাদের ব্যবহারের উপর একটি ম্যানুয়াল পর্যালোচনা ট্রিগার করা উচিত। এটি একটি পর্যালোচনা সহায়ক সরঞ্জাম, ভাল / খারাপ কোড স্কোরিং সরঞ্জাম নয়।

দ্বিতীয়ত, ধারনাটি ছিল যে তারা যদি অতিরিক্ত কার্যকারিতা বা সুরক্ষা সরবরাহ করতে পারে তবে তারা যদি উপস্থিত থাকে তবে ম্যাগন্টো র‌্যাপারগুলি (ফাংশন / ক্লাস) ব্যবহার করা ভাল।

তৃতীয়ত, নির্দিষ্ট কল হিসাবে, বেস 64_ ডিকোড প্রায়শই দূষিত ইনজেকশনের কোডের জন্য ব্যবহৃত হয়, এবং বাকী পার্স_স্ট্রের মতো ঝুঁকিপূর্ণ হতে পারে, বিশেষত অজানা বা ব্যবহারকারী প্রদত্ত ইনপুট পরিচালনা করে - উদাহরণস্বরূপ দেখুন http://php-security.org/2010/05/ 31 / mops-2010-049-পিএইচপি-parse_str-বিঘ্ন-মেমরি দুর্নীতি দুর্বলতার /

আবার কোডটি খারাপ হিসাবে প্রত্যাখ্যান না করে পর্যালোচনা করার জন্য এটি এটি পতাকাঙ্কিত করছে।

আশা করি এটা সাহায্য করবে.

Comments

তাহলে তারা "ফাংশন নিষিদ্ধ" এর পরিবর্তে "কেন কোডটির বৈধ ব্যবহার নিশ্চিত করার জন্য আপনার কোডটি পর্যালোচনা করা উচিত" এর পরিবর্তে লিখছেন ?!

— কালো

Answer 2

কোডিং স্ট্যান্ডার্ডের দুটি লক্ষ্য রয়েছে।

1. সম্ভবত সমস্যাযুক্ত অংশগুলি সন্ধান করা অনেক সহজ করে তুলুন। একজন অভিজ্ঞ বিকাশকারী ইতিমধ্যে জানে যে নতুন মডিউলের কোন অংশটি তার পর্যালোচনা করা উচিত এবং এই মানটি চিহ্নিত করে এবং সেগুলি তার জন্য তালিকাভুক্ত করে। তিনি এই অংশগুলি সরাতে পারেন তাই নয়, তবে সেগুলি প্রয়োজনীয়, সমস্যাযুক্ত বা উভয় ক্ষেত্রে পর্যালোচনা করার জন্য।

2. অনভিজ্ঞ বিকাশকারীদের সমর্থন করুন যার উপর সে এড়ানো উচিত। সমস্ত চিহ্নিত ফাংশনগুলি নির্দিষ্ট সমস্যার জন্য ভাল সমাধান হতে পারে তবে সমস্যাযুক্ত উপায়ে এগুলি ব্যবহার করা খুব সহজ। এটি বিকাশকারীদের সমস্যাটি সম্পর্কে আরও চিন্তাভাবনা করতে, এবং প্রায়শই একটি ভাল সমাধানের দিকে নিয়ে যায় যা মানদণ্ডের সাথে বিরোধী নয়।

এবং কখনও কখনও, এমনকি সবচেয়ে অভিজ্ঞ বিকাশকারীরা অন্ধভাবে স্ট্যান্ডার্ডটি অনুসরণ করে এবং সবচেয়ে নিষ্ঠুর কাজগুলি তৈরি করে, কেবল কোনও সম্প্রদায়কে বাধ্য করা স্ট্যান্ডার্ডকে আঘাত না করে।

কিছুটা অতিরিক্ত তথ্য

ফাইল ফাংশনগুলি প্রায়শই প্রোটোকল মোড়কের ব্যবহারের অনুমতি দেয়, এর অর্থ http: // দিয়ে শুরু হওয়া কোনও ফাইল পাথ একটি http রিকোয়েস্টের দিকে নিয়ে যায় যা প্রায়শই "হোম কলিং" এর জন্য ব্যবহৃত হয় এবং সময়ে সময়ে একটি দোকানকে হত্যা করে কারণ সার্ভারটি পৌঁছনীয় নয় because (30 সেকেন্ডগুলির ডিফল্ট সময়সীমা) এবং এটি একটি খুব কেন্দ্রীয় জায়গায় নির্মিত।

স্কিরিএল প্রত্যেকেই বুঝতে পেরেছিল, দু'জন বিশ্বাস করে যে কতগুলি বর্গ ইনজেকশন গর্ত এখনও আছে exists মাইএসকিএল ওয়েবসাইটে অনুসন্ধানের মতো একটি দুর্দান্ত উদাহরণ ছিল।

কোথাও json_decode এর জন্য একটি মূল সহায়ক রয়েছে, তবে এটির একটি পুরানো বাস্তবায়ন রয়েছে, কেবল json_decode ব্যবহার করুন। কেন এটি নিষিদ্ধ করা উচিত আইডিয়া নেই।

গেটেক্সট একটি আকর্ষণীয় পিএইচপি অংশ, আমি মনে করি এটি কিছু নেটিভ ওএস প্রয়োগকরণ ব্যবহার করে যাতে সমস্যা হতে পারে, আপনি যদি এটি বিভিন্ন ভাষার সাথে সমান্তরালভাবে ব্যবহার করেন (যেমন এটি সাধারণত তখন ঘটে যখন আপনার দোকানটিতে একটি ভাষা বেশি থাকে really সত্যিই কখনই এটি তদন্ত করে না , তবে ম্যাজেন্টো প্রসঙ্গে এটির কোনও প্রয়োজনও হবে না।

তালিকার আরও গর্তে যাওয়া, এটি কেবলমাত্র একটি তালিকা যতটা সম্ভব কার্যকারিতা সহ বলে মনে হচ্ছে। ইতিহাস আসলে মজার, মনে হচ্ছে তারা তালিকা থেকে কিছু ফাংশন সরিয়ে নিয়েছে, তারা লক্ষ্য করার পরে তারা এটি ব্যবহার করে। : ডি