💛 💛 🔱 MySQL के साथ सुविधाजनक और सुरक्षित काम करने के लिए PHP वर्ग 🔎 👩🏻‍🤝‍👨🏾 🕴🏼

इंजेक्शन के खिलाफ सुरक्षा के बारे में एक लेख लिखने के बाद , मैंने एक वर्ग लिखने के बारे में सेट किया जो इसमें निहित विचारों को लागू करता है।
अधिक सटीक रूप से, चूंकि मुख्य कार्यक्षमता पहले से ही कार्य ढांचे के ढांचे के भीतर उपयोग की गई है, इसलिए मैंने इसे एक स्वतंत्र वर्ग में अलग करने के बारे में निर्धारित किया है। इस अवसर को लेते हुए, मैं कई महत्वपूर्ण त्रुटियों और उपयोगी टिप्पणियों को सही करने में उनकी मदद के लिए PHPClub के प्रतिभागियों को धन्यवाद देना चाहता हूं। नीचे मैं मुख्य विशेषताओं का वर्णन करने की कोशिश करूंगा, लेकिन पहले एक छोटा

त्याग

SQL के साथ काम करने के कई तरीके हैं - आप q-बिल्डर का उपयोग कर सकते हैं, आप ORM का उपयोग कर सकते हैं, आप शुद्ध SQL के साथ काम कर सकते हैं। मैंने आखिरी विकल्प चुना, क्योंकि यह मेरे करीब है। मुझे नहीं लगता कि पहले दो बिल्कुल खराब हैं। यह सिर्फ इतना है कि मैं व्यक्तिगत रूप से हमेशा उनके ढांचे में तंग आया हूं। लेकिन किसी भी तरह से मैं यह दावा नहीं करता कि मेरा विकल्प बेहतर है। यह सिर्फ एक और विकल्प है। जिसका उपयोग ओआरएम लिखते समय, अन्य चीजों के बीच किया जा सकता है। किसी भी मामले में, मेरा मानना है कि शुद्ध एसक्यूएल के साथ काम करने का सुरक्षित तरीका कोई नुकसान नहीं कर सकता है। लेकिन एक ही समय में, यह अंतिम शातिर अभ्यास छोड़ने के लिए आवेदन कोड में mysql_ * का उपयोग करने के अंतिम शेष अनुयायियों की मदद कर सकता है।

संक्षेप में, वर्ग सहायक कार्यों के एक सेट के आसपास बनाया गया है जो आपको SQL इंजेक्शन के खिलाफ पूर्ण सुरक्षा प्रदान करते हुए, एक लाइन पर अधिकांश डेटाबेस संचालन करने की अनुमति देता है, किसी भी डेटा प्रकार की रक्षा करने वाले प्लेसहोल्डर्स के एक विस्तारित सेट का उपयोग करके कार्यान्वित किया जाता है, जिसे अनुरोध मिल सकता है।
कक्षा तीन मूल सिद्धांतों पर आधारित है:

SQL इंजेक्शन के खिलाफ 100% सुरक्षा
एक ही समय में, सुरक्षा का उपयोग करने के लिए बहुत सुविधाजनक है, कोड को छोटा और लंबे समय तक नहीं बनाया जा सकता है
बहुमुखी प्रतिभा, पोर्टेबिलिटी और विकास में आसानी

मैं प्रत्येक बिंदु पर थोड़ा और ध्यान दूंगा।

सुरक्षा

लेख में मेरे द्वारा तैयार किए गए बहुत ही दो नियमों द्वारा प्रदान किया गया है:

कोई भी - अपवाद के बिना! - गतिशील तत्व केवल प्लेसहोल्डर्स के माध्यम से अनुरोध में आते हैं।
प्लेसहोल्डर के माध्यम से प्रतिस्थापित नहीं किया जा सकता है कि सब कुछ पहले सफेद सूची के माध्यम से चलाया जाता है।

