हमें क्लाइंट साइड और सर्वर साइड सत्यापन दोनों की आवश्यकता क्यों है?

Question

एक वैधकर्ता का उपयोग कर क्लाइंट साइड सत्यापन (जावास्क्रिप्ट) और सर्वर साइड सत्यापन दोनों का उपयोग करने का तर्क यह है: यदि क्लाइंट ब्राउज़र जावास्क्रिप्ट का समर्थन नहीं करता है, तो उपयोगकर्ता क्लाइंट साइड सत्यापन का उपयोग नहीं कर सकता है।

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

Answer 1

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

सर्वर-साइड सत्यापन भी इस तथ्य के कारण महत्वपूर्ण है कि क्लाइंट-साइड सत्यापन जावास्क्रिप्ट को बंद करके पूरी तरह से बाईपास किया जा सकता है। एक तरह से, जेएस संचालित मान्यता एक सुविधा और सौंदर्य/कॉस्मेटिक सुधार है और पर निर्भर होना चाहिए। इसके अलावा, जेएस सत्यापन के सबसे जटिल को अक्षम या बाईपास करने के लिए स्थानीय रूप से किसी पृष्ठ के स्रोत को संपादित करना भी छोटा है।

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

Answer 2

प्रमाणीकरण हमेशा सर्वर-पक्ष प्रदर्शन किया जाना चाहिए - आप क्लाइंट-साइड सत्यापन पर भरोसा नहीं कर सकते हैं।

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

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

अब यह आपके ऊपर है कि क्या आप गतिशील क्लाइंट-साइड सत्यापन संकेतों के साथ यूआई प्रदान करना चाहते हैं या नहीं।

Answer 3

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

Answer 4

हमेशा अपने इनपुट को सुरक्षित रखें सर्वर। यह हमेशा जावास्क्रिप्ट अक्षम उपयोगकर्ताओं के बारे में नहीं है बल्कि यह भी कि वे सर्वर तोड़ सकते हैं।

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

एक और उदाहरण है किसी बाहरी जावास्क्रिप्ट का उपयोग करने के लिए बाहरी HTTP उपकरण का उपयोग करने वाला कोई भी व्यक्ति किसी भी जावास्क्रिप्ट को पूरी तरह से बाईपास कर रहा है। मैं जेएसओएन एपीआई परीक्षण के लिए हर समय क्रोम के लिए Advanced REST Client का उपयोग करता हूं।

जावास्क्रिप्ट के माध्यम से ग्राहक पक्ष सत्यापन साइट के साथ उनकी बातचीत के बारे में किसी भी जानकारी के साइट का उपयोग कर किसी व्यक्ति को तेज फ़ीडबैक प्रदान करने का एक तरीका है। पारंपरिक क्लाइंट-सर्वर संचार में ऊपर उल्लिखित कारणों के लिए एकमात्र सत्यापन होना चाहिए।

Answer 5

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

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

यह एक वेबसाइट है कि दोनों जावास्क्रिप्ट और "पुराने" प्रौद्योगिकी का उपयोग कर रहा है प्रत्येक उपयोगकर्ता के लिए मान्य होने के लिए संभव है और हर ब्राउज़र।