एएसपी.नेट में क्वेरीस्ट्रिंग का उपयोग करने में सर्वोत्तम प्रथाएं?

Question

मैं ASP.NET में QueryString का उपयोग करते समय कुछ बेहतरीन अभ्यास मार्गदर्शन खोज रहा हूं और वास्तव में कोई भी नहीं मिला है।

मैं एक उपयोगी अनुकूलन लेख पाया है: http://dotnetperls.com/querystring

लेकिन मैं निम्न प्रश्नों का उत्तर में अधिक रुचि रखते हूँ:

• प्रकरण नियम? सभी छोटे अक्षर? पास्कल केस? टेढ़े मेढ़े संयुक्त शब्द?
  • मेरी निजी वरीयता सभी लोअरकेस है, लेकिन स्थिरता सबसे महत्वपूर्ण है।
• पैरामीटर नामों में विशेष वर्णों से बचना?
• सुरक्षा उद्देश्यों के लिए पैरामीटर और मानों को obfuscated किया जाना चाहिए?

आदि ...

कोई और दिशा निर्देशों की सराहना की होगी!

Answer 1

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

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

http://myurl.com/myPage.aspx?secretKey=73FA4A5A85A44C75ABB5E323569628D3 

यह बल एक GUID और एक GUID टकराव की संभावना infinitesimally छोटे हैं, इसलिए यदि क्वेरी स्ट्रिंग के साथ अंत उपयोगकर्ता भोजनालयों तो वे अंत में कुछ भी नहीं हो रही है जानवर करने के लिए नहीं बल्कि मुश्किल है।

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

Answer 2

मेरे 5 सेंट:

यदि आप एक पृष्ठ है कि अन्य लोगों द्वारा कहा जा सकता है, जैसे

http://myurl.com/myPage.aspx?secretKey=73FA4A5A85A44C75ABB5E323569628D3 

है तो आप नहीं उन्हें समस्याओं का अनुभव करना चाहते हैं जब वे secretKey में कश्मीर गलत लिखा है इसे पूंजी पत्र नहीं बनाकर।

तो यहाँ मेरे नियमों:

1. यह सभी लोअरकेस करो। कभी अपरकेस नहीं, क्योंकि कुछ छोटे अक्षर हैं जिनके पास जर्मन डबल एस जैसे संबंधित अपरकेस अक्षर नहीं हैं।

2. QueryString["mykey"].ToLower().Equals("73FA4A5A85A44C75ABB5E323569628D3") क्योंकि QueryString["mykey"] शून्य (अपवाद शून्य संदर्भ) हो सकता है एक बुरा विचार है।

3. string.IsNullOrEmpty() if else if object.equals(querykey, "comparison") जैसी कोई जटिल चीजें नहीं हैं। बस StringComparer.OrdinalIgnoreCase.Equals(key, "73FA4A5A85A44C75ABB5E323569628D3") का उपयोग करें, यह NULL पर काम करता है, झूठा रिटर्न, कोई अतिरिक्त शून्य/emtpy जांच की आवश्यकता है।

Answer 3

मुझे लगता है कि स्लगस्टर और स्टीफन के बीच कोई बेहतर जवाब नहीं है। दोनों को ग्रिड का जिक्र करने और कम मामले का उपयोग करने के लिए सबसे अच्छा करना है, इसलिए ऊपर दिया गया उदाहरण वास्तव में http://myurl.com/mypage.aspx?secretkey=73fa4a5a85a44c75abb5e323569628d3