दुर्भाग्य से, मानक पुस्तकालय इंजेक्शन के खिलाफ पूर्ण सुरक्षा प्रदान नहीं करते हैं, केवल तैयार किए गए बयानों के साथ तार और संख्याओं की रक्षा करते हैं।
इसलिए, रक्षा को पूर्ण बनाने के लिए, मुझे व्यापक अवधारणा - प्लेसहोल्डर्स के पक्ष में तैयार बयानों की स्पष्ट रूप से सीमित अवधारणा को छोड़ना पड़ा। इसके अलावा, प्लेसहोल्डर्स टाइप किए जाते हैं (यह बात हम सभी को प्रिंटफ () फ़ंक्शंस के परिवार द्वारा ज्ञात होती है:% d एक प्लेसहोल्डर है जो पार्सर को बताता है कि प्रतिस्थापनित मूल्य को कैसे संसाधित किया जाए, इस मामले में, पूर्णांक के रूप में)। नवाचार इतना सफल रहा कि इसने एक साथ कई समस्याओं को हल किया और कोड को सरल बनाया। मैं नीचे टाइप किए गए प्लेसहोल्डर्स के बारे में अधिक लिखूंगा।
वाइटेलिस्टिंग फ़िल्टरिंग के लिए सहायता दो कार्यों द्वारा प्रदान की जाती है, कुछ हद तक दूर की, लेकिन फिर भी आवश्यक है।

आवेदन कोड की सुविधा और संक्षिप्तता

यहां, टाइप किए गए प्लेसहोल्डर्स ने भी मेरी बहुत मदद की, जिससे फंक्शन कॉल को सिंगल-लाइन करना संभव हो गया, इसके लिए अनुरोध और डेटा दोनों को तुरंत स्थानांतरित कर दिया। इसके अलावा PEAR :: DB - उन कार्यों से मिलते-जुलते सहायकों का एक समूह - जो वांछित प्रकार के परिणाम को तुरंत वापस करता है। सभी सहायकों को एक ही योजना के अनुसार आयोजित किया जाता है: फ़ंक्शन के लिए एक आवश्यक पैरामीटर पास किया जाता है - प्लेसहोल्डर्स के साथ एक अनुरोध, और आवश्यक के रूप में कई वैकल्पिक पैरामीटर, संख्या और क्रम जिसमें अनुरोध में प्लेसहोल्डर्स की संख्या और क्रम के साथ मेल खाना चाहिए। इंडस्ट्रीज़ परिवार के कार्य एक अन्य आवश्यक पैरामीटर का उपयोग करते हैं - उस फ़ील्ड का नाम जिसके द्वारा लौटे सरणी को अनुक्रमित किया जाता है।
अपने अनुभव के आधार पर, मैं वापसी मूल्यों के निम्नलिखित सेट पर आया (और, परिणामस्वरूप, सहायकों):

क्वेरी () - mysqli संसाधन देता है। यह परंपरागत रूप से भ्रूण (), आदि के साथ इस्तेमाल किया जा सकता है।
getOne () - स्केलर, परिणाम की पहली पंक्ति का पहला तत्व देता है
getRow () - एक आयामी सरणी, परिणाम की पहली पंक्ति
getCol () - स्केलर्स की एक-आयामी सरणी - टेबल कॉलम
getAll () - क्रम में संख्याओं द्वारा अनुक्रमित दो-आयामी सरणी
getInd () - पहले पैरामीटर द्वारा निर्दिष्ट क्षेत्र के मूल्यों द्वारा अनुक्रमित दो-आयामी सरणी
getIndCol () - पहले पैरामीटर से फ़ील्ड द्वारा अनुक्रमित स्केलर्स की एक सरणी। प्रपत्र कुंजी => मान के शब्दकोशों के संकलन के लिए अपरिहार्य

नतीजतन, अधिकांश डेटाबेस एक्सेस एक या दो लोअरकेस निर्माणों के लिए आते हैं (पारंपरिक दृष्टिकोण के साथ 5-10 के बजाय):

$data = $db->getAll("SELECT * FROM ?n WHERE mod=?s LIMIT ?i",$table,$mod,$limit);

इस कोड में केवल आवश्यक और महत्वपूर्ण तत्व हैं, लेकिन कुछ भी नहीं है जो अति सुंदर और दोहराव वाला है। सभी गिबल्स को बड़े करीने से कक्षा के अंदर छिपाया जाता है: getAll () सहायक आपको आवेदन कोड में चक्र लिखे बिना तुरंत वांछित परिणाम प्राप्त करने की अनुमति देता है, और टाइप किए गए प्लेसहोल्डर आपको मैन्युअल रूप से bind_param लिखने के लिए किसी भी प्रकार के गतिशील तत्वों को सुरक्षित रूप से जोड़ने की अनुमति देते हैं। अतिरिक्त DRY कोड! प्लेसहोल्डर का उपयोग करने के मामलों में? ए और यू, कोड की मात्रा में अंतर और भी अधिक हो जाता है:

 $data = $db->getAll("SELECT * FROM table WHERE category IN (?a)",$ids);

