जावास्क्रिप्ट: क्लाइंट-साइड बनाम सर्वर-साइड सत्यापन

Question

ग्राहक पक्ष या सर्वर साइड सत्यापन करना बेहतर है?

हमारी स्थिति में हम उपयोग कर रहे हैं

• jQuery और MVC।
• JSON डेटा हमारे दृश्य और नियंत्रक के बीच से गुजरने के लिए।

उपयोगकर्ता द्वारा दर्ज किए जाने के बाद मैं बहुत से सत्यापन डेटा को मान्य कर रहा हूं। उदाहरण के लिए, मैं keypressएक टेक्स्ट बॉक्स में अक्षरों को रोकने के लिए घटना का उपयोग करता हूं , अधिकतम संख्या में वर्ण सेट करता हूं और एक संख्या एक सीमा में होती है।

मुझे लगता है कि बेहतर सवाल होगा, क्या क्लाइंट साइड पर सर्वर साइड सत्यापन करने का कोई लाभ है?

---

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

Comments

जावास्क्रिप्ट को निष्क्रिय किया जा सकता है

— एनरिको मूरू

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

— स्टीवर्ट

Answer 1

जैसा कि दूसरों ने कहा है, आपको दोनों करना चाहिए। यहाँ पर क्यों:

ग्राहक की ओर

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

यदि आप केवल सर्वर पर मान्य हैं, तो उन्हें फ़ॉर्म जमा करना होगा, त्रुटि संदेश प्राप्त करना होगा, और समस्या का शिकार करने का प्रयास करना होगा।

(सर्वर द्वारा उपयोगकर्ता के मूल इनपुट के साथ फ़ॉर्म को फिर से प्रस्तुत करने से इस दर्द को कम किया जा सकता है, लेकिन क्लाइंट-साइड सत्यापन अभी भी तेज है।)

सर्वर साइड

आप सर्वर की ओर से मान्य करना चाहते हैं क्योंकि आप दुर्भावनापूर्ण उपयोगकर्ता से सुरक्षा कर सकते हैं , जो आसानी से आपके जावास्क्रिप्ट को बायपास कर सकते हैं और सर्वर को खतरनाक इनपुट सबमिट कर सकते हैं।

अपने यूआई पर भरोसा करना बहुत खतरनाक है। न केवल वे आपके UI का दुरुपयोग कर सकते हैं, लेकिन वे आपके UI का उपयोग नहीं कर सकते हैं, या यहां तक ​​कि एक ब्राउज़र भी । क्या होगा यदि उपयोगकर्ता मैन्युअल रूप से URL को संपादित करता है, या अपनी स्वयं की जावास्क्रिप्ट चलाता है, या किसी अन्य टूल के साथ अपने HTTP अनुरोधों को घुमाता है? क्या होगा यदि वे curlउदाहरण के लिए या स्क्रिप्ट से कस्टम HTTP अनुरोध भेजते हैं ?

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

इसके लिए अनुमति नहीं देना न केवल सुरक्षा के दृष्टिकोण से भोला है, बल्कि गैर-मानक भी है: एक ग्राहक को जो भी वे चाहते हैं, उसके द्वारा HTTP भेजने की अनुमति दी जानी चाहिए, और आपको सही तरीके से जवाब देना चाहिए। जिसमें मान्यता शामिल है।

संगतता के लिए सर्वर साइड सत्यापन भी महत्वपूर्ण है - सभी उपयोगकर्ता नहीं, भले ही वे एक ब्राउज़र का उपयोग कर रहे हों, जावास्क्रिप्ट सक्षम होगा।

परिशिष्ट - दिसंबर २०१६

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

Comments

यह स्वीकृत उत्तर होना चाहिए, यहां तक ​​कि 6 साल बाद: पी

— जैकब मैकके

हां, मैं यह सुनिश्चित करने के लिए लगभग 10 साल इंतजार करना चाहता था।

— ब्रैड .११ Brad

@kidmosey "यह DRY सिद्धांतों का एक स्पष्ट उल्लंघन है" हां, जिसका अर्थ है हमारे जैसे प्रोग्रामर के लिए दर्द। लेकिन साइनअप फॉर्म की कल्पना करें। यदि ज्ञान को डुप्लिकेट करने पर ग्राहक कोड में "एक ईमेल पते में एक @" होना चाहिए, तो इसका मतलब है कि उपयोगकर्ताओं को तेजी से प्रतिक्रिया मिलती है और उनमें से अधिक साइन अप करते हैं, जिसके परिणामस्वरूप प्रति वर्ष $ 100k अतिरिक्त राजस्व होता है, यह अतिरिक्त रखरखाव लागतों के लिए भुगतान से अधिक है। DRY एक बहुत अच्छा सिद्धांत है, लेकिन यह एकमात्र विचार नहीं है। कोड की गुणवत्ता को वास्तव में मापा जाता है कि यह उपयोगकर्ताओं और किसी संगठन को लागत / लाभ विश्लेषण में कितनी अच्छी तरह से कार्य करता है।

