क्या आपको बाहरी API से अनपेक्षित मानों की रक्षा करनी चाहिए?

51

कहते हैं कि आप एक फ़ंक्शन को कोड कर रहे हैं जो बाहरी एपीआई से इनपुट लेता है MyAPI।

उस बाहरी API MyAPIका एक अनुबंध होता है जिसमें कहा गया है कि यह एक stringया एक रिटर्न देगा number।

यह तरह बातें से सुरक्षा के लिए सिफारिश की है null, undefined, boolean, आदि भले ही इसके बारे में एपीआई का हिस्सा नहीं है MyAPI? विशेष रूप से, चूंकि आपके पास उस API पर कोई नियंत्रण नहीं है, इसलिए आप स्थैतिक प्रकार के विश्लेषण जैसी किसी चीज़ के माध्यम से गारंटी नहीं दे सकते हैं, इसलिए यह खेद से सुरक्षित होना बेहतर है?

मैं रोबस्टनेस सिद्धांत के संबंध में सोच रहा हूं ।

— एडम थॉम्पसन
स्रोत

16

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

— विन्सेन्ट सावर

55

यदि आप उनसे उम्मीद कर रहे हैं, तो परिभाषा के अनुसार वे अप्रत्याशित नहीं हैं।

— मेसन व्हीलर

28

याद रखें कि एपीआई आपको केवल वैध JSON वापस देने के लिए बाध्य नहीं है (मुझे लगता है कि यह JSON है)। आपको उत्तर भी मिल सकता है जैसे

<!doctype html><html><head><title>504 Gateway Timeout</title></head><body>The server was unable to process your request. Make sure you have typed the address correctly. If the problem persists, please try again later.</body></html>

— user253751

5

"बाहरी एपीआई" का क्या अर्थ है? क्या यह अभी भी आपके नियंत्रण में है?

— डेडुप्लिकेटर

11

"एक अच्छा प्रोग्रामर वह होता है जो एक-तरफ़ा सड़क पार करने से पहले दोनों रास्ते देखता है।"

— jeroen_de_schutter

103

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

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

टिप्पणियों से मैं देख सकता हूं कि शायद मेरा जवाब थोड़ा विस्तार का उपयोग कर सकता है।

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

उदाहरण के माध्यम से मैं जिन टिप्पणियों को संबोधित करूंगा उनमें एक तर्क सामने आया। हां, आपको अपने ओएस पर कुछ हद तक भरोसा करना होगा, यह अनुचित नहीं है, उदाहरण के लिए, यादृच्छिक संख्या जनरेटर के परिणामों को अस्वीकार करें यदि आप इसे 1 और 10 के बीच की संख्या के लिए पूछते हैं और यह "बॉब" के साथ प्रतिक्रिया करता है।

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

हालांकि आप हर संभव इनपुट किसी को कभी नहीं जान सकते हैं / कुछ आपको दे सकते हैं, आप निश्चित रूप से यह सीमित कर सकते हैं कि व्यवसाय की आवश्यकताओं के आधार पर क्या स्वीकार्य है और उस आधार पर इनपुट श्वेत सूची के कुछ रूप हैं।

— पॉल
स्रोत

20

क्यूवी स्टैंड क्या है?

— जोनाह

15

@JonH मूल रूप से "भी देखें" ... लक्ष्य हैक एक उदाहरण है कि वह en.oxfordd शब्दकोशों . com/definition/qv को संदर्भित कर रहा है ।

— andttweber

8

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

— वामावर्तबौट

23

@leftaroundabout नहीं, लेकिन आपको उन सभी मान्य चीजों की भविष्यवाणी करने में सक्षम होना चाहिए जिन्हें आपका आवेदन स्वीकार कर सकता है और बाकी को अस्वीकार कर सकता है।

— पॉल

10

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

— Voo

33

हां , बिल्कुल। लेकिन क्या आपको लगता है कि उत्तर अलग हो सकता है?

निश्चित रूप से आपके प्रोग्राम को कुछ अप्रत्याशित तरीके से व्यवहार नहीं करने देना चाहते हैं, यदि एपीआई अनुबंध वापस नहीं लेता है, तो क्या आप नहीं करते हैं? तो कम से कम आपको इस तरह के व्यवहार से किसी तरह निपटना होगा । त्रुटि से निपटने का एक न्यूनतम रूप हमेशा (बहुत न्यूनतम!) प्रयास के लायक होता है, और इस तरह से कुछ लागू नहीं करने के लिए बिल्कुल कोई बहाना नहीं है।

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

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

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

— डॉक्टर ब्राउन
स्रोत

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

— मैकेंज़्म