बहुमुखी प्रतिभा और विकास में आसानी

तीन स्तंभों पर खड़े हो जाओ:

एक बहुत छोटा एपीआई - आधा दर्जन प्लेसहोल्डर्स और कई सहायकों के रूप में।
हम अच्छे पुराने SQL के साथ काम कर रहे हैं, जिसे दोबारा पढ़ाने की जरूरत नहीं है।
पहली नज़र में, असंगत लेकिन अविश्वसनीय रूप से उपयोगी फ़ंक्शन पार्स (), जो मूल रूप से केवल डीबगिंग के लिए अभिप्रेत था, लेकिन अंततः जटिल प्रश्नों की तैयारी में एक प्रमुख तत्व तक बढ़ गया।

नतीजतन, सभी जटिल प्रश्नों को पुराने ढंग से एकत्र किया जाता है - उदाहरण के लिए, एक लूप में - लेकिन एक ही समय में, सभी सुरक्षा नियमों के अधीन!
मैं एक छोटा सा उदाहरण दूंगा (लेख के नीचे लिंक पर प्रलेखन में अधिक जटिल उदाहरण पाए जा सकते हैं):
एक बहुत ही सामान्य मामला है जब हमें एक चर होने पर अनुरोध में एक शर्त जोड़ने की आवश्यकता होती है

 $sqlpart = ''; if (!empty($var)) { $sqlpart = $db->parse(" AND field = ?s", $var); } $data = $db->getAll("SELECT * FROM table WHERE a=?i ?p", $id, $sqlpart);

