मेल डिलीवरी सफल होने के बाद मैजिक-लिंक विफलता हो सकती है। संदेश समाप्ति के बाद आ सकता है, एप्लिकेशन पहले वाले लिंक को अमान्य कर सकता है, या रीडायरेक्ट गलत वातावरण में आ सकता है। प्रत्येक असफल साइन-इन को प्रमाणीकरण-रिकॉर्ड समस्या के रूप में मानने के बजाय अलग-अलग परिकल्पनाओं के रूप में इनकी जांच करें।
दो यात्राओं का पता लगाएँ
मेल यात्रा अनुरोध से पीढ़ी, कतारबद्धता और प्राप्तकर्ता-सर्वर स्वीकृति तक चलती है। एप्लिकेशन यात्रा टोकन निर्माण से लेकर लिंक अनुरोध, सत्यापन और सत्र स्थापना तक चलती है। एक गैर-गुप्त सहसंबंध पहचानकर्ता का उपयोग करके उनसे जुड़ें। संपूर्ण बियरर लिंक लॉग न करें या किसी लाइव लिंक को बाहरी स्कैनर में पेस्ट न करें।
SMTP स्वीकृति घटना स्थानांतरण जिम्मेदारी के बारे में सबूत है, न कि पूर्ण उपयोगकर्ता सत्र। समर्थन लेबल सटीक रखें. RFC 5321. जब प्रदाता केवल सबमिशन और अंतिम स्थिति को उजागर करता है तो गायब दृश्यता को स्पष्ट रूप से रिकॉर्ड करें।
OWASP लॉगिंग मार्गदर्शन पहुंच रहस्यों को उजागर किए बिना सहसंबंध का समर्थन करता है।
लिंक डिज़ाइन को अलग से मान्य करें
OWASP के पासवर्ड-रीसेट मार्गदर्शन में सुरक्षा सिद्धांतों में एकल-उपयोग समाप्त होने वाले टोकन, विश्वसनीय HTTPS गंतव्य और टोकन रिसाव के खिलाफ सुरक्षा शामिल है। वे सिद्धांत संवेदनशील ईमेल किए गए लिंक की समीक्षा करने के लिए प्रासंगिक हैं, लेकिन स्रोत पासवर्ड रहित लॉगिन के लिए पूर्ण विनिर्देश के बजाय पासवर्ड रीसेट के बारे में है। एक मैजिक-लिंक उत्पाद को अपने स्वयं के खतरे मॉडल और सत्र नियंत्रण की आवश्यकता होती है। OWASP रीसेट-टोकन मार्गदर्शन.
अनुमोदित परीक्षण वातावरण में डिस्पोजेबल परीक्षण क्रेडेंशियल्स का उपयोग करके इच्छित होस्ट, पर्यावरण, पथ और रीडायरेक्ट व्यवहार का निरीक्षण करें। पुष्टि करें कि क्या नया अनुरोध पिछले लिंक को अमान्य कर देता है और क्या सफल उपयोग टोकन को अमान्य कर देता है। यह मानने के बजाय कि सभी उत्पाद एक जैसा व्यवहार करते हैं, वास्तविक नीति रिकॉर्ड करें।
समाप्ति विफलता और उपभोग विफलता की तुलना करें
09:00 यूटीसी पर बनाए गए दो काल्पनिक टोकन पर विचार करें जिनकी समाप्ति 09:10 पर हो। केस ए समाप्ति से एक मिनट पहले ही 09:11 पर रिसीवर स्वीकृति तक पहुंच जाता है। केस बी 09:01 पर उस चरण पर पहुंचता है, 09:02 पर एक सफल एप्लिकेशन रिडेम्प्शन दर्ज किया जाता है, और 09:03 पर दूसरा प्रयास प्राप्त होता है। एकल-उपयोग नीति के तहत, बी का दूसरा प्रयास विफल हो जाना चाहिए क्योंकि सात मिनट शेष रहने पर भी पहले ही प्रयोग किया जा चुका है।
ये आविष्कृत घटना धारणाएँ हैं, न कि राज्य-मशीन निष्पादन या सत्यापित घटनाएँ। केस ए समयबद्ध जांच का सुझाव देता है; केस बी में पहले के आवेदन संक्रमण के बारे में साक्ष्य की आवश्यकता होती है। कम मेल विलंब बी को पुन: प्रयोज्य नहीं बनाएगा। किसी सुरक्षा स्कैनर या केवल उपयोगकर्ता-एजेंट स्ट्रिंग वाले व्यक्ति को प्रारंभिक कार्रवाई न सौंपें। अभिनेता को जिम्मेदार ठहराने से पहले अधिकृत संशोधित अनुरोध रिकॉर्ड, राज्य परिवर्तन और सत्र घटनाओं को सहसंबंधित करें।
लिंक को पुन: प्रयोज्य बनाए बिना मरम्मत करें
वास्तविक विलंब के लिए, धीमे चरण का समाधान करें और शेष वैधता बजट का सत्यापन करें। समय से पहले उपभोग के लिए, समीक्षा करें कि क्या एप्लिकेशन एक सत्र स्थापित करने वाली स्पष्ट, सुरक्षित रूप से मान्य कार्रवाई से हानिरहित लैंडिंग अनुरोध को अलग कर सकता है। यह एक डिज़ाइन समीक्षा है, कोई सार्वभौमिक पैच नहीं; पुनरावृत्ति की रोकथाम, समाप्ति और अन्य आवश्यक नियंत्रणों को सुरक्षित रखें।
स्वीकृत टेम्पलेट कॉन्फ़िगरेशन के माध्यम से संवेदनशील खाता लिंक से अनावश्यक मार्केटिंग ट्रैकिंग हटाएं और अंतिम संदेश सत्यापित करें। किसी भी रीडायरेक्ट या मोबाइल डीप-लिंक व्यवहार को अभी भी परीक्षण की आवश्यकता है। कभी भी समाप्त हो चुके टोकन को अनिश्चित काल के लिए स्वीकार करके रुक-रुक कर होने वाली विफलता का समाधान न करें।
विलंबित आगमन, बार-बार अनुरोध, पुनरावृत्ति और गलत वातावरण वाले रूटिंग के लिए नियंत्रित यात्राओं का पुनः परीक्षण करें। सटीक विफलता वर्ग और शेष अंतराल के साथ बंद करें। एक स्पष्ट वर्गीकरण मेल ऑपरेटरों और एप्लिकेशन इंजीनियरों को बार-बार गलत सिस्टम बदलने से रोकता है।
प्रत्येक विफलता वर्ग के लिए एक अलग समापन की आवश्यकता है
नियंत्रित यात्रा द्वारा वैधता बजट की पुष्टि करने के बाद ही तेजी से आगमन समाप्ति-विलंब मामले को बंद कर सकता है। यह पूर्व-उपभोग या गलत-पर्यावरण के मामले को बंद नहीं कर सकता है। कारण बताने से पहले कक्षा को रिकॉर्ड करें, आवेदन परिवर्तन का समर्थन करें और लापता साक्ष्य को रिकॉर्ड करें।