फ़ॉर्म वैलिडेशन: सर्वर-साइड बनाम क्लाइंट-साइड के बेस्ट प्रैक्टिस

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

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

वैलिडेशन क्या है?

वैलिडेशन जांचता है कि फ़ॉर्म में डाला गया डेटा आपकी ज़रूरतों के हिसाब से है या नहीं। ज़रूरी फ़ील्ड में वैल्यू होती है। ईमेल फ़ील्ड में @ चिह्न होता है। फ़ोन फ़ील्ड में सिर्फ़ नंबर होते हैं। अपलोड की गई फ़ाइल साइज़ लिमिट के अंदर होती है।

वैलिडेशन के बिना गलत डेटा आपके सिस्टम में घुस जाता है। आपका बैकएंड क्रैश हो सकता है। आपकी ईमेल सर्विस मैसेज रिजेक्ट कर देती है। गंदे डेटा को साफ़ करने में आपका समय बर्बाद होता है।

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

क्लाइंट-साइड वैलिडेशन

ब्राउज़र डेटा भेजने से पहले उसे जांच सकता है। HTML में वैलिडेशन के लिए बने-बनाए एट्रिब्यूट होते हैं। JavaScript से भी वैलिडेशन किया जा सकता है।

HTML वैलिडेशन

<input type="email" required> जांचता है कि फ़ील्ड में वैल्यू है और वह ईमेल जैसी दिखती है। अगर यूज़र गलत फ़ॉर्म सबमिट करने की कोशिश करे, तो ब्राउज़र एरर मैसेज दिखाता है।

HTML वैलिडेशन के एट्रिब्यूट ये हैं: required, जिससे फ़ील्ड में वैल्यू होना ज़रूरी हो जाता है; नंबर के लिए min/max, जो वैल्यू को एक दायरे में रखता है; minlength/maxlength, जो अक्षरों की गिनती तय करता है; pattern, जो रेगुलर एक्सप्रेशन से मिलान करता है; और type, जो फ़ील्ड का टाइप जांचता है। जैसे, type="email" फ़ॉर्मैट जांचता है, जबकि type="number" नंबर के अलावा कुछ भी स्वीकार नहीं करता।

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

JavaScript वैलिडेशन

ज़्यादा कंट्रोल चाहिए तो JavaScript से वैलिडेशन करें, जैसे function validateEmail(email) { const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return regex.test(email); } और form.addEventListener('submit', (e) => { if (!validateEmail(input.value)) { e.preventDefault(); showError('Please enter a valid email'); } });। JavaScript वैलिडेशन से आप अपने नियम लिख सकते हैं, अपने एरर मैसेज दिखा सकते हैं, और यूज़र के टाइप करते समय फ़ील्ड जांच सकते हैं, यानी रियल-टाइम वैलिडेशन। इसकी कमियां ये हैं कि इसके लिए JavaScript चलना ज़रूरी है (सुरक्षा के लिए यह भरोसेमंद नहीं), मेंटेन करने के लिए ज़्यादा कोड चाहिए, और अगर आप input इवेंट पर वैलिडेट करें तो यूज़र के टाइप खत्म करने से पहले ही एरर दिख सकता है।

सर्वर-साइड वैलिडेशन

फ़ॉर्म सबमिट होने के बाद सर्वर डेटा को दोबारा जांचता है। असली सुरक्षा यहीं होती है।

क्लाइंट-साइड वैलिडेशन पर कभी भरोसा न करें। कोई JavaScript बंद कर सकता है। कोई रिक्वेस्ट को बीच में पकड़कर डेटा बदल सकता है। कोई curl या किसी टूल से आपके फ़ॉर्म से गुज़रे बिना ही गलत डेटा भेज सकता है।

सर्वर-साइड वैलिडेशन ही आपकी एकमात्र सुरक्षा है। यह वैकल्पिक नहीं है।

जब सर्वर को फ़ॉर्म सबमिशन मिले, तो ये जांचें: ज़रूरी फ़ील्ड मौजूद हैं, ईमेल, फ़ोन और URL का फ़ॉर्मैट सही है, नंबर अपेक्षित दायरे में हैं, अपलोड की गई फ़ाइलों का टाइप और साइज़ सही है, डेटा की लंबाई ज़्यादा नहीं है, और इंजेक्शन अटैक रोकने के लिए डेटा सैनिटाइज़ किया गया है। अगर वैलिडेशन फ़ेल हो, तो एरर रिस्पॉन्स भेजें ताकि फ़ॉर्म प्रोसेस न हो और यूज़र को बताया जाए कि क्या गलत है। सर्वर-साइड वैलिडेशन धीमा होता है क्योंकि यूज़र को जवाब का इंतज़ार करना पड़ता है, लेकिन यह भरोसेमंद और सुरक्षित है, इसलिए इसे हमेशा करें।

कौन-सा वैलिडेशन कब इस्तेमाल करें

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

सर्वर-साइड वैलिडेशन डेटा की सही स्थिति और सुरक्षा के लिए है। यह पक्का करता है कि गलत डेटा आपके सिस्टम में कभी न आए।

