2011-01-14 18 views
5

मुझे हाल ही में एक वेबसाइट के मेरे स्रोत कोड के बारे में एक सहयोगी से एक प्रतिक्रिया मिली है। वह कहता है कि यह एक बुरा अभ्यास है कि यह देखने के लिए कि कौन सा दृश्य इंटरफ़ेस करने की अनुमति नहीं देता है।क्या यह किसी ऐसे उपयोगकर्ता को ग़लत त्रुटियां प्रदान नहीं करता है जो वेबसाइट का सही उपयोग नहीं करता है?

चूंकि यह बहुत स्पष्ट नहीं है, यहां एक उदाहरण दिया गया है।

मान लें कि कोई विज़िटर कुछ टिप्पणी कर सकता है।

  • nvarchar(500) कॉलम में एक टिप्पणी डेटाबेस में सहेजी गई है।
  • <input /> क्षेत्र लंबाई 500.

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

(अन्य उदाहरण:। एक विकल्प है जो भी एक <select />लेकिन वहाँमें मौजूद नहीं है प्रस्तुत करने एक सुंदर त्रुटि जब उपयोगकर्ता एक नंबर डालने का आग्रह किया गया है, और वह बजाय एक गैर संख्या में प्रवेश करती है, के बाद से कीप्रेस घटनाओं को जावास्क्रिप्ट के माध्यम से नियंत्रित किया जाता है, और जावास्क्रिप्ट को अक्षम किया जा सकता है)

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

यह बुरा अभ्यास क्यों है? मैं उन मामलों के लिए स्पष्ट और स्पष्ट त्रुटि संदेशों को डिजाइन करने के लिए परेशान क्यों करूंगा जहां आगंतुक सही वेबसाइट का उपयोग नहीं करेंगे?


नोट: मैं समझता हूँ कि यह एक .नेट फ्रेमवर्क विस्तृत त्रुटि और एक स्टैक ट्रेस प्रदर्शित करने के लिए जब कुछ इस तरह होता है बेकार है। अगर मैं ऐसा करता हूं, तो यह एक गंभीर सुरक्षा समस्या है। लेकिन मेरे मामले में, कुछ जेनेरिक या किसी सामान्य पृष्ठ पर रीडायरेक्ट के साथ केवल एक AJAX प्रतिक्रिया होती है जिसमें त्रुटि के बारे में माफी माँगती है।

+0

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

+2

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

+0

@ मेनमा - मुझे लगता है कि आपको अपने प्रश्न को फिर से भरना होगा, क्योंकि यहां हर उत्तर बिंदु से चूक गया है। –

उत्तर

8

हर किसी को अपने वास्तविक प्रश्न गायब हो गया लगता है के बाद से, मैं जब तक आपके आदानों सर्वर साइड मान्य किए जाते हैं मेरे 2c में डाल देता हूँ (हालांकि मुझे कोई संदेह नहीं प्रतिशोध में downvoted हो जाएगा)

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

यदि, हालांकि, जावास्क्रिप्ट या गलत प्रविष्टि की कमी के माध्यम से सत्यापन विफल करना संभव है, तो उपयोगकर्ता की स्वच्छता के लिए एक कस्टम त्रुटि संदेश प्रदान किया जाना चाहिए।

संक्षेप में, आप जो कर रहे हैं वह ठीक है।

4

पहले एक सबसे महत्वपूर्ण बात

आप सब कुछ सर्वर पर उपयोगकर्ता की आपूर्ति को मान्य करना चाहिए! इसका मतलब है

इसके अलावा यदि कोई अनचाहे अपवाद होता है तो आपको उपयोगकर्ता को संदेश दिखाना चाहिए जो को कुछ भी नहीं देता है। यदि आप अपवाद जानकारी वापस कर रहे थे तो यह एक हमलावर पर सोने की धूल है।

सबसे अच्छी विधि एक सामान्य त्रुटि को प्रदर्शित करना है जैसे "हमें खेद है, हम सीधे समस्या पर काम कर रहे हैं" और डेवलपर्स को अपवाद जानकारी को ठीक करने के लिए उन्हें ईमेल करें।

+0

सवाल यह निर्दिष्ट करता है कि लंबी प्रविष्टि पकड़ी जाएगी। वह पूछ रहा है कि उपयोगकर्ता के अनुकूल संदेश को ऐसी स्थिति के लिए प्रदर्शित किया जाना चाहिए जहां उपयोगकर्ता स्पष्ट रूप से सिस्टम के साथ गड़बड़ कर रहा हो। –

