मेरे पास एक ऐसा फॉर्म है जो उपयोगकर्ता को सार्वजनिक आईडी दिखाता है। मैं सोच रहा था कि यह खतरनाक है। व्यक्तिगत रूप से मुझे इसके बारे में कुछ भी बुरा नहीं दिखता है। आईडी का उपयोग सिर्फ एक डेटाबेस रिकॉर्ड के संदर्भ में किया जाता है।क्या मुझे सार्वजनिक रूप से उपयोगकर्ता आईडी का पर्दाफाश करना चाहिए?
यदि यह खतरनाक थे, ताकि उपयोगकर्ता प्रोफ़ाइल लुकअप काम करने के लिए में स्टैक ओवरफ़्लो अपने URL में उपयोगकर्ता आईडी से प्रदर्शित नहीं किया जाएगा: https://stackoverflow.com/users/104826/rfactor
विशाल स्तर की गंभीरता के संपादित करें: प्रयोक्ता आईडी खुद को प्रति संवेदनशील हैं, तो डेटा; उदाहरण के लिए किसी कारण से आपकी प्राथमिक कुंजी सामाजिक सुरक्षा संख्या होती है, जो निश्चित रूप से एक सुरक्षा और गोपनीयता देयता होगी। यदि आपकी उपयोगकर्ता आईडी केवल ऑटो-वृद्धि संख्याएं हैं, तो आप स्पष्ट हैं।
क्योंकि मेरे लिए आईडी उपयोगकर्ता नाम दिखाने के रूप में खतरनाक है।
उपयोगकर्ता आईडी का खुलासा करना, अपने आप में, बुरा नहीं है। यह गोपनीयता और सुरक्षा के स्तर पर निर्भर करता है। यदि उपयोगकर्ता आईडी का खुलासा नहीं किया जाता है और किसी अन्य व्यक्तिगत डेटा से बंधे नहीं जा सकते हैं जो अन्यथा निजी हो, तो कोई समस्या नहीं हो सकती है।
लेकिन ऐसा नहीं लगता कि सार्वजनिक उपयोगकर्ता आईडी कभी भी समस्या नहीं हो सकती है।
सुनिश्चित करें कि आप उपयोगकर्ता आईडी को जानकर किसी भी निजी डेटा में प्रवेश करने की अनुमति न दें। फेसबुक को ऐसी समस्याएं थीं। यहां केवल है। उपयोगकर्ता आईडी को प्रकट करते समय पूरी कहानी नहीं थी, यह समीकरण का हिस्सा था।
क्या इससे कुछ नुकसान होगा? केवल आप ही इसे तय कर सकते हैं, और आपको इसके बारे में सोचना चाहिए। लेकिन सामान्य रूप से, ऐसा करने के लिए व्यावसायिक कारण के बिना उपयोगकर्ता आईडी प्रदर्शित करने के लिए यह खराब रूप है। (आपको काम बचाता है शायद यह एक अच्छा व्यावसायिक कारण नहीं है।)
यदि यह किसी अन्य अर्थ के साथ उत्पन्न डेटाबेस आईडी है, तो यह खतरनाक नहीं है। हालांकि मुझे नहीं लगता कि एक आईडी को प्रकट करना या तो सुरुचिपूर्ण है। यह एक तकनीकी विवरण है और मैं समझ नहीं पा रहा हूं कि आप इसे उपयोगकर्ताओं को क्यों दिखाना चाहते हैं।
आम तौर पर यह कोई समस्या नहीं है, लेकिन यह आपकी साइट कितनी सक्रिय है, इस बारे में संकेत दे सकता है कि आपके पास कितने उपयोगकर्ता हैं आदि। यदि आप इस संवेदनशील जानकारी पर विचार करते हैं या यहां तक कि अच्छी मार्केटिंग भी पूरी तरह से आपके ऊपर है।
एक कहानी है कि यह डब्ल्यूडब्ल्यू 2 खोने के कारणों में से एक कारण था। उनके पास क्रमिक प्रत्येक टैंक पर लिखे गए उत्पादन से धारावाहिक संख्या थी। ब्रिटिश बाहर निकाले गए टैंकों से आईडी संख्या एकत्र करके अनुमान लगाया जा सकता है कि पूरे जर्मन सेना के कितने टैंक थे और इससे नई रणनीतियां बन गईं।
मुझे पता चला है कि भौतिक संस्थाओं की पहचान करने वाली प्राथमिक कुंजी का पर्दाफाश सिरदर्द पैदा कर सकता है।
कल्पना करें कि दो रक्त नमूने एक प्रयोगशाला में आते हैं और प्रत्येक नमूने के लिए परीक्षण परिणाम उत्पन्न होते हैं। कई अलग-अलग प्रकार के परीक्षण किए जा सकते हैं और एक परीक्षण परिणाम का प्रतिनिधित्व करने वाले प्रत्येक रिकॉर्ड में विदेशी कुंजी के रूप में sample_id होगा।
यदि आप ग्राहक के साथ डेटाबेस आईडी साझा करते हैं और आप पाते हैं कि दो नमूने गलती से स्विच किए गए हैं, तो आपको परीक्षणों का प्रतिनिधित्व करने वाले सभी विवरण रिकॉर्ड में विदेशी कुंजी अपडेट करनी होगी। यदि आपने अपने सिस्टम के बाहर कुछ अन्य अनूठा नाम का खुलासा किया है, तो आपको मास्टर टेबल में नमूना रिकॉर्ड पर दो अद्वितीय नामों को स्विच करने की आवश्यकता होगी।
डेटा माइग्रेशन से संबंधित अन्य फायदे हैं और ऐसे कई फायदे हैं जब एक से अधिक डेटाबेस में इकाइयों का प्रतिनिधित्व किया जाता है जिसमें समान डेटाबेस आईडी के साथ रिकॉर्ड बनाना मुश्किल होता है।
मेरे अनुभव में आपके सिस्टम के बाहर प्राथमिक कुंजी के अलावा एक अद्वितीय पहचानकर्ता का खुलासा करना हमेशा सर्वोत्तम होता है। यह आपको डाटा मिक्स-अप को हल करने, डेटा माइग्रेशन समस्याओं से निपटने, और अन्यथा भविष्य में आपके सिस्टम को प्रमाणित करने में अधिक लचीलापन देता है।
वैसे SO कई स्थानों पर करता है, उदा। आपका उपयोगकर्ता खाता यूआरएल, और आपको इसे SEDE – Rup