क्या क्लाइंट-साइड जावास्क्रिप्ट से सीधे डेटाबेस में जाने का कोई कारण नहीं है?


62

संभव डुप्लिकेट:
लेखन वेब "सर्वर कम" अनुप्रयोग

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

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

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

संपादित करें: बहुत बढ़िया चर्चा अब तक, और मैं हर किसी की प्रतिक्रिया की सराहना करता हूं! मुझे ऐसा लगता है कि मुझे CouchDB और AngularJS को विशेष रूप से कॉल करने के बजाय कुछ सामान्य मान्यताओं को जोड़ना चाहिए। तो चलिए मान लेते हैं कि:

  • डेटाबेस उपयोगकर्ताओं को सीधे अपने छिपे हुए स्टोर से प्रमाणित कर सकता है
  • सभी डेटाबेस संचार SSL पर होगा
  • डेटा सत्यापन डेटाबेस द्वारा नियंत्रित किया जा सकता है (लेकिन शायद नहीं करना चाहिए?)
  • एकमात्र प्राधिकरण जिसे हम व्यवस्थापक कार्यों के अलावा अन्य के बारे में परवाह करते हैं, किसी को केवल अपने स्वयं के पोस्ट को संपादित करने की अनुमति दी जा रही है
  • हम सभी डेटा को पढ़ने में सक्षम होने के साथ पूरी तरह से ठीक हैं (EXCEPT उपयोगकर्ता रिकॉर्ड जिसमें पासवर्ड हैश हो सकते हैं)
  • डेटाबेस प्राधिकरण द्वारा प्रशासनिक कार्यों को प्रतिबंधित किया जाएगा
  • कोई भी खुद को व्यवस्थापक की भूमिका में नहीं जोड़ सकता है
  • डेटाबेस को स्केल करना अपेक्षाकृत आसान है
  • कोई भी सच्चा व्यावसायिक तर्क नहीं है; यह एक बुनियादी CRUD ऐप है

डेटाबेस के लिए बिल्कुल शुद्ध "ग्राहक पक्ष" नहीं है, लेकिन क्या आपने पार्स और फायरबेस को देखा है? (और कुछ स्तर पर उल्का भी), उन सभी में कुछ प्रासंगिक अवधारणाएं हैं, और सभी रचनात्मक तरीकों से सुरक्षा संभालते हैं। : जैसे यह देखने blog.firebase.com/post/38234264120/...
Eran मेडन

हाँ! मैं पार्स से पहले सुना था, लेकिन नहीं Firebase। बहुत दिलचस्प है, और निश्चित रूप से मैं क्या सोच रहा था की तर्ज पर।
क्रिस स्मिथ

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

6
बाकी सब को अनदेखा करते हुए, आप एक 2 स्तरीय एप्लिकेशन बना रहे हैं, जो डेटाबेस में आपके UI को कसकर जोड़े हुए है। जब तक आपका ऐप तुच्छ न हो, वास्तव में एक अच्छा विचार नहीं है।
एंडी

12
SSL किसी को चलने से नहीं रोकेगाDELETE FROM ImportantData;
user253751

जवाबों:


48

जैसा कि आप सुझाव देते हैं, अपने ग्राहक पक्ष भाषा और आपके डेटाबेस के बीच एक तंग (एर) युग्मन बनाता है।

यह ठीक हो सकता है - लिखने और बनाए रखने के लिए कम कोड है, और सिद्धांत में डीबगिंग थोड़ा तेज हो सकता है / जाना चाहिए।

दूसरी ओर, यह अन्य पहलुओं को और अधिक कठिन बना देता है। यदि / जब आपको उन तकनीकों में से किसी को बदलने की आवश्यकता होती है, तो आपके बीच कठिन युग्मन के कारण आपके पास कठिन समय होगा।

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

मैं इसकी सिफारिश नहीं करूंगा, और बहुत से आपको नहीं बताएंगे। लेकिन यह किया जा सकता है।


दिलचस्प। एक हमलावर मेरे प्रमाणीकरण तंत्र को कैसे उधार ले सकता है? मैं ग्राहक को प्रमाणित करने के लिए भरोसा नहीं करूंगा। डेटाबेस बस एक HTTPS POST को सत्र के समापन बिंदु तक ले जाएगा जो POSTed पासवर्ड हैश करेगा और जांच करेगा कि यह मान्य है। यदि यह है, तो यह भविष्य के अनुरोधों में उपयोग किए जाने वाले सत्र कुकी लौटाएगा।
क्रिस स्मिथ

1
मुझे केवल सत्र कुकी की आवश्यकता है, है ना? मैं आपके ग्राहक का उपयोग करने और मेरे सत्र कुकी प्राप्त करने के लिए करता हूं। फिर मैं अपने ग्राहक के साथ सत्र कुकी चोरी करता हूं और बुरी तरह से स्वरूपित अनुरोधों को कहर का कारण बनता हूं । याद रखें कि यह सब मेरी मशीन पर है, इसलिए मुझे MiTM हमले की भी आवश्यकता नहीं है।

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

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

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

36

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

यदि आपको समर्थन साक्ष्य की आवश्यकता है, तो बहुत सारी चिंताएं हैं - सभी दुर्गम नहीं, लेकिन सोचने के लिए बहुत कुछ। कोई विशेष क्रम में, यहाँ कुछ हैं:

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

... और मुझे यकीन है कि अन्य चिंताएं भी हैं। और मुझे यकीन है कि इनमें से अधिकांश का समाधान है - यदि इन सभी चिंताओं का नहीं। लेकिन, आपको शुरू करने के लिए एक सूची है!


1
यहाँ सोचा के लिए कुछ महान भोजन। ये सभी बिंदु हर स्थिति में लागू नहीं होंगे और समान रूप से महत्वपूर्ण होंगे लेकिन एक संक्षिप्त बुलेट बिंदु सूची है जो गियर प्राप्त करता है, यह बहुत अच्छा है। धन्यवाद!
डेव

16

सबसे अच्छा एकल कारण जिसकी मैं कल्पना कर सकता हूं: क्योंकि यह विधि किसी भी शामिल पार्टी द्वारा सीधे समर्थित या अनुशंसित नहीं है।

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

मैं यह नहीं कह रहा हूं कि यह संभव नहीं है। मैं सिर्फ यह कह रहा हूं कि यह "पहिए का फिर से आविष्कार" की तरह कम है और ब्राउज़र-आधारित क्लाइंट-सर्वर इंटरैक्शन को फिर से आविष्कार करने जैसा है।

सबसे अच्छी तरह से, आप सिस्टम को सबसे बुनियादी संभव स्तर पर काम करने के लिए एक टन का काम कर रहे होंगे। आधुनिक लोकप्रिय डेटाबेस Restful या HTTP पर काम करने के लिए निर्मित नहीं हैं, इसलिए आप अपने खुद के WebSocket- आधारित (मैं ग्राहक क्लाइंट) का निर्माण करूंगा।

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

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

डेटाबेस स्केलेबिलिटी बड़े पैमाने पर काम करने में सबसे कठिन समस्याओं में से एक है, जबकि कई HTTP सर्वरों को स्केल करना - विशेष रूप से स्थिर या कैश्ड पृष्ठों के साथ - सबसे आसान भागों में से एक है। आपका प्रस्ताव मूल रूप से सर्वर-साइड गतिविधि के 100% के लिए जिम्मेदार होने से डेटाबेस को अधिक काम करता है। यह अपने आप में एक हत्यारा दोष है। डेटाबेस पर अधिक काम करने से आपके द्वारा खोए गए क्लाइंट पर काम करने से आपको क्या लाभ होता है।

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

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


8

चूँकि यह मूल रूप से एक CRUD एप्लीकेशन है और व्यापारिक तर्क में "केवल लेखक ही अपने पद को संपादित कर सकते हैं" मैं क्लाइंट-साइड सामान और डेटाबेस के बीच एक परत होने की ज्यादा जरूरत नहीं देखता। मैं बस CouchDB पक्ष पर सत्यापन का उपयोग करूँगा यह सुनिश्चित करने के लिए कि कोई व्यक्ति कचरा डेटा में नहीं डाल रहा है और सुनिश्चित करें कि अनुमतियाँ ठीक से सेट की गई हैं ताकि उपयोगकर्ता केवल अपना स्वयं का _user डेटा पढ़ सकें।

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

डेटाबेस के साथ सीधे संवाद करने वाले क्लाइंट इनपुट की क्षमता प्रदान करना डेटा को खराब करने की बहुत बड़ी क्षमता है

इसका मतलब यह भी है कि तंग युग्मन से बचने / हटाने से आपके सॉफ्टवेयर सिस्टम को अधिक टिकाऊ और ठोस बनाया जा सकता है।


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

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

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

नहीं, मुझे ऐसा नहीं लगता। DB में आपके सत्यापन और प्राधिकरण तर्क को रखने से आपके सिस्टम पर प्रदर्शन हिट होने वाला है, एक बार रिकॉर्ड संख्या बढ़ने लगती है और आपको अपने सिस्टम पर अधिक उपयोगकर्ता मिलते हैं।
ईएल यूसुबोव

DB इंजन डेटा को स्टोर करने और पुनः प्राप्त करने के लिए होते हैं, न कि इसे हेरफेर करने या मान्य करने के लिए। बेशक आप इसे अपने तरीके से कर सकते हैं, लेकिन यह पालन करने का कुशल तरीका नहीं है।
ईएल युसुबोव

6

उपयोगकर्ता को डेटाबेस से सीधे संवाद करने देना वास्तव में मेरे लिए खतरनाक लगता है।

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

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


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

6

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

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

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

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

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

और यह एक वास्तविक शर्म की बात होगी, क्योंकि हमारे पास पहले से ही उस स्थान का एक नाम है जहां आपने अपना आवेदन तर्क रखा है, और इसे "डेटाबेस के लिए संग्रहीत प्रक्रियाओं" के बजाय "आपके आवेदन के स्रोत कोड" कहा जाता है।


5

यदि आपकी सुरक्षा जांच और व्यावसायिक तर्क आपके क्लाइंट साइड जावास्क्रिप्ट में समाहित हैं, तो उन्हें दुर्भावनापूर्ण उपयोगकर्ता द्वारा ओवरराइड किया जा सकता है। एक विकल्प के रूप में, आप सत्यापन, प्राधिकरण और इसी तरह संभालने के लिए जावास्क्रिप्ट आधारित सर्वर-साइड तकनीक (जैसे नोड.जेएस ) का लाभ उठा सकते हैं।


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

2

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

अपने stackoverflow क्लोन उदाहरण के बाद:

  • वैसे भी संपादित किए जाने से आप साइट पर "बंद" प्रश्नों को कैसे रोकेंगे?
  • आप लोगों को टिप्पणियों को हटाने से कैसे रोकेंगे?
  • आप लोगों को टिप्पणी की तारीखों को रोकने से कैसे रोकेंगे?
  • आप एक ही पोस्ट से 50 बार लोगों को कैसे रोकेंगे?
  • यदि आप थोड़ा और खोदते हैं तो शायद बहुत अधिक उदाहरण हैं।

कोई भी ग्राहक पक्ष कोड में हेरफेर कर सकता है और डेटा अखंडता का पूरी तरह से उल्लंघन कर सकता है (भले ही कुछ वस्तुओं तक सीमित हो, जैसे कि उनके स्वयं के पोस्ट)।


1

पेज को फायरबग में संपादित करें और कुछ बिंदु पर इसके समान एक रेखा डालें:

ExecDbCommand("DROP TABLE Users")

चलाओ।

संपादित करें:

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

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


CouchDB पता नहीं है कि उस के साथ क्या करना है, लेकिन मुझे आपकी बात मिल गई। यदि अनुमतियाँ ठीक से सेट की गई हैं, तो ऐसी चीज़ की प्रतिक्रिया 401 अनधिकृत होगी।
क्रिस स्मिथ

-1, जब आप SQL कोड पोस्ट करते हैं तो आपको स्पष्ट रूप से पता नहीं चलता है कि CouchDB क्या है। इसके अलावा, बस काउचडी पर एक व्यवस्थापक खाता बनाकर आप पहले से ही किसी अन्य उपयोगकर्ता को सबसे खतरनाक संचालन करने से रोकते हैं।
फिलिपिंस

काफी उचित। मैंने प्रश्न में CouchDB पर भाग छोड़ दिया और केवल इसे "ग्राहक पक्ष JS से सीधे डेटा स्टोर" के रूप में पंजीकृत किया। मैं प्रतिक्रिया संपादित करूंगा।
एज़ ०१

1
+1, SQL या नहीं, उसकी बात अभी भी कायम है। एक जेएस डिबगर का उपयोग यह बदलने के लिए किया जा सकता है कि डेटा कैसे एक्सेस किया जाता है।
ग्रैंडमास्टरबी

1

पुराना सवाल, मुझे पता है, लेकिन मैं झंकार करना चाहता था क्योंकि मेरा अनुभव अन्य प्रतिक्रियाओं से काफी अलग है।

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

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

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

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

मैं वर्तमान में CouchDB का उपयोग कर एक प्रणाली का निर्माण कर रहा हूं जहां उपयोगकर्ताओं को डेटा को एक QA / QC वर्कफ़्लो के माध्यम से "डेटा" प्रकाशित करने के लिए सहयोग करने की आवश्यकता है। सहयोग डेटा की प्रतिकृति पर किया जाता है (हम इसे एक स्टेजिंग या वर्किंग डेटाबेस कहते हैं), और एक बार पूरा होने पर, एक जिम्मेदार व्यक्ति डेटा पर क्यूए / क्यूसी करता है और उसके बाद ही इसे मुख्य रिपॉजिटरी में वापस दोहराया जाता है।

कई लाभ इस से प्रवाहित होते हैं जो अन्य प्रणालियों में प्राप्त करना कठिन है - जैसे कि पारंपरिक तीन स्तरीय CRUD अनुप्रयोगों के लिए संस्करण नियंत्रण, प्रतिकृति और सहयोग (ऑफ़लाइन काम करने दें!) सुपर कठिन है।

मेरी सलाह - यदि आपका आवेदन "पारंपरिक" है, तो इसे पारंपरिक तरीके से करें। अगर मेरे द्वारा ऊपर बताई गई कोई भी बात (हालाँकि बहुत अधिक है ...) आप पर लागू होती है तो वैकल्पिक आर्किटेक्चर पर विचार करें और बाद में सोचने के लिए तैयार रहें।


0

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

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

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

लेकिन मैं निश्चित रूप से यह देख सकता था कि आज के बाद के कम जोखिम वाले हिस्सों के लाभ के लिए ऐसा करना जोखिम का कारण हो सकता है।


अच्छी बात। यह निश्चित रूप से एक संकीर्ण उपयोग-मामला है, इसलिए यह ऐसा कुछ नहीं है जिसे आप किसी भी एप्लिकेशन पर लागू कर सकते हैं।
क्रिस स्मिथ

0

बॉक्स प्रश्न के बाहर के लिए सबसे पहले धन्यवाद .... :)

लेकिन जो मैं सुझाऊंगा वह है; हमेशा अपनी 3 परतों के बीच अलगाव बनाए रखने की कोशिश करें। जो प्रेजेंटेशन / बिज़नेस और डेटाबेस या डीएओ हैं क्योंकि यह उन प्रकार की आवश्यकताओं और सेटअपों में सबसे अच्छा अभ्यास होगा जहां हर दिन बहुत सारे बदलाव होंगे।

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

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

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

धन्यवाद


0

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

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

यदि आप जटिल सुरक्षा परीक्षण करते हैं तो यह एक सुरक्षित समाधान हो सकता है। जेएसएफ जैसे फ्रेमवर्क का उपयोग करते समय यह और भी आसान हो सकता है, जो अक्सर पीछे पढ़ने योग्य एपीआई का उपयोग कर रहे हैं। अस्पष्टता से सुरक्षा को कोई समाधान नहीं माना जाता है।

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


0

मुझे दो समस्याएं दिखाई देती हैं:

1. टाइट कपलिंग: अपना DB विकल्प बदलें? ठीक है, अब आप अपने सभी क्लाइंट-साइड कोड भी बदल सकते हैं। मुझ पर विश्वास करो। हमें क्लाइंट-साइड पर अधिक समस्याओं की आवश्यकता नहीं है।

2. TMI सुरक्षा समस्या: सामान कैसे काम करता है, इसके बारे में बहुत कुछ बताता है। प्रामाणिक अभी भी एक बाधा हो सकती है लेकिन एक शोषण खोजना बहुत आसान का एक नर्क है जब आपको पता है कि सर्वर-साइड पर वास्तव में क्या हो रहा है।

एक बहुत-बहुत पतली मध्य-स्तरीय एक बेहतर तरीका हो सकता है।


-1

यदि जावास्क्रिप्ट केवल डेटाबेस-एक्सेस-लेयर है तो जावास्क्रिप्ट को अक्षम किया गया है (या उसके डिवाइस के ब्राउज़र पर समर्थित नहीं है) तो आपका क्लाइंट आपके वेब ऐप का उपयोग नहीं कर सकता है।


2
एह, इस बारे में बहुत चिंतित नहीं हैं। अधिकांश वेब अब वैसे भी जावास्क्रिप्ट पर निर्भर करते हैं। मुझे बस <noscript> टैग्स को तोड़ना होगा और उन्हें बताना होगा कि क्या उन्हें मेरी साइट (और वहाँ से 80% लोग चाहते हैं) काम करने के लिए इसे चालू करना होगा।
क्रिस स्मिथ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.