डेटा इनपुट सत्यापन - कहां? कितना? [बन्द है]

Question

डेटा इनपुट सत्यापन हमेशा मेरे लिए काफी आंतरिक संघर्ष था।

एक वास्तविक सुरक्षा ढांचे और कोड को हमारे विरासत अनुप्रयोग को फिर से लिखने की परियोजना के कगार पर (जो अब तक बहुत ज्यादा कार्ड-महल-मजबूत विरासत सुरक्षा कोड और डेटा सत्यापन रखता है), मैं फिर से सोच रहा हूं कि मुझे कितना मान्य करना चाहिए, कहाँ, आदि

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

संक्षेप में, ये मेरे दिशा-निर्देश हैं (3-स्तरीय वेब एप्लिकेशन शैली पर) संक्षिप्त विवरण के साथ:

• 1 स्तरीय ग्राहक पक्ष (ब्राउज़र): न्यूनतम सत्यापन, केवल अपरिवर्तनीय नियम (अनिवार्य ईमेल फ़ील्ड, एक आइटम और इस तरह का चयन करना होगा); अतिरिक्त सत्यापन का उपयोग जैसे "6 और 20 वर्णों के बीच" कम लगातार, क्योंकि इससे परिवर्तनों पर रखरखाव का काम बढ़ता है (व्यापार कोड स्थिर होने पर जोड़ा जा सकता है);

• 1 टियर सर्वर साइड (वेब ​​कम्युनिकेशन हैंडलिंग, "कंट्रोलर"): मेरे पास इसके लिए कोई नियम नहीं है, लेकिन मेरा मानना ​​है कि केवल डेटा हेरफेर और असेंबली / पार्सिंग त्रुटियों को यहां संभाला जाना चाहिए (जन्मदिन का क्षेत्र एक वैध तारीख नहीं है); यहाँ आगे सत्यापन को जोड़ना आसानी से एक उबाऊ प्रक्रिया है;

• 2 टीयर (व्यावसायिक परत): रॉक सॉलिड वेलिडेशन, कम नहीं; इनपुट डेटा फॉर्मेट, रेंज, वैल्यूज़, इंटरनल स्टेट चेकिंग अगर मेथड को कभी भी कॉल नहीं किया जा सकता है, तो यूजर रोल्स / परमिशन, इत्यादि; जितना संभव हो उतना कम उपयोगकर्ता इनपुट डेटा का उपयोग करें, यदि आवश्यक हो तो इसे डेटाबेस से फिर से प्राप्त करें; अगर हम पुनर्प्राप्त डेटाबेस डेटा को इनपुट के रूप में भी मानते हैं, तो मैं केवल इसे मान्य करूंगा यदि कुछ विशिष्ट डेटा को DB पर अविश्वसनीय या भ्रष्ट माना जाता है - मजबूत टाइपिंग यहां अधिकांश काम करता है, IMHO;

• 3 टीयर (डेटा लेयर / DAL / DAO): कभी नहीं माना जाता है कि यहाँ पर बहुत अधिक सत्यापन की आवश्यकता नहीं है, क्योंकि डेटा तक पहुँचने के लिए केवल व्यवसायिक लेयर को माना जाता है (शायद कुछ मामले जैसे "param2 null नहीं होना चाहिए अगर param1 सत्य है); हालाँकि, जब मेरा मतलब है कि "यहाँ" मेरा मतलब है "कोड" जो डेटाबेस तक पहुँच "या" SQL- निष्पादन विधियों ", डेटाबेस ही पूरी तरह से विपरीत है;

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

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

तो आप इस बारे मे क्या सोचते हैं? विपरीत राय? क्या आपके पास अन्य प्रक्रियाएं हैं? ऐसे विषय का संदर्भ? कोई भी योगदान मान्य है।

नोट: यदि आप चीजों को करने के जावा तरीके के बारे में सोच रहे हैं, तो हमारा ऐप स्प्रिंग स्प्रिंग एमवीसी और मायबैटिस के साथ आधारित है (प्रदर्शन और खराब डेटाबेस मॉडल ओआरएम समाधानों से शासन करता है); मैं हमारे सुरक्षा प्रदाता प्लस JSR 303 (हाइबरनेट वैलिडेटर) के रूप में स्प्रिंग सिक्योरिटी को जोड़ने की योजना बना रहा हूं?

धन्यवाद!

---

संपादित करें: 3 परत पर कुछ अतिरिक्त स्पष्टीकरण।

Comments

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

— विनीत रेनॉल्ड्स

@ विनीत रेनॉल्ड्स मैंने इसे पहले ही स्प्रिंग एमवीसी के साथ फॉर्म सत्यापन के लिए इस्तेमाल किया था, यह वास्तव में बहुत अच्छा संयोजन है। मुझे बिना किसी प्रयास के, ठीक-ठाक संदेशों के साथ सर्वर साइड सत्यापन मिल जाता है, जो उपयोगकर्ता को दिखाई गई उचित त्रुटि है। मैं अभी भी पूरी तरह से सर्वर साइड वस्तुओं पर इसका परीक्षण कर रहा हूं, फायदे के बारे में निश्चित नहीं। इस नमूना पोस्ट पर एक नज़र डालें, बस इतना ही मैंने इसे कैसे इस्तेमाल किया: codemunchies.com/2010/07/…

— mdrg

डाल बहुत ज्यादा मान्यता। हर कोई लानत है उन उपयोगकर्ता इनपुट @ # पर! ! @@!

— चानी

Answer 1

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

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

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

Comments

+1 बिल्कुल। मैं ASP.NET MVC के बारे में भी यही बात कहने जा रहा था, लेकिन आपने मुझे हरा दिया। :) वास्तव में, हमने यह सुनिश्चित करने के लिए कि किसी सिस्टम को एक वैध स्थिति में रखा है, केवल उसी स्थान पर सत्यापन की आवश्यकता है। क्लाइंट की तरह सत्यापन के बाकी उपयोगकर्ता के लिए प्रयोज्य और समय को बढ़ाने के लिए कर रहे हैं, ताकि मुख्य ध्यान केंद्रित किया जाना चाहिए। संगति प्रमुख है।

— रयान हेस

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

— mdrg

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

— mdrg

Answer 2

एक संबंधपरक प्रणाली में, मैं इसे तीन-स्तरीय दृष्टिकोण के रूप में देखता हूं। प्रत्येक परत नीचे वालों द्वारा विवश है:

• प्रस्तुति / यूआई
  • सरल इनपुट सत्यापन
  • यदि इनपुट गलत प्रारूप में है तो आगे न बढ़ें
  • "गेट" क्लाइंट बेहतर प्रयोज्य और कम बैंडविड्थ / समय के लिए सर्वर को राउंड-ट्रिप को कम करने का अनुरोध करता है
• तर्क
  • व्यापार तर्क और प्राधिकरण
  • उपयोगकर्ताओं को वे काम न करने दें जो उन्हें करने की अनुमति नहीं है
  • यहां "व्युत्पन्न" गुण और स्थिति को संभालें (वे चीजें जो डेटाबेस में निरूपित की जाएंगी)
• डेटा
  • आवश्यक डेटा अखंडता परत
  • किसी भी कबाड़ को स्टोर करने से बिल्कुल मना करें
  • DB स्वयं डेटा प्रारूप (उदाहरण, दिनांक, आदि) लागू करता है
  • उचित संबंधों को सुनिश्चित करने के लिए डेटाबेस बाधाओं का उपयोग करें

इसका आदर्श उत्तर एक ऐसी प्रणाली होगी जो आपको एक ही स्थान पर सभी तीन परतों में बाधाओं को परिभाषित करने देती है। इसमें SQL के लिए कुछ कोड जनरेशन और क्लाइंट और सर्वर के लिए कम से कम कुछ डेटा-चालित सत्यापन शामिल होंगे।

मुझे नहीं पता कि यहां कोई सिल्वर बुलेट है ... लेकिन जब से आप जेवीएम पर हैं, मैं सुझाव दूंगा कि राइनो को कम से कम क्लाइंट और सर्वर के बीच जावास्क्रिप्ट सत्यापन कोड साझा करें। अपना इनपुट सत्यापन दो बार न लिखें।

Comments

मैं राइनो पर एक नज़र डालूंगा। यदि यह स्प्रिंग एमवीसी फॉर्म सत्यापन के साथ किसी तरह एकीकृत कर सकता है, तो बहुत बेहतर है।

— mdrg

Answer 3

• तीसरा स्तर (डेटा लेयर / DAL / DAO): कभी नहीं माना जाता है कि यहाँ पर बहुत अधिक सत्यापन की आवश्यकता नहीं है, क्योंकि केवल व्यवसायिक परत को डेटा तक पहुँचने की अनुमति है (कुछ मामलों पर मान्य हो सकता है जैसे "param2 null नहीं होना चाहिए यदि param1 सत्य है") ।

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

वह कहता है कि मैं इससे बेहतर हूं: http://softarch.97things.oreilly.com/wiki/index.php/Database_as_a_Fortress

Comments

मैं इस लेख के साथ बहुत अंतिम सा सहमत हूं, मुझे लगता है कि मैंने इस भाग में खुद को स्पष्ट नहीं किया है। मैंने आगे के विवरण के साथ प्रश्न को अद्यतन किया। धन्यवाद!

— mdrg

Answer 4

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

यकीन है, बहुत अधिक सत्यापन एक बुरी बात है, लेकिन प्रोग्राम, नेटवर्क और ओएस सही हैं, हैकर्स को आपके फ़ायरवॉल के माध्यम से नहीं मिलेगा, एक डीबीए मैन्युअल रूप से "ट्वीक" नहीं करेगा डेटाबेस संभवतः बदतर है।

चीजों के चारों ओर सीमा वृत्त बनाएं, उस विफलता मोड की पहचान करें जो उसके विरुद्ध सुरक्षा कर रहा है और उस सीमा के लिए उपयुक्त स्तर की जाँच को कार्यान्वित करता है। उदाहरण के लिए, आपके डेटाबेस को कभी भी अमान्य डेटा नहीं देखना चाहिए, लेकिन यह कैसे हो सकता है और यदि यह होता है तो क्या होगा? आपका उपयोगकर्ता कौन है, विफलता की लागत क्या है?

भौतिक विश्व सुरक्षा मॉडल का अध्ययन करें, सुरक्षा एक प्याज की तरह परतों में होनी चाहिए। एक मोटी दीवार को खराब सुरक्षा माना जाता है। डेटा सत्यापन को उसी तरह माना जाना चाहिए।

Answer 5

सत्यापन के लिए दो छोटे, सामान्य नियम:

यदि आप ऐसी किसी भी चीज़ को कॉल करने जा रहे हैं जो इसकी गारंटी नहीं देती है तो आपको अमान्य इनपुट के बारे में बताने के लिए कुछ (त्रुटि, अपवाद) वापस आ जाएगी, जिसे आप अपने कॉलर को वापस भेज सकते हैं, इसे सत्यापित कर सकते हैं।

यदि आप डेटा के साथ कुछ और करने जा रहे हैं (निर्णय लें, गणित करें, इसे संग्रहीत करें, आदि), तो इसे सत्यापित करें।