वास्तविक इनबॉक्सेसशिवाय OAuth रिकव्हरी ईमेल तपासा
OAuth रिकव्हरी ईमेल तपासण्याची सोपी पद्धत सुरक्षा धोके निर्माण करते. अनेक टीम्स पासवर्ड रिसेट लिंक्स एकाच सामायिक (shared) मेलबॉक्सवर पाठवतात. ईमेल आला की नाही हे तपासून ते पुढे जातात. ही पद्धत कमकुवत आहे. यामुळे टोकनचा पुनर्वापर (token reuse), चुकीच्या वापरकर्त्याला ईमेल जाणे आणि संवेदनशील लॉग डेटा (sensitive log data) यांसारख्या गोष्टी लपल्या राहतात.
प्रत्येक टेस्ट रनसाठी डिस्पोजेबल (disposable) ईमेल पत्ता वापरा. इव्हेंट वेगळा करा, त्याचे निरीक्षण करा आणि डेटा हटवा. यामुळे मिश्रित टेस्ट डेटामुळे तुमचे निकाल सिद्ध करणे कठीण होणार नाही.
एका चांगल्या थ्रेट मॉडेलमध्ये (threat model) खालील प्रश्न विचारले पाहिजेत:
- हा संदेश या विशिष्ट रनसाठी नियुक्त केलेल्या इनबॉक्समध्ये पोहोचला का?
- लिंक किंवा कोड योग्य वेळी कालबाह्य (expire) होतो का?
- सब्जेक्ट लाईनमुळे वापरकर्त्याचा खूप जास्त डेटा उघड होतो का?
- नवीन विनंतीनंतर जुने टोकन काम करू शकते का?
- लॉग्स रिकव्हरी सिक्रेट्स (recovery secrets) आवश्यकतेपेक्षा जास्त काळ साठवून ठेवतात का?
सर्वोत्तम पद्धत म्हणजे प्रत्येक टेस्ट एक्झिक्यूशनसाठी एक इनबॉक्स असणे. यामुळे प्रत्येक लिंक आणि टाइमस्टॅम्प एकाच रनशी जोडलेला राहतो.
या प्रक्रियेचे (flow) अनुसरण करा:
- एक नवीन युजर फिक्स्चर (user fixture) किंवा सँडबॉक्स आयडेंटिटी तयार करा.
- रिकव्हरी ईमेल रन-स्कोपड (run-scoped) इनबॉक्सकडे वळवा.
- OAuth किंवा पासवर्ड रिकव्हरी क्रिया एकदा ट्रिगर करा.
- नेमका एकच मॅचिंग ईमेल आला आहे याची खात्री करा.
- एक्सपायरी आणि सिंगल-युज (single-use) वर्तन तपासण्यासाठी लिंक किंवा कोड उघडा.
- इनबॉक्स आणि फिक्स्चर डेटा त्वरित नष्ट करा.
जर तुमच्या प्रक्रियेसाठी कालचे जुने ईमेल तपासण्याची आवश्यकता असेल, तर तुमची प्रक्रिया चुकीची आहे. रिकव्हरीचा पुरावा कधीही जुन्या (stale) डेटावर अवलंबून नसावा.
शिपिंगपूर्वी (shipping) या मुद्द्यांची तपासणी करा:
- प्राप्तकर्त्याचे अलिआस (recipient alias) टेस्ट आयडेंटिटीशी जुळते का.
- इव्हेंटसाठी फक्त एकच वैध रिकव्हरी मेसेज अस्तित्वात आहे का.
- सब्जेक्ट आणि प्रिव्ह्यूमुळे संवेदनशील डेटा उघड होत नाही ना.
- रिकव्हरी URL योग्य एन्व्हायरमेंटला (environment) निर्देशित करते का.
- वापरल्यानंतर किंवा कालबाह्य झाल्यानंतर टोकन अवैध होते का.
- रिट्राय (retry) वर्तनामुळे एकापेक्षा जास्त वैध टोकन्स सक्रिय राहत नाहीत ना.
या सामान्य चुका टाळा:
- अनेक टेस्ट युजर्ससाठी एकच इनबॉक्स पुन्हा वापरणे.
- रिकव्हरी URLs दीर्घकाळ टिकणाऱ्या लॉग्समध्ये साठवणे.
- रिकव्हरी सब्जेक्ट्समध्ये पूर्ण ईमेल पत्ते समाविष्ट करणे.
- दुसऱ्या विनंतीनंतर जुन्या लिंक्स अवैध करायला विसरणे.
स्टेजिंग डेटा महत्त्वाचा असतो. त्यामध्ये अनेकदा वास्तववादी नावे आणि कॉन्फिगरेशन असतात. सुरक्षित डिफॉल्ट्स वापरा: कमी रिटेंशन (retention), वन-टाइम सिक्रेट्स आणि स्पष्ट क्लिनअप (cleanup).
स्त्रोत: https://dev.to/sophiax99/how-to-test-oauth-recovery-emails-without-exposing-real-inboxes-hni