वास्तविक इनबॉक्स के बिना OAuth रिकवरी ईमेल का परीक्षण करें
OAuth रिकवरी ईमेल का आसान तरीके से परीक्षण करना सुरक्षा जोखिम पैदा करता है। कई टीमें पासवर्ड रीसेट लिंक को एक ही साझा मेलबॉक्स (shared mailbox) पर भेजती हैं। वे केवल यह देखते हैं कि ईमेल आया या नहीं और फिर आगे बढ़ जाते हैं। यह तरीका कमजोर है। यह टोकन के पुन: उपयोग (token reuse), गलत उपयोगकर्ता को डिलीवरी, और संवेदनशील लॉग डेटा को छिपा देता है।
प्रत्येक टेस्ट रन के लिए एक डिस्पोजेबल ईमेल एड्रेस (disposable email address) का उपयोग करें। इवेंट को अलग करें, उसका निरीक्षण करें और डेटा को डिलीट कर दें। यह मिश्रित टेस्ट डेटा को आपके परिणामों को साबित करने में कठिन होने से रोकता है।
एक अच्छे थ्रेट मॉडल (threat model) में ये प्रश्न पूछे जाने चाहिए:
- क्या संदेश इस विशिष्ट रन के लिए इच्छित इनबॉक्स तक पहुँचा?
- क्या लिंक या कोड सही समय पर एक्सपायर (expire) हो जाता है?
- क्या सब्जेक्ट लाइन बहुत अधिक यूजर डेटा उजागर करती है?
- क्या नए अनुरोध के बाद भी पुराना टोकन काम कर सकता है?
- क्या लॉग्स रिकवरी सीक्रेट्स को आवश्यकता से अधिक समय तक रखते हैं?
सबसे अच्छा पैटर्न प्रत्येक टेस्ट निष्पादन (test execution) के लिए एक इनबॉक्स का उपयोग करना है। यह प्रत्येक लिंक और टाइमस्टैम्प को एक ही रन से जोड़कर रखता है।
इस फ्लो (flow) का पालन करें:
- एक नया यूजर फिक्स्चर (user fixture) या सैंडबॉक्स आइडेंटिटी (sandbox identity) बनाएं।
- रिकवरी ईमेल को रन-स्कोप वाले इनबॉक्स (run-scoped inbox) पर रूट करें।
- OAuth या पासवर्ड रिकवरी एक्शन को एक बार ट्रिगर करें।
- सुनिश्चित करें (Assert) कि ठीक एक मेल खाता हुआ ईमेल प्राप्त हो।
- एक्सपायरी और सिंगल-यूज़ व्यवहार को सत्यापित करने के लिए लिंक या कोड खोलें।
- इनबॉक्स और फिक्स्चर डेटा को तुरंत नष्ट कर दें।
यदि आपकी प्रक्रिया में कल के पुराने ईमेल की जांच करने की आवश्यकता है, तो आपकी प्रक्रिया त्रुटिपूर्ण है। रिकवरी का प्रमाण कभी भी पुराने (stale) डेटा पर निर्भर नहीं होना चाहिए।
शिपिंग (shipping) से पहले इन बिंदुओं की जांच करें:
- प्राप्तकर्ता का एलियास (recipient alias) टेस्ट आइडेंटिटी से मेल खाता है।
- इवेंट के लिए केवल एक ही वैध रिकवरी मैसेज मौजूद है।
- सब्जेक्ट और प्रीव्यू संवेदनशील डेटा को उजागर नहीं करते हैं।
- रिकवरी URL सही एनवायरनमेंट (environment) की ओर संकेत करता है।
- उपयोग या एक्सपायरी के बाद टोकन अमान्य हो जाता है।
- रिट्राय व्यवहार (retry behavior) के कारण कई वैध टोकन सक्रिय नहीं रहने चाहिए।
इन सामान्य विफलताओं से बचें:
- कई टेस्ट यूजर्स के लिए एक ही इनबॉक्स का पुन: उपयोग करना।
- रिकवरी URL को लंबे समय तक रहने वाले लॉग्स में स्टोर करना।
- रिकवरी सब्जेक्ट्स में पूरे ईमेल एड्रेस शामिल करना।
- दूसरे अनुरोध के बाद पुराने लिंक को अमान्य करना भूल जाना।
स्टेजिंग डेटा (Staging data) महत्वपूर्ण है। इसमें अक्सर वास्तविक नाम और कॉन्फ़िगरेशन होते हैं। सुरक्षित डिफॉल्ट्स का उपयोग करें: कम रिटेंशन (short retention), वन-टाइम सीक्रेट्स, और स्पष्ट सफाई (explicit cleanup)।
स्रोत: https://dev.to/sophiax99/how-to-test-oauth-recovery-emails-without-exposing-real-inboxes-hni