ग्राहक आईडी
प्रत्येक प्रोजेक्ट को अपना स्वयं का क्लाइंट पहचानकर्ता मिलता है।
Meld® IDएक खाता
प्रोजेक्ट टीमों के लिए
यह पृष्ठ तकनीकी अनुबंध को उपयोगकर्ता-सामना वाले पोर्टल से अलग दिखाता है: client_id, redirect_uri, गुप्त, IP allowlist, और OAuth प्रवाह।
प्रत्येक प्रोजेक्ट को अपना स्वयं का क्लाइंट पहचानकर्ता मिलता है।
रहस्यों को व्यवस्थापक क्षेत्र से घुमाया जा सकता है।
कॉलबैक यूआरएल समय से पहले पंजीकृत किए जाते हैं और सटीक रूप से मिलान किए जाते हैं।
सर्वर-टू-सर्वर अनुरोध ज्ञात पतों तक सीमित हो सकते हैं।
01
प्रत्येक प्रोजेक्ट के अपने नियम होते हैं और दूसरों को परेशान नहीं करते।
प्रोजेक्ट को client_id मिलता है, जबकि उपयोगकर्ता एक पहचान रखता है।
अनुमत redirect_uri मान समय से पहले निर्धारित किए जाते हैं और उनका अनुमान नहीं लगाया जाता है।
ग्राहक रहस्य अलग से संग्रहीत किया जाता है और इसे फिर से जारी किया जा सकता है।
एकीकरण को विशिष्ट आईपी पते तक सीमित किया जा सकता है।
02
प्रत्येक प्रोजेक्ट केवल उन क्षेत्रों के लिए पूछता है जिनकी उसे आवश्यकता है, और Meld® ID केवल उपयोगकर्ता द्वारा अनुमोदित दावों को लौटाता है।
पहचान की पुष्टि करता है और बुनियादी लॉगिन प्रवाह के लिए आवश्यक है।
पुष्टि की गई ईमेल और उसकी सत्यापन स्थिति लौटाता है।
विस्तृत प्रोफ़ाइल का दायरा. इसमें profile.basic, profile.contact, profile.address, और profile.billing शामिल हैं।
पहला नाम, अंतिम नाम, प्रदर्शन नाम, जन्म तिथि और भाषा।
संपर्क और सत्यापन के लिए फ़ोन नंबर.
भुगतान डेटा के बिना घर या डिलीवरी का पता।
बिलिंग का नाम, कंपनी और कर विवरण। कोई कार्ड स्थानांतरित नहीं किया जाता.
03
पहले प्राधिकरण, फिर कोड, फिर टोकन एक्सचेंज, फिर प्रोजेक्ट का स्थानीय सत्र।
उपयोगकर्ता Meld® ID खोलता है और प्रोजेक्ट लॉगिन को मंजूरी देता है।
सहमति के बाद, Meld® ID पंजीकृत redirect_uri के लिए एक प्राधिकरण कोड जारी करता है।
प्रोजेक्ट एक्सेस टोकन के लिए कोड का आदान-प्रदान करता है और userinfo प्राप्त करता है।
04
हम बिना किसी अनुमान के रीडायरेक्ट, रहस्य और IP allowlists की जांच करते हैं।
मिलान सटीक होना चाहिए, बिना किसी मनमाने बदलाव के।
सर्वर ब्राउज़र लॉगिन से अलग से रहस्य की पुष्टि करता है।
व्यवस्थापक क्षेत्र दिखाता है कि कौन कहाँ जाता है और श्रृंखला कहाँ टूटती है।