@mckenzm: तथ्य यह है कि ओपी एक सवाल पूछता है, जहां शाब्दिक उत्तर स्पष्ट रूप से केवल "हां" हो सकता है, IMHO एक संकेत है जो वे केवल शाब्दिक उत्तर में दिलचस्पी नहीं ले सकते हैं। ऐसा लगता है कि वे पूछ रहे हैं "क्या यह आवश्यक है कि एक एपीआई से अप्रत्याशित मूल्यों के विभिन्न रूपों की रक्षा करें और उनके साथ अलग तरीके से व्यवहार करें" ?

— डॉक्टर ब्राउन

1

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

— mckenzm

21

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

संपादित करें: उपरोक्त कथन में मुझे गलत समझा गया था। रोबस्टनेस सिद्धांत हार्डवेयर की दुनिया से नहीं आता है, लेकिन इंटरनेट वास्तुकला से, विशेष रूप से आरएफसी 1958 से । य़ह कहता है:

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

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

इस बिंदु पर आगे विस्तार के लिए IETF पेपर द रोबसनेस प्रिंसिपल के हानिकारक परिणाम भी देखें ।

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

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

यही कारण है कि फेल फास्ट सिद्धांत मौजूद है; अपने API में इसे लागू करके सभी को सिरदर्द से बचाएं।

— मेसन व्हीलर
स्रोत

7

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

— मॉर्गन

9

@ मॉर्गन: मजबूती के सिद्धांत का उपयोग यह सुझाव देने के लिए किया जाता था कि ब्राउज़र को मैला HTML स्वीकार करना चाहिए, और वेब साइटों को तैनात करने के लिए नेतृत्व करने के लिए नेतृत्व करने की तुलना में वे बहुत ही सुस्त थे, अगर ब्राउज़र ने उचित एचटीएमएल की मांग की थी। समस्या का एक बड़ा हिस्सा, हालांकि, मानव-उत्पन्न और मशीन-जनित सामग्री के लिए एक सामान्य प्रारूप का उपयोग था, क्योंकि उनके बीच कनवर्ट करने के लिए उपयोगिताओं के साथ-साथ अलग-अलग मानव-संपादन योग्य और मशीन-पार्सबल प्रारूपों के उपयोग का विरोध किया गया था।

— सुपरकैट

9

@supercat: फिर भी - या सिर्फ इसलिए - HTML और WWW बेहद सफल रहे ;-)

— Doc Brown

11

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

— सुपरकैट

5

@ सुपरपैक्ट बिल्कुल उदाहरण के लिए, जावास्क्रिप्ट तुरंत दिमाग में आता है ...

— मेसन व्हीलर

13

सामान्य तौर पर, जब भी व्यावहारिक हो कम से कम निम्नलिखित बाधाओं को बनाए रखने के लिए कोड का निर्माण किया जाना चाहिए:

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

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

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

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

— supercat
स्रोत

फिर यह सब तय करने के लिए नीचे आता है कि क्या एपीआई कॉल का परिणाम "इनपुट" है।

— मस्तोव

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

— सुपरकैट

3

आइए दो परिदृश्यों की तुलना करें और एक निष्कर्ष पर आने का प्रयास करें।

परिदृश्य 1 हमारा आवेदन मानता है कि बाहरी एपीआई समझौते के अनुसार व्यवहार करेगा।

परिदृश्य 2 हमारा आवेदन मानता है कि बाहरी एपीआई गलत व्यवहार कर सकता है, इसलिए सावधानी बरतें।

सामान्य तौर पर, किसी भी एपीआई या सॉफ़्टवेयर के लिए समझौतों का उल्लंघन करने का मौका होता है; बग या अप्रत्याशित स्थितियों के कारण हो सकता है। यहां तक कि एक एपीआई में आंतरिक सिस्टम में समस्या हो सकती है जिसके परिणामस्वरूप अप्रत्याशित परिणाम हो सकते हैं।

अगर हमारे कार्यक्रम को यह कहते हुए लिखा जाता है कि बाहरी एपीआई समझौतों का पालन करेगा और किसी भी सावधानी बरतने से बचना होगा; मुद्दों का सामना करने वाली पार्टी कौन होगी? यह हम होंगे, जिन्होंने एकीकरण कोड लिखा है।

उदाहरण के लिए, शून्य मान जो आपने उठाया है। कहते हैं, एपीआई समझौते के अनुसार प्रतिक्रिया में शून्य मान नहीं होना चाहिए; लेकिन अगर अचानक इसका उल्लंघन हुआ तो हमारे कार्यक्रम का परिणाम NPEs होगा।

इसलिए, मेरा मानना है कि यह सुनिश्चित करने के लिए बेहतर होगा कि आपके एप्लिकेशन में अप्रत्याशित परिदृश्यों को संबोधित करने के लिए कुछ अतिरिक्त कोड हों।

