अपने सर्वर पर सत्र बनाए रखें
server-rendered एप्लिकेशन के लिए निम्नलिखित बदलावों के साथ, JavaScript quickstart में बताया गया होस्टेड फ़्लो उपयोग करें। आपके route names एप्लिकेशन routes हैं जिन्हें आप स्वयं लागू करते हैं, Didit API endpoints नहीं।
केवल एक यादृच्छिक एप्लिकेशन-सत्र reference को
Secure, HttpOnly, SameSite=Lax cookie में भेजें, जिसका path सीमित हो। उचित समाप्ति अवधि रखें और साइन-इन के बाद reference बदलें। Didit refresh token को rendered props, client components या browser storage में उजागर न करें। token और callback responses पर Cache-Control: no-store उपयोग करें।
केवल layout या middleware की जाँच पर भरोसा न करें: हर डेटा access और mutation पर अधिकृत करें। cookie से प्रमाणित mutations को CSRF से सुरक्षित रखें। केवल कॉन्फ़िगर किए गए लॉगिन-के-बाद के गंतव्यों की अनुमति दें, query string से आने वाले किसी भी मनमाने returnTo URL की कभी नहीं।
पैकेज रिलीज़ पूर्वावलोकन
प्रस्तावित पैकेज में middleware, server-sideauth(), callback route और server rendering के लिए HttpOnly cookie समर्थन जुड़ेगा। core /server entry का उद्देश्य cached JWKS के साथ verifyToken() देना है। इन symbols का उपयोग करने से पहले सत्यापित रिलीज़ के exports की प्रतीक्षा करें। तब तक, tokens and JWKS में बताए अनुसार, किसी भी JOSE library से tokens स्वयं सत्यापित करें।
अन्य उत्पादों से जोड़ें
सर्वर पर सत्यापन सत्र बनाएँ और सीमित दायरे वाले monitoring tokens जारी करें।vendor_data को सत्यापित व्यक्ति मैपिंग से प्राप्त करें। ब्राउज़र को केवल सत्यापन सत्र URL या अल्पकालिक SDK token लौटाएँ। DIDIT_API_KEY को सार्वजनिक environment variables में न रखें।
सत्यापन के लिए मौजूदा web verification SDK और monitoring के लिए transaction submission guide का उपयोग करें। इनमें से कोई भी प्रमाणीकरण सत्र प्रबंधक नहीं है।
रिलीज़ से पहले callback replay, गलत state, समय-सीमा समाप्त state, refresh races, निरस्त सत्र, CSRF अस्वीकृति और लॉगआउट का परीक्षण करें। सत्यापन अनुबंध के लिए tokens and JWKS देखें।