+2

यदि कोई उपयोगकर्ता जानता है कि आपके एप्लिकेशन के साथ गड़बड़ कैसे करें तो आपको निश्चित रूप से उनकी सहायता नहीं करनी चाहिए, इसलिए आपको केवल एक सामान्य संदेश प्रदर्शित करना चाहिए –

+0

"सत्यापन" से आपका क्या मतलब है? यदि मैं लंबाई 500 वर्णों तक सीमित करने के लिए कोड अनुबंध का उपयोग करता हूं, तो इसका मतलब है कि उपयोगकर्ता 501 अक्षरों को सबमिट करते समय व्यापार परत से आगे नहीं जा पाएगा। यहां तक ​​कि यदि वह ऐसा करती है, तो डेटाबेस कॉलम 500 अक्षरों तक सीमित है (भले ही मुझे डेटाबेस को एक अनुरोध भेजना पसंद न हो, जो * निश्चित * निश्चित रूप से विफल हो जाएगा)। –

2

मैं उन मामलों के लिए स्पष्ट और स्पष्ट त्रुटि संदेशों को डिजाइन करने के लिए परेशान क्यों करूंगा जहां आगंतुक सही वेबसाइट का उपयोग नहीं करेंगे?

यदि हर कोई वेब का सही ढंग से उपयोग करता है, तो हमें कभी भी सत्यापन की आवश्यकता नहीं होगी।

जैसा कि रोनाल्ड रीगन ने एक बार कहा था, "विश्वास करें, लेकिन सत्यापित करें"।

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

+2

-1 ओपी ने कहा कि वह कोड अनुबंध का उपयोग कर रहा है। वह पूछ रहा है कि एक विशिष्ट त्रुटि कोड वापस किया जाना चाहिए, या यदि एक सामान्य विफलता (कोई अपवाद जानकारी के साथ) ठीक है। –

2

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

+1

मुझे पता है कि सवाल 100% स्पष्ट नहीं है, लेकिन वह स्पष्ट रूप से ऐसी कोई धारणा नहीं कर रहा है। –

+0

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

+2

प्रश्न की समझ की कमी एकमात्र कारण है जिसे मैंने एक जवाब जोड़ा और स्पष्ट रूप से, मुझे यह कठोर लगता है कि लगभग सभी उत्तरों ने इस सवाल को गलत तरीके से पढ़ा और _then_ ने कहा कि ओपी किसी तरह से आलसी या अन्यथा अक्षम था। मैंने "-1" टिप्पणियां जोड़ दीं क्योंकि मुझे यह पसंद नहीं है जब लोग गुमनाम रूप से डाउनवॉटेड होते हैं। एक असंबंधित नोट पर, यदि आप @Richard (केवल पहले 3 वर्णों के मामले में) के साथ अपनी टिप्पणी उपसर्ग करते हैं तो मुझे स्वचालित रूप से अधिसूचित किया जाएगा। –

2

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

मैं सुझाव दूंगा कि आप खुद से पूछें कि आप इन स्थितियों को नियंत्रित करने में बहुत आसान क्यों नहीं हैं। क्या यह आलस्य है या क्या आपको उपयोगकर्ता के रूप में अनुभव की कमी है?

+0

जो आप वर्णन कर रहे हैं वह वह नहीं है जो वह वर्णन कर रहा है। –

0

सर्वर साइड सत्यापन के दो मुख्य उद्देश्यों के लिए है:

  • एक मनोहर पतन अगर ग्राहक सत्यापन इस मामले में किसी कारण

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

      इस मामले में
    • , आप चाहते हैं कोई आंतरिक विवरण प्रदर्शित

आप सच मनोहर पतन का मार्ग लेने के लिए चाहते हैं, यह अच्छा होगा यदि सर्वर अभी भी वापस दे दी उपयोगकर्ता एक होगा प्रत्येक सत्यापन के लिए दोस्ताना संदेश।

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

हालांकि, हम में से अधिकांश, मानते हैं कि जावास्क्रिप्ट पर भरोसा किया जा सकता है, इसलिए सर्वर सत्यापन विफल होने पर एक सामान्य त्रुटि संदेश ठीक है।

संबंधित मुद्दे

 संबंधित मुद्दे