दोनों इस्तेमाल करें। क्लाइंट-साइड तेज़ी और फ़ीडबैक के लिए। सर्वर-साइड सुरक्षा के लिए।

वैलिडेशन की आम गलतियां

सिर्फ़ क्लाइंट-साइड वैलिडेशन करना

कोई JavaScript बंद कर दे तो आपका वैलिडेशन खत्म हो जाता है। कोई curl से गलत डेटा POST करे तो आपका वैलिडेशन चलता ही नहीं। आपके डेटाबेस में कचरा जमा हो जाता है।

वैलिडेशन हमेशा सर्वर पर करें। क्लाइंट-साइड सिर्फ़ अतिरिक्त है।

वैलिडेशन बहुत सख्त रखना

आपका ईमेल वैलिडेशन इतना सख्त है कि असली ईमेल भी फ़ेल हो जाते हैं। आपका फ़ोन वैलिडेशन सिर्फ़ US फ़ॉर्मैट मानता है और इंटरनेशनल नंबर रिजेक्ट कर देता है। आपका नाम फ़ील्ड हाइफ़न, एपॉस्ट्रॉफ़ी और दूसरे सही अक्षर रिजेक्ट कर देता है।

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

साफ़ एरर मैसेज न दिखाना

"Invalid input." क्या गलत है? कौन-सा फ़ील्ड? यूज़र क्या करे?

एरर मैसेज साफ़ होने चाहिए: "Email must be between 5 and 254 characters." "Phone must be 10 digits." "Password must contain at least one number."

एरर उसी फ़ील्ड के पास दिखाएं जिसकी वजह से वह आया है। एरर को किसी लिस्ट में न छिपाएं जहां यूज़र को उन्हें ढूंढना पड़े।

संवेदनशील डेटा को क्लाइंट पर वैलिडेट करना

क्रेडिट कार्ड नंबर या पासवर्ड को क्लाइंट-साइड वैलिडेशन से न गुज़ारें। उन्हें ब्राउज़र कंसोल में न दिखाएं। उन्हें लॉग न करें।

संवेदनशील डेटा सिर्फ़ सर्वर पर, HTTPS के ज़रिए वैलिडेट करें।

फ़ाइल अपलोड वैलिडेट न करना

कोई 100 मेगाबाइट की फ़ाइल अपलोड करता है। आपके सर्वर की स्टोरेज भर जाती है। कोई एक्ज़ीक्यूटेबल फ़ाइल अपलोड करता है। आपके सर्वर में वायरस आ जाता है।

फ़ाइल का टाइप और साइज़ सर्वर पर वैलिडेट करें। जांचें कि फ़ाइल सच में वही टाइप है जो वह बताती है। सिर्फ़ फ़ाइल एक्सटेंशन या MIME टाइप पर भरोसा न करें।

रियल-टाइम वैलिडेशन बनाम सबमिट-टाइम वैलिडेशन

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

कमी: अगर आप एरर बहुत जल्दी दिखाएंगे, तो यूज़र झुंझला जाएगा। एरर तभी दिखाएं जब यूज़र फ़ील्ड छोड़ दे (blur इवेंट पर), टाइप करते समय नहीं।

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

कमी: यूज़र को सबमिट करने के बाद वापस जाकर एरर ठीक करने पड़ते हैं। इससे उसका फ़्लो टूट जाता है।

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

अलग-अलग फ़ील्ड टाइप के लिए वैलिडेशन

ईमेल वैलिडेशन

पूरा ईमेल वैलिडेशन जटिल है (RFC 5322 साठ पेज का है), इसलिए ज़्यादातर मामलों में बस जांचें कि वैल्यू में @ और डोमेन है, जैसे const email = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;। इससे ज़्यादातर गलत ईमेल पकड़े जाते हैं और इतनी सख्ती भी नहीं होती कि असली ईमेल फ़ेल हो जाएं।

फ़ोन वैलिडेशन

फ़ोन का फ़ॉर्मैट देश के हिसाब से बदलता है। US फ़ॉर्मैट (123) 456-7890 है, UK फ़ॉर्मैट +44 20 7946 0958 है, और जर्मनी में +49 30 123456 चलता है। इंटरनेशनल फ़ॉर्मैट स्वीकार करें, सर्वर पर नंबर के अलावा बाकी अक्षर हटा दें, और फ़ोन को नंबर की जगह स्ट्रिंग के रूप में स्टोर करें ताकि कुछ देशों के नंबरों में शुरू के ज़ीरो बने रहें।

पासवर्ड वैलिडेशन

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

तारीख वैलिडेशन

ज़रूरत के हिसाब से जांचें कि तारीख भविष्य की है या अतीत की। इवेंट रजिस्ट्रेशन फ़ॉर्म को पिछली तारीखें रिजेक्ट करनी चाहिए। जन्मतिथि के फ़ॉर्म को भविष्य की तारीखें रिजेक्ट करनी चाहिए।

WEMASY में फ़ॉर्म वैलिडेशन

ऊपर के सुझावों को अपने फ़ॉर्म पर लागू करें, ताकि यूज़र को तुरंत फ़ीडबैक मिले और आपका डेटा सही रहे।

WEMASY के प्लान देखें।

अक्सर पूछे जाने वाले सवाल