कुछ बिंदुओं पर ध्यान देना महत्वपूर्ण है।
सबसे पहले, चूंकि हम मूल एपीआई से जुड़े नहीं हैं, कोई भी हमें पूरे अनुरोध को पार्स करने के लिए मना नहीं करता है, लेकिन इसका केवल एक हिस्सा है। यह उन अनुरोधों के लिए सुपर-सुविधाजनक हो जाता है जो कुछ तर्क के अनुसार एकत्र किए जाते हैं: हम अनुरोध के केवल भाग को पार्स करते हैं, और फिर इसे बार-बार पार्स करने से बचने के लिए एक विशेष "निष्क्रिय" प्लेसहोल्डर के माध्यम से मुख्य अनुरोध में डाला जाता है (और नियम का पालन करते हुए किसी भी तत्व को केवल प्रतिस्थापित किया जाता है। प्लेसहोल्डर ")।
लेकिन, दुर्भाग्य से, यह पूरी कक्षा का कमजोर बिंदु है। अन्य सभी प्लेसहोल्डर्स के विपरीत (जो, भले ही गलत तरीके से उपयोग किया जाता है, कभी भी इंजेक्शन का नेतृत्व नहीं करेगा), प्लेसहोल्डर का गलत उपयोग? पी इसे जन्म दे सकता है।
हालाँकि, एक मूर्ख व्यक्ति से सुरक्षा वर्ग को बहुत उलझा देती है, लेकिन साथ ही यह क्वेरी स्ट्रिंग में एक वैरिएबल डालने के खिलाफ रक्षा नहीं करेगा। इसलिए, मैंने इसे वैसे ही छोड़ने का फैसला किया। लेकिन अगर आप बहुत अधिक इंजीनियरिंग के बिना इस समस्या को हल करने का एक तरीका जानते हैं, तो मैं विचारों के लिए आभारी रहूंगा।

हालाँकि, अंत में हमें एक शक्तिशाली और हल्का क्वेरी जनरेटर मिला जो इस छोटी सी खामी को सही ठहराता है।
शक्तिशाली क्योंकि हम निर्माण बिल्डर के वाक्य-विन्यास से सीमित नहीं हैं, "PHP में लिखा SQL" - हम शुद्ध SQL लिखते हैं।
आसान क्योंकि प्रश्नों के संकलन के लिए पूरे एपीआई में आधा दर्जन प्लेसहोल्डर और पार्स () फ़ंक्शन शामिल हैं
यहां मेरा पसंदीदा उदाहरण है - मैसकल कार्यों का उपयोग करना

 $data = array('field'=>$value,'field2'=>$value); $sql = "INSERT INTO table SET ts=unix_timestamp(), ip=inet_aton(?s),?u"; $db->query($sql, $ip, $data);

एक तरफ, हम एसक्यूएल सिंटैक्स को सहेजते हैं, दूसरे पर, हम इसे सुरक्षित बनाते हैं, और तीसरे पर, हम कोड की मात्रा को पूरी तरह से कम कर देते हैं।

टाइप किए गए प्लेसहोल्डर्स के बारे में अधिक

सबसे पहले, इस सवाल का जवाब दें, सामान्य तौर पर प्लेसहोल्डर क्यों?
यह, सामान्य तौर पर, पहले से ही एक आम जगह है, लेकिन, फिर भी, मैं दोहराता हूं - किसी भी गतिशील डेटा को निम्नलिखित कारणों से केवल प्लेसहोल्डर्स के माध्यम से अनुरोध में प्राप्त करना चाहिए :

सबसे महत्वपूर्ण बात सुरक्षा है। प्लेसहोल्डर के माध्यम से एक चर जोड़कर, हम यह सुनिश्चित कर सकते हैं कि इसे सही ढंग से स्वरूपित किया जाएगा।
स्थानीयता का प्रारूपण। यह कोई कम महत्वपूर्ण बात नहीं है। सबसे पहले, डेटा को अनुरोध दर्ज करने से तुरंत पहले स्वरूपित किया जाता है, और मूल चर को प्रभावित नहीं करता है, जिसे बाद में कहीं और इस्तेमाल किया जा सकता है। दूसरे, डेटा को ठीक उसी जगह स्वरूपित किया जाता है, जहां इसकी आवश्यकता होती है, और स्क्रिप्ट के काम शुरू होने से पहले नहीं, जैसा कि जादू उद्धरण के साथ होता है, और कई डेवलपर्स द्वारा कोड के दस संभावित स्थानों में नहीं, जिनमें से प्रत्येक दूसरे पर भरोसा कर सकते हैं।

इस अवधारणा को और विकसित करते हुए, हम इस निष्कर्ष पर पहुँचे हैं कि पेसोल्डर्स को टाइप किया जाना चाहिए। लेकिन क्यों?
यहां मैं संक्षेप में रोकना चाहता हूं और इंजेक्शन के खिलाफ सुरक्षा के क्षेत्र में प्रोग्रामर के विचार के विकास के इतिहास का पता लगाता हूं।
पहले तो अराजकता थी - बिल्कुल भी सुरक्षा नहीं थी, हम सब कुछ वैसे ही छोड़ देते हैं।
तब यह बहुत बेहतर नहीं हुआ, प्रतिमान के साथ "हम उपयोगकर्ता से स्क्रिप्ट में आने वाली हर चीज को अलग कर देंगे" और जादू उद्धरण के रूप में चरमोत्कर्ष।
इसके अलावा, सबसे अच्छे दिमाग इस निष्कर्ष पर पहुंचे कि स्क्रीनिंग के बारे में नहीं, बल्कि फ़ॉर्मेटिंग के बारे में बोलना सही है। चूंकि स्वरूपण हमेशा एक आइसकीटिंग के लिए कम नहीं होता है। तो बोली () विधि पीडीओ में दिखाई दी, जिसने स्ट्रिंग का पूर्ण स्वरूपण किया - न केवल इसमें विशेष वर्ण बच गए, बल्कि एक प्रोग्रामर की उम्मीद न करते हुए, इसे उद्धरण चिह्नों में संलग्न किया। नतीजतन, भले ही प्रोग्रामर ने इस फ़ंक्शन को जगह से बाहर किया हो (उदाहरण के लिए, एक संख्या के लिए), इंजेक्शन अभी भी पास नहीं हुआ (और mysql_real_escape_string के माध्यम से नग्न भागने के मामले में, यह आसानी से गुजरता है कि हमने इसे उद्धृत किए बिना क्वेरी में एक नंबर डाल दिया है। )। पहचानकर्ता को प्रारूपित करने के लिए उपयोग किए जाने के कारण, इस फ़ंक्शन ने विकास के चरण में एक त्रुटि पैदा की, जिससे कोड के लेखक को पता चला कि वह थोड़ा गलत था।
दुर्भाग्य से, पीडीओ के लेखकों ने इस पर रोक लगा दी, क्योंकि यह अनुरोध केवल स्वरूपण में स्वरूपण डेवलपर्स के दिमाग में अभी भी मजबूती से है। लेकिन वास्तव में, अनुरोध में सबसे अधिक प्रकार के बहुत अधिक तत्व हैं। और प्रत्येक को स्वरूपण की अपनी आवश्यकता है! यही कारण है, केवल बोली () विधि हमें बिल्कुल भी पसंद नहीं है - आपको विभिन्न उद्धरणों की बहुत आवश्यकता है। और एक अपवाद के रूप में नहीं, "यहां आपके पास कोटनाम ()" है, लेकिन मुख्य अवधारणाओं में से एक के रूप में: प्रत्येक प्रकार का अपना प्रारूप है। खैर, चूंकि कई प्रकार के प्रारूपण हैं, इसलिए किसी प्रकार को निर्दिष्ट किया जाना चाहिए। और एक टाइप प्लेसहोल्डर इसके लिए सबसे उपयुक्त है।

इसके अलावा, एक टाइप प्लेसहोल्डर बहुत सुविधाजनक है!
सबसे पहले, क्योंकि किसी प्लेसहोल्डर को मान बाँधने के लिए किसी विशेष ऑपरेटर का उपयोग करना अनावश्यक हो जाता है (लेकिन साथ ही, प्रेषित किए जाने वाले मूल्य के प्रकार को निर्दिष्ट करना संभव रहता है!)
दूसरे, चूंकि हमने एक टाइप किए गए प्लेसहोल्डर का आविष्कार किया है, इसलिए हम SQL क्वेरी कंपोज़िट के कई नियमित कार्यों को हल करने के लिए इन प्लेसहोल्डर्स की एक बड़ी संख्या जोड़ सकते हैं।
सबसे पहले, हम पहचानकर्ताओं के लिए एक प्लेसहोल्डर बनाएंगे - हमें वास्तविक जीवन में इसकी सख्त कमी है, और मानक एपीआई के लेखकों द्वारा कल्पना नहीं की गई है। जैसे ही डेवलपर को अनुरोध करने के लिए एक फ़ील्ड नाम को गतिशील रूप से जोड़ने की आवश्यकता का सामना करना पड़ता है, हर एक अपने तरीके से विकृत करना शुरू कर देता है, जो जंगल में है, जो जलाऊ लकड़ी से है। यहां, बाकी क्वेरी तत्वों के साथ सब कुछ एकीकृत है, और एक पहचानकर्ता को जोड़ना एक पंक्ति जोड़ने की तुलना में अधिक कठिन नहीं है। लेकिन एक ही समय में, पहचानकर्ता को एक स्ट्रिंग के रूप में प्रारूपित नहीं किया जाता है, बल्कि अपने स्वयं के नियमों के अनुसार - यह बैकक्वाटर में संलग्न है, और इन उद्धरणों के अंदर दोहरीकरण से बच जाते हैं।
ज्यादा है। किसी भी डेवलपर का अगला सिरदर्द जिसने कभी वास्तविक जीवन में मानक तैयार बयानों का उपयोग करने की कोशिश की है, वह IN () ऑपरेटर है। वोइला, हमारे पास इस ऑपरेशन के लिए एक प्लेसहोल्डर भी है! सरणी प्रतिस्थापन किसी भी अन्य तत्वों की तुलना में अधिक जटिल नहीं हो जाता है, प्लस यह उनके साथ एकीकृत है - कोई अलग कार्य नहीं, केवल प्लेसहोल्डर में पत्र बदलता है।
ठीक उसी तरह, हम SET के लिए प्लेसहोल्डर करते हैं। मैं विरोध नहीं कर सकता और प्रदर्शित कर सकता हूं कि INSERT जैसी उलझी हुई क्वेरी के लिए कोड कितना सरल हो गया है ... ON DUPLICATE:

 $data = array('offers_in' => $in, 'offers_out' => $out); $sql = "INSERT INTO stats SET pid=?i,dt=CURDATE(),?u ON DUPLICATE KEY UPDATE ?u"; $db->query($sql,$pid,$data,$data);

वर्तमान में वर्ग 6 प्रकार के प्लेसहोल्डर्स का समर्थन करता है।

s ("स्ट्रिंग") - तार (साथ ही साथ DATE, FLOAT और DECIMAL)।
? मैं ("पूर्णांक") पूर्णांक हैं।
? n ("नाम") - फ़ील्ड और टेबल के नाम
? पी ("पार्स") - अनुरोध के पहले से ही संसाधित भागों को सम्मिलित करने के लिए
? ("सरणी") - IN के लिए मानों का एक सेट (प्रपत्र 'a', 'b', 'c' की एक स्ट्रिंग)
? u ("अपडेट") - SET के लिए मानों का एक सेट (फॉर्म की एक स्ट्रिंग `फ़ील्ड` = 'मान', `फ़ील्ड` = 'मान')

जो मेरे कार्यों के लिए काफी पर्याप्त है, लेकिन इस सेट को हमेशा किसी भी अन्य प्लेसहोल्डर्स के साथ विस्तारित किया जा सकता है, उदाहरण के लिए, आंशिक संख्याओं के लिए। मैं NULL के लिए एक अलग प्लेसहोल्डर बनाने के बिंदु को नहीं देखता - आप हमेशा इसे सीधे अनुरोध में दर्ज कर सकते हैं।
मैंने निर्णय लिया कि PHP null को SQL null में स्वचालित रूप से अनुवादित नहीं किया जाएगा। शायद यह कोड को थोड़ा जटिल करेगा (उन दुर्लभ मामलों में जब इसकी आवश्यकता होती है), लेकिन यह इसकी अस्पष्टता को कम करेगा।

वैसे, जैसा कि कई नोटिस कर सकते हैं, यह वर्ग दिमित्री कोटरोव के डीबीसिमल पुस्तकालय की तरह है। लेकिन इसमें निहित कुछ विचारों के साथ मेरे मूलभूत मतभेद हैं।
सबसे पहले, मैं किसी भी जादू का विरोध करता हूं जब एक ही फ़ंक्शन स्थानांतरित किए गए डेटा के प्रकार के आधार पर एक अलग परिणाम लौटा सकता है। यह, शायद, लेखन को थोड़ा आसान बनाता है, लेकिन एक ही समय में कोड को बनाए रखना और डीबग करना राक्षसी रूप से कठिन है। इसलिए, मेरी कक्षा में, सभी जादू को कम से कम किया जाता है, और सभी ऑपरेशन और डेटा प्रकार हमेशा स्पष्ट रूप से पंजीकृत होते हैं।
दूसरे, DbSimple में थोड़ा, मेरी राय में, एक ओवरलैम्प्ड सिंटैक्स। एक ओर, ब्रेसिज़ एक महान विचार है। दूसरी ओर, क्यों, अगर हमारे पास हमारे निपटान में PHP की सारी शक्ति है? इसलिए, मैंने दूसरे रास्ते पर जाने का फैसला किया और "आंतरिक" - स्पष्ट रूप से सीमित - तर्क को "बाहरी" एक के रूप में पेश किया, केवल PHP सिंटैक्स द्वारा सीमित। मुख्य बात यह है कि किसी भी गतिशील तत्व केवल प्लेसहोल्डर्स के माध्यम से अनुरोध में आते हैं, और बाकी केवल डेवलपर की कल्पना (और पार्स () फ़ंक्शन) पर निर्भर करता है।

वर्ग कोड github, github.com/colshrapnel/safemysql/blob/master/safemysql.class.php पर उपलब्ध है
बुनियादी आज्ञाओं और उदाहरणों के साथ धोखा शीट: phpfaq.ru/misc/safemysql_cheatsheet_b.df
आप नमूना प्रलेखन पृष्ठ पर सुविधाओं का एक अच्छा विचार प्राप्त कर सकते हैं (दुर्भाग्य से, अभी तक पूरा नहीं), phpfaq.ru/safemysql
अक्सर पूछे जाने वाले प्रश्नों के उत्तर भी होते हैं, जैसे "आप देशी तैयार बयानों का उपयोग क्यों नहीं करते?", आदि।
फिर भी, मुझे टिप्पणियों में किसी भी प्रश्न का उत्तर देने में खुशी होगी, साथ ही आपकी टिप्पणियों पर कक्षा और इस लेख दोनों में सुधार होगा।

MySQL के साथ सुविधाजनक और सुरक्षित काम करने के लिए PHP वर्ग

सुरक्षा

आवेदन कोड की सुविधा और संक्षिप्तता

बहुमुखी प्रतिभा और विकास में आसानी

टाइप किए गए प्लेसहोल्डर्स के बारे में अधिक

More articles: