लगभग 10 वर्षों तक मैंने SQL सर्वर डेटा स्टोर के साथ विभिन्न इन-हाउस डेस्कटॉप क्लाइंट एप्लिकेशन पर काम किया है। शायद ही मैंने इन परियोजनाओं को शुरू किया था - अधिकांश अधिग्रहण कार्य हैं।
एक चीज जो हर जगह लगातार लगती थी, वह यह थी कि एक एकल वैश्विक SQL सर्वर उपयोगकर्ता खाता था जो इस एप्लिकेशन का उपयोग करता था जो इसे सामान्य डेटाबेस को अनुमति देता था, और हाँ कुछ भोली स्थितियों में यह saउपयोगकर्ता खाते का उपयोग करता था , जिसे मैं आमतौर पर संभव होने पर ठीक करने की कोशिश करता था ।
आप वास्तव में इस उपयोगकर्ता नाम और पासवर्ड को प्रभावी ढंग से छिपा नहीं सकते हैं जो एप्लिकेशन डेटाबेस तक पहुंचने के लिए उपयोग करता है। वे आमतौर पर एक iniया configफ़ाइल में संग्रहीत होते हैं , या संभवतः निष्पादन योग्य में बेक किए जाते हैं। सभी मामलों में, यदि वे थोड़ा खुदाई करते हैं, तो वे उपयोगकर्ता को दिखाई देते हैं। एक मामले में हमने वास्तव में एक configफ़ाइल का उपयोग किया था लेकिन इसे एन्क्रिप्ट किया था, लेकिन निश्चित रूप से एन्क्रिप्शन कुंजी को निष्पादन योग्य में संग्रहीत किया जाना था (हम इस की सीमाओं के लिए भोले नहीं थे, लेकिन इसने प्रभावी रूप से उन लोगों को रोकना बंद कर दिया, जो काफी समझदार थे configफाइलों में देखना )।
इन सभी प्रणालियों में एक उपयोगकर्ता-प्रमाणीकरण प्रणाली थी जिसे एप्लिकेशन में बनाया गया था, लेकिन निश्चित रूप से वे सभी एप्लिकेशन के माध्यम से प्रबंधित किए गए थे, जिसका अर्थ है कि उपयोगकर्ता जानकारी डेटाबेस में संग्रहीत थी। एप्लिकेशन को प्रतिबंधित किया गया है कि आप अपने एक्सेस स्तर के आधार पर किन चीजों को कर सकते हैं, लेकिन यह सभी प्रकार की लूट है यदि आप बस डेटाबेस से कनेक्ट कर सकते हैं और एड-हॉक क्वेरी चला सकते हैं।
मुझे यह जानने में दिलचस्पी है कि इस समस्या के आसपास अन्य सिस्टम क्या कर सकते हैं। यहाँ मेरे द्वारा चुने गए विकल्प हैं:
- उपयोगकर्ता और भूमिकाओं की सूची को बनाए रखने के लिए SQL सर्वर के सुरक्षा तंत्र का उपयोग करें, और डेस्कटॉप एप्लिकेशन को T-SQL प्रश्नों के माध्यम से उपयोगकर्ताओं को जोड़ने और हटाने के लिए बनाएं।
- डेटाबेस से सीधे कनेक्ट करने के बजाय, सर्वर पर चलने वाली कुछ प्रकार की वेब सेवा बनाएं और प्रमाणीकरण तर्क को वहां रखें। हर अनुरोध सुरक्षा सत्यापन करें।
पहला विकल्प थोड़ा बदसूरत है क्योंकि आप उपयोगकर्ताओं को डेटाबेस से अलग कर रहे हैं ताकि उपयोगकर्ता अब प्रथम श्रेणी की संस्थाएं न हों और आप उन्हें विदेशी कुंजी रिश्तों आदि के साथ संदर्भित न कर सकें।
दूसरा सिर्फ एक प्रमुख प्रदर्शन समस्या की तरह लगता है, और बहुत सारे अतिरिक्त काम, प्लस आप आसानी से ORM मैपर्स जैसे NHibernate (मुझे लगता है) का उपयोग नहीं कर सकते हैं।
क्या किसी के पास इसका अनुभव है? सर्वोत्तम प्रथाएं?
संपादित करें
थोड़ा और सोचकर, क्या SQL सर्वर प्रमाणीकरण वास्तव में इस समस्या को हल कर सकता है? उदाहरण के लिए, यदि आपका उपयोगकर्ता टाइमशीट रिकॉर्ड सम्मिलित करने और अपडेट करने में सक्षम होना चाहिए, ताकि आप अपना टाइमशीट संपादित कर सकें, तो कोई तरीका नहीं है कि SQL सर्वर टाइमशीट विवरण तालिका में अन्य पंक्तियों तक पहुंच को बाधित कर सकता है, जिसका अर्थ है कि आप अन्य लोगों की टाइमशीट भी पढ़ और लिख सकते हैं ।