— lkamal
स्रोत

1

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

सामान्यतया, किसी भी सीम में जहां अतिरिक्त-संस्थागत सिस्टम मिलते हैं, उन्हें प्रमाणीकरण, प्राधिकरण (यदि प्रमाणीकरण द्वारा केवल परिभाषित नहीं किया गया है), और सत्यापन की आवश्यकता होती है।

— StarTrekRedneck
स्रोत

1

सामान्य तौर पर, हाँ, आपको हमेशा त्रुटिपूर्ण जानकारी से बचना चाहिए, लेकिन एपीआई के प्रकार के आधार पर, "गार्ड" का अर्थ अलग-अलग चीजें हैं।

किसी सर्वर के लिए बाहरी एपीआई के लिए, आप गलती से एक कमांड नहीं बनाना चाहते हैं जो सर्वर की स्थिति को क्रैश या समझौता करता है, इसलिए आपको उसके खिलाफ गार्ड होना चाहिए।

उदाहरण के लिए जैसे कि एक कंटेनर क्लास (सूची, वेक्टर, आदि), अपवादों को फेंकना एक पूरी तरह से ठीक परिणाम है, वर्ग की स्थिति से समझौता करना कुछ हद तक स्वीकार्य हो सकता है (उदाहरण के लिए एक सॉर्ट किए गए कंटेनर जो एक दोषपूर्ण तुलना ऑपरेटर के साथ प्रदान नहीं किया जाएगा) क्रमबद्ध किया जा सकता है), यहां तक कि आवेदन को दुर्घटनाग्रस्त करना स्वीकार्य हो सकता है, लेकिन आवेदन की स्थिति से समझौता करना - जैसे कि कक्षा के उदाहरण से असंबंधित यादृच्छिक मेमोरी स्थानों पर लिखना - सबसे अधिक संभावना नहीं है।

— पीटर
स्रोत

0

थोड़ा अलग राय देने के लिए: मुझे लगता है कि यह आपके द्वारा दिए गए डेटा के साथ काम करने के लिए स्वीकार्य हो सकता है, भले ही यह अनुबंध का उल्लंघन करता हो। यह उपयोग पर निर्भर करता है: यह कुछ ऐसा है जो आपके लिए एक स्ट्रिंग होना चाहिए, या यह ऐसा कुछ है जिसे आप बस प्रदर्शित कर रहे हैं / उपयोग नहीं करते हैं आदि उत्तरार्द्ध मामले में, बस इसे स्वीकार करें। मेरे पास एक एपीआई है जिसे बस एक और एपीआई द्वारा वितरित डेटा का 1% चाहिए। मैं कम परवाह नहीं कर सकता था कि 99% में किस तरह के डेटा हैं, इसलिए मैं इसे कभी नहीं जांचूंगा।

"त्रुटि होने के बीच संतुलन होना चाहिए क्योंकि मैं अपने इनपुट की पर्याप्त जांच नहीं करता हूं" और "मैं मान्य डेटा को अस्वीकार करता हूं क्योंकि मैं बहुत सख्त हूं"।

— क्रिश्चियन सउर
स्रोत

2

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

— वू

1

@Voo - मेरा संदेह यह है कि वे कुछ बाहरी एपीआई (जैसे "शहर एक्स के लिए मौसम का विवरण प्राप्त करते हैं") कॉल कर रहे हैं और फिर उन्हें आवश्यक डेटा ("वर्तमान तापमान") को चेरी-लेने और शेष डेटा ("वर्षा") की अनदेखी कर रहे हैं "," हवा "," पूर्वानुमान तापमान "," विंड चिल ", आदि ...)

— स्टोबोर

@ChristianSauer - मुझे लगता है कि आप व्यापक सहमति से बहुत दूर नहीं हैं - आपके द्वारा उपयोग किए जाने वाले डेटा का 1% चेक करने के लिए समझ में आता है, लेकिन 99% जिसे आपको जांचने की आवश्यकता नहीं है। आपको केवल उन चीजों की जांच करने की आवश्यकता है जो आपके कोड को यात्रा कर सकते हैं।

— स्टोबोर

0

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

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

मेरी दुनिया में सब कुछ का परीक्षण करने के लिए दो अपवाद हैं:

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

वास्तव में इनपुट / रिटर्न वैल्यू की जांच करना कितना महत्वपूर्ण है, यह एक महत्वपूर्ण सवाल है। उदाहरण के लिए, अगर एपीआई को स्ट्रिंग लौटाने के लिए कहा जाता है, तो मैं उसकी जांच करूंगा:

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

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

— ghellquist
स्रोत