— नाथन लॉन्ग

@ArunRaaj हां, और आप इस तरह की अधिकांश समस्याओं को पकड़ लेंगे, लेकिन यह 100% विश्वसनीय नहीं है। यदि दो उपयोगकर्ता एक ही समय पर फ़ॉर्म भर रहे हैं, तो उन्हें बताया जा सकता है कि user1उपलब्ध उपयोगकर्ता नाम है। जब वे सबमिट करते हैं, तो वे दोनों एक ही उपयोगकर्ता नाम प्राप्त करेंगे जब तक कि आप सर्वर की ओर से फिर से जांच न करें। और यहां तक ​​कि सर्वर एप्लिकेशन कोड में एक चेक में भी यही समस्या हो सकती है: दो अनुरोध आते हैं, पहला डेटाबेस को चेक करता है और ओके को बताया जाता है, दूसरा डेटाबेस को चेक करता है और ओके को बताया जाता है, पहला बच जाता है, दूसरा बच जाता है। एक नकल के रूप में। केवल एक db अद्वितीय बाधा अद्वितीयता की गारंटी देता है।

— नाथन लॉन्ग

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

— एलस्कैन्टर

Answer 2

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

Answer 3

मैं इसे दोहराने जा रहा हूं, क्योंकि यह काफी महत्वपूर्ण है:

हमेशा सर्वर पर मान्य

और उपयोगकर्ता-जवाबदेही के लिए जावास्क्रिप्ट जोड़ें।

Answer 4

क्लाइंट साइड सत्यापन पर सर्वर साइड सत्यापन करने का लाभ यह है कि क्लाइंट साइड सत्यापन को बाईपास / हेरफेर किया जा सकता है:

• अंतिम उपयोगकर्ता के पास जावास्क्रिप्ट स्विच ऑफ हो सकता है
• डेटा को सीधे आपके सर्वर पर भेजा जा सकता है, जो आपकी साइट का उपयोग नहीं कर रहा है, ऐसा करने के लिए डिज़ाइन किए गए एक कस्टम ऐप के साथ
• आपके पृष्ठ पर एक जावास्क्रिप्ट त्रुटि (किसी भी चीज़ की संख्या के कारण) परिणाम में कुछ हो सकती है, लेकिन सभी नहीं, आपके सत्यापन चल रहे हैं

संक्षेप में - हमेशा, हमेशा सर्वर-साइड को मान्य करें और फिर क्लाइंट-साइड सत्यापन को अंतिम उपयोगकर्ता अनुभव को बढ़ाने के लिए "अतिरिक्त" के रूप में मानें।

Answer 5

आपको सर्वर पर हमेशा मान्य होना चाहिए ।

इसके अलावा क्लाइंट पर सत्यापन उपयोगकर्ताओं के लिए अच्छा है, लेकिन पूरी तरह असुरक्षित है।

Answer 6

खैर, मुझे अभी भी जवाब देने के लिए कुछ जगह मिल गई है।

रोब और नाथन के जवाबों के अलावा, मैं जोड़ूंगा कि क्लाइंट-साइड सत्यापन मायने रखता है। जब आप अपने वेबफ़ॉर्म पर सत्यापन लागू कर रहे हैं तो आपको इन दिशानिर्देशों का पालन करना चाहिए:

ग्राहक की ओर

1. आपकी वेबसाइट पर वास्तविक उपयोगकर्ताओं से आने वाले वास्तविक अनुरोधों को फ़िल्टर करने के लिए क्लाइंट-साइड सत्यापन का उपयोग करना चाहिए।
2. क्लाइंट-साइड सत्यापन सर्वर साइड प्रसंस्करण के दौरान उत्पन्न त्रुटियों को कम करने के लिए इस्तेमाल किया जाना चाहिए।
3. क्लाइंट-साइड सत्यापन का उपयोग सर्वर-साइड राउंड-ट्रिप्स को कम करने के लिए किया जाना चाहिए ताकि आप बैंडविड्थ और प्रति उपयोगकर्ता अनुरोधों को बचा सकें।

सर्वर साइड

1. आप ग्राहक आधार पर सफलतापूर्वक किया गया सत्यापन 100% सही नहीं मानते हैं। कोई फर्क नहीं पड़ता भले ही वह 50 से कम उपयोगकर्ताओं को सेवा देता हो। आप कभी नहीं जानते हैं कि आपका कौन सा उपयोगकर्ता / एम्पली एक "बुराई" में बदल जाता है और कुछ हानिकारक गतिविधि करता है, जिससे आपको पता चलता है कि आपके पास उचित मान्यता नहीं है।
2. भले ही ईमेल पते, फोन नंबरों को मान्य करने या कुछ वैध इनपुट्स की जांच करने के मामले में यह एकदम सही है, इसमें बहुत हानिकारक डेटा हो सकता है। अगर इसके सही या गलत होने पर सर्वर-साइड पर कोई बात नहीं करनी चाहिए।
3. यदि क्लाइंट-साइड सत्यापन को बायपास किया जाता है, तो आपके सर्वर-साइड सत्यापन आपको अपने सर्वर-साइड प्रसंस्करण के किसी भी संभावित नुकसान से बचाने के लिए आते हैं। हाल के दिनों में, हमने पहले ही SQL इंजेक्शन और अन्य प्रकार की तकनीकों की बहुत सी कहानियाँ सुनी हैं, जो कुछ बुरे लाभ प्राप्त करने के लिए लागू की जा सकती हैं।

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

Comments

मैंने लोगों को कोड इंजेक्शन से बचाने के लिए पूरी तरह से उपेक्षा करते देखा है, कभी भी इसे केवल ग्राहक की तरफ ध्यान न दें। और कोड इंजेक्शन का कोई संदर्भ इस लिंक के बिना पूरा नहीं हुआ है: xkcd.com/327 :)

— स्टीवर्ट

Answer 7

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

Comments

यूजर फ्रेंडली? शायद। लगभग तात्कालिक और मक्खनदार चिकनी? शायद ऩही।

— quadrupleslap

Answer 8

क्लाइंट पक्ष को HTML5 इनपुट प्रकार और पैटर्न विशेषताओं के माध्यम से एक मूल सत्यापन का उपयोग करना चाहिए और क्योंकि ये केवल बेहतर उपयोगकर्ता अनुभव के लिए प्रगतिशील संवर्द्धन के लिए उपयोग किए जाते हैं (भले ही वे <IE9 और सफारी पर समर्थित नहीं हैं, लेकिन हम उन पर भरोसा नहीं करते हैं)। लेकिन मुख्य सत्यापन सर्वर साइड पर होना चाहिए।

Comments

"लेकिन मुख्य सत्यापन सर्वर की तरफ होना चाहिए।" नहीं चाहिए, चाहिए।

— स्टीवर्ट

Answer 9

मैं क्लाइंट और सर्वर सत्यापन दोनों को कार्यान्वित करने का सुझाव दूंगा जो परियोजना को अधिक सुरक्षित रखता है ...... अगर मुझे एक चुनना है तो मैं सर्वर साइड सत्यापन के साथ जाऊंगा।

आप कुछ प्रासंगिक जानकारी यहां पा सकते हैं https://web.archive.org/web/20131210085944/http://www.webexpertlabs.com/server-side-form-validation-using- अनियमित-expression/

Answer 10

जावास्क्रिप्ट को रनटाइम पर संशोधित किया जा सकता है।

मैं सर्वर पर एक सत्यापन संरचना बनाने और ग्राहक के साथ इसे साझा करने का एक पैटर्न सुझाता हूं।

आपको दोनों सिरों पर अलग-अलग सत्यापन तर्क की आवश्यकता होगी, उदा:

"required"inputsक्लाइंट-साइड पर विशेषताएँ

field.length > 0 सर्वर साइड।

लेकिन एक ही सत्यापन विनिर्देश का उपयोग दोनों सिरों पर सत्यापन को प्रतिबिंबित करने के कुछ अतिरेक (और गलतियों) को समाप्त करेगा।

Answer 11

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

फिर भी, जैसा कि एक हमलावर ग्राहक पक्ष सत्यापन को दरकिनार कर सकता है (और ब्राउज़र का उपयोग भी नहीं कर सकता है), सर्वर साइड सत्यापन आवश्यक है, और आपके बैकएंड को नापाक उपयोगकर्ताओं से बचाने के लिए वास्तविक गेट होना चाहिए।

Answer 12

मुझे एक दिलचस्प कड़ी सामने आई जो सकल, व्यवस्थित, यादृच्छिक त्रुटियों के बीच अंतर करती है।

Client-Side validationसकल और यादृच्छिक त्रुटियों को रोकने के लिए पूरी तरह से सूट करता है। आमतौर पर बनावट और इनपुट के लिए अधिकतम लंबाई। सर्वर-साइड सत्यापन नियम की नकल न करें; अपने स्वयं के सकल, अंगूठे सत्यापन नियम (ग्राहक-पक्ष पर पूर्व 200 वर्ण, nएक मजबूत व्यवसाय द्वारा निर्धारित सर्वर-साइड) प्रदान करें।

Server-side validationव्यवस्थित त्रुटियों को रोकने के लिए पूरी तरह से सूट; यह व्यावसायिक नियमों को लागू करेगा।

मैं जिस परियोजना में शामिल हूं, वह सत्यापन सर्वर पर ajax अनुरोधों के माध्यम से किया जाता है। क्लाइंट पर मैं तदनुसार त्रुटि संदेश प्रदर्शित करता हूं।

आगे पढ़ने: सकल, व्यवस्थित, यादृच्छिक त्रुटियों:

https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO

Answer 13

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

Comments

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

— क्रेमुवा