दोन PWAs मधील स्वाक्षरीकृत टोकन (Signed Token): बॅकएंडशिवाय HMAC-SHA256
तुम्हाला एका PWA कडून दुसऱ्या PWA कडे वापरकर्त्याची ओळख (user identity) पास करण्याची आवश्यकता आहे. दोन्ही ॲप्स वेगवेगळ्या Firebase प्रोजेक्ट्सवर चालतात. त्यांचे कोणतेही डेटाबेस किंवा ऑथेंटिकेशन (authentication) सामायिक नाही.
तुम्ही बॅकएंड कोड न लिहिता हे सोडवू शकता. तुम्हाला फक्त ब्राउझरमधील Web Crypto API आणि एक स्वाक्षरीकृत (signed) URL ची आवश्यकता आहे.
समस्या: PanelControl नावाच्या अंतर्गत टूलला Orders नावाच्या दुसऱ्या साइटवर जावे लागते. जेव्हा वापरकर्ता बटणावर क्लिक करतो, तेव्हा Orders साइटला वापरकर्ता कोण आहे हे माहित असणे आवश्यक आहे. वापरकर्त्याला दुसऱ्यांदा लॉगिन करण्याची गरज पडू नये.
हे करण्यासाठी तीन मार्ग:
- Shared Firebase: यासाठी सामायिक डेटाबेसची आवश्यकता असते. येथे ते शक्य नाही.
- postMessage: यासाठी समान डोमेन किंवा पॉपअपची आवश्यकता असते. याचे व्यवस्थापन करणे कठीण आहे.
- HMAC signed URL: टोकनसह लिंक वापरा. हे उत्तम प्रकारे काम करते.
हे कसे कार्य करते: HMAC एका सिक्रेट की (secret key) चा वापर करून स्वाक्षरी (signature) तयार करते. प्राप्तकर्ता (receiver) स्वाक्षरी तपासण्यासाठी त्याच की चा वापर करतो. जर त्या जुळल्या, तर पाठवणारा (sender) विश्वसनीय मानला जातो.
कार्यप्रवाह (Workflow):
- पाठवणारी बाजू (Sender side):
- वापरकर्त्याचे नाव आणि टाइमस्टॅम्पसह एक पेलोड (payload) तयार करा.
- HMAC-SHA256 वापरून पेलोडवर स्वाक्षरी करा.
- URL मध्ये स्वाक्षरी आणि पेलोड जोडा.
- प्राप्त करणारी बाजू (Receiver side):
- URL मधून टोकन वाचा.
- पेलोडमधून स्वाक्षरी वेगळी करा.
- सामायिक सिक्रेट वापरून स्वाक्षरी पुन्हा मोजा.
- टोकन कालबाह्य झाले आहे का ते तपासा (उदा. ५ मिनिटांनंतर).
- जर वैध असेल, तर ॲपमध्ये वापरकर्त्याची ओळख सेट करा.
अंमलबजावणीचे तपशील: Web Crypto API सर्व आधुनिक ब्राउझरमध्ये नेटिव्ह (native) आहे. ते ArrayBuffer सोबत काम करते आणि त्यासाठी कोणत्याही अतिरिक्त लायब्ररीची आवश्यकता नसते.
गोष्टी सुव्यवस्थित ठेवण्यासाठी, रिसीव्हर स्क्रिप्ट डॉक्युमेंटच्या head मध्ये चालते. ती टोकनची पडताळणी करते, वेळ तपासते आणि लगेच history.replaceState वापरून URL स्वच्छ करते. यामुळे ब्राउझर बारमधून टोकन निघून जाते आणि ते लपलेले राहते.
सुरक्षेबद्दल टीप: सिक्रेट की क्लायंट कोडमध्ये असते. DevTools वापरणारा कोणीही ती पाहू शकतो. अंतर्गत व्यावसायिक साधनांसाठी (internal business tools), जिथे तुम्ही फक्त नावासारखा संवेदनशील नसलेला डेटा पास करता, तिथे हे ठीक आहे.
जर तुम्ही संवेदनशील डेटासह सार्वजनिक ॲप बनवत असाल, तर त्याऐवजी सर्व्हर-साइड टोकन वापरा. अंतर्गत साधनांसाठी, ही क्लायंट-ओन्ली पद्धत जलद आणि प्रभावी आहे.
कोणतेही अतिरिक्त इन्फ्रास्ट्रक्चर नाही. कोणतेही अतिरिक्त डेटाबेस नाहीत. फक्त नेटिव्ह ब्राउझर टूल्स.
Source: https://dev.to/androve2k/signed-token-between-two-pwas-hmac-sha256-with-no-backend-3jod