डॉक्युमेंटेशन

ओळख पडताळणी

तुमच्या बॅकएंडच्या ताब्यातील स्वाक्षरी वापरून साइन इन केलेल्या व्यक्तीला ओळखा आणि तिचा संभाषण-इतिहास वेगवेगळ्या डिव्हाइसवर पुन्हा उपलब्ध करा.

पडताळणी का करावी#

डीफॉल्टनुसार SDK अनामिक असते: ती स्थिर visitor_id तयार करते आणि तो प्लॅटफॉर्मच्या कीस्टोअरमध्ये ठेवते. एका डिव्हाइसवरील एका संभाषणासाठी एवढे पुरेसे आहे. ठरावीक वापरकर्त्याला ओळखण्यासाठी, पुन्हा लॉगिन केल्यावर किंवा दुसऱ्या डिव्हाइसवर इतिहास परत मिळवण्यासाठी आणि संभाषण संपर्क-प्रोफाइलशी विश्वासार्हपणे जोडण्यासाठी बॅकएंडला क्लायंट तो सांगतो तोच आहे याचा पुरावा लागतो. SDK ने फक्त "मी वापरकर्ता 42 आहे" एवढेच पाठवले असते, तर कोणीही दुसऱ्याचा id सांगून त्याचे चॅट वाचू शकले असते — म्हणून Respondo userHash ही क्रिप्टोग्राफिक स्वाक्षरी मागते, जी फक्त तुमचा बॅकएंडच तयार करू शकतो.

identity secret मिळवणे#

identity_secret ही तुमच्या एजंटशी (तुमचे विजेट चॅनेल ज्या AI कर्मचाऱ्याशी जोडलेले आहे त्याच्याशी) बांधलेली गुप्त स्ट्रिंग आहे. ती डॅशबोर्डमध्ये Channels → Widget → Identity verification येथे तयार करा. ती एजंटवर राहत असल्यामुळे त्या एजंटवर चालणाऱ्या प्रत्येक चॅनेलला — वेब विजेट असो वा मोबाइल SDK — तीच सीक्रेट लागू होते. ती ओळखींवर स्वाक्षरी करण्याचा अधिकार देते, म्हणून ती फक्त तुमच्या बॅकएंडवरच राहिली पाहिजे आणि ॲपसोबत कधीही पाठवली जाऊ नये.

userHash चे सूत्र#

userHash म्हणजे स्वाक्षरी केलेल्या एकाच ओळख-स्ट्रिंगवरचा HMAC-SHA256, लोअरकेस hex मध्ये एन्कोड केलेला:

सूत्रtext
userHash = HMAC_SHA256( identity_secret, payload )

payload = userId          // userId दिलेला असल्यास
        = email           // अन्यथा, email दिलेला असल्यास
        = (invalid)       // दोन्ही रिकामे असल्यास स्वाक्षरी करण्यासारखे काहीच नाही
  • सीक्रेट ही HMAC ची की आहे; ओळख-स्ट्रिंग हा संदेश आहे — उलट नाही.
  • नेमकी एकच स्ट्रिंग स्वाक्षरित करा — कच्चा userId (किंवा email), कोणतेही salt किंवा JSON रॅपर न वापरता.
  • तुम्ही userId आणि email दोन्ही देत असाल, तर userId वर स्वाक्षरी करा (त्याला प्राधान्य आहे).
  • आउटपुट hex असते (SHA-256 साठी 64 अक्षरे), base64 नाही.

बॅकएंडची उदाहरणे#

स्वाक्षरी तुमच्या बॅकएंडवर काढा आणि तयार userHash ॲपला द्या.

Gogo
import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/hex"
)

// HMAC_SHA256(identity_secret, userId), लोअरकेस hex मध्ये.
func ComputeUserHash(identitySecret, userID string) string {
    mac := hmac.New(sha256.New, []byte(identitySecret))
    mac.Write([]byte(userID))
    return hex.EncodeToString(mac.Sum(nil))
}
Node.jsjavascript
const crypto = require("crypto");

// मोबाइल क्लायंटवर Respondo.identify ला द्यायचा userHash परत करते.
function computeUserHash(identitySecret, userId) {
  return crypto
    .createHmac("sha256", identitySecret)
    .update(userId, "utf8")
    .digest("hex");
}
Pythonpython
import hmac
import hashlib

# मोबाइल क्लायंटवर Respondo.identify ला द्यायचा userHash परत करते.
def compute_user_hash(identity_secret: str, user_id: str) -> str:
    return hmac.new(
        identity_secret.encode(),
        user_id.encode(),
        hashlib.sha256,
    ).hexdigest()
PHPphp
<?php
// मोबाइल क्लायंटवर Respondo.identify ला द्यायचा userHash परत करते.
function computeUserHash(string $identitySecret, string $userId): string {
    return hash_hmac('sha256', $userId, $identitySecret);
}

हॅश Respondo पर्यंत कसा पोहोचतो#

Respondo कोणतेही identity एंडपॉइंट देत नाही. कॉल करण्यासाठी /identity असा कोणताही रूट नाही आणि नोंदणी करण्यासारखेही काही नाही. userHash हे एक फील्ड आहे, जे SDK आधीपासूनच करत असलेल्या विनंत्यांसोबत जाते.

दोन टप्पे, आणि त्यातला फक्त पहिला तुम्हाला बनवायचा आहे:

  1. तुमचा बॅकएंड → तुमचे ॲप. हॅश कसा पोहोचवायचा हे पूर्णपणे तुमच्यावर आहे. सर्वात स्वस्त पर्याय म्हणजे तुम्ही आधीच परत करत असलेल्या login/bootstrap प्रतिसादात आणखी एक फील्ड जोडणे — वेगळी फेरी लागत नाही. तुमच्या स्वतःच्या बॅकएंडवरचा स्वतंत्र एंडपॉइंट (उदा. POST /myapp/identity जो { userId, userHash } परत करतो) तितकाच चांगला चालतो. तो एंडपॉइंट Respondo चालवत नाही — तो तुम्ही बनवायचा आहे.
  2. तुमचे ॲप → Respondo. हे तुमच्यासाठी आपोआप होते. तुम्ही एकदा identify कॉल केले, की SDK प्रत्येक संबंधित विनंतीला हॅश जोडते आणि बॅकएंड दर वेळी त्याची पुन्हा पडताळणी करतो.
SDK तो कुठे ठेवते (संदर्भासाठी — या तुम्ही हाताने पाठवत नाही)text
POST /api/v1/chat                      body   identity.userHash
GET  /api/v1/chat/resume               query  user_hash
GET  /api/v1/chat/history              query  user_hash
GET  /api/v1/chat/ws                   frames    user_hash (subscribe/identify JSON frames after connect — not in the handshake URL)
GET  /api/v1/widget/tours              query  user_hash
GET  /api/v1/widget/checklists         query  user_hash
POST /api/v1/widget/push/register      body   user_hash

हॅश प्रत्येक विनंतीला पुन्हा तपासला जातो; तो एकदा देऊन त्याबदल्यात सेशन मिळत नाही — त्यामुळेच चोरलेला userId एकटा निरुपयोगी ठरतो.

तुमच्या बॅकएंडवरचा हा पोहोचवणारा एंडपॉइंट अजून बनवलेला नसेल, तर तुमच्या ॲपची स्वतःची विनंती 404 देते, identify कधीच कॉल होत नाही आणि चॅट अनामिकपणे चालते. हे अपेक्षित वर्तन आहे, Respondo ची चूक नाही — तुमच्याच पत्त्यावरचा 404 म्हणजे तुमच्या बाजूचे बाकी असलेले काम, तुटलेले इंटिग्रेशन नव्हे.

SDK ला ओळख देणे#

स्वाक्षरी केलेली ओळख तुमच्या बॅकएंडकडून मिळवा, आणि मग कोणत्याही प्लॅटफॉर्मवर userHash identify ला द्या:

Kotlinkotlin
Respondo.identify(
    RespondoIdentity(userId = "42", email = "user@example.com", userHash = hash),
)
Swiftswift
Respondo.identify(
    RespondoIdentity(userId: "42", email: "user@example.com", userHash: hash)
)
Dartdart
Respondo.identify(RespondoIdentity(
  userId: '42', email: 'user@example.com', userHash: hash,
));

चुकीच्या userHash वेळी काय होते#

एजंटवर पडताळणी चालू असताना स्वाक्षरी नसेल किंवा चुकीची असेल, तेव्हा बॅकएंड गुपचूप अनामिककडे उतरवतो: चॅट चालूच राहते, visitor_id टिकतो आणि संभाषण अनामिक संपर्काशी जोडले जाते — पण प्रोफाइलशी दुवा राहत नाही आणि क्रॉस-डिव्हाइस इतिहासही मिळत नाही. एखादा वापरकर्ता "ओळखला जात नाही" असे वाटत असेल, तर जवळपास नेहमीच कारण स्वाक्षरीच असते: तुम्ही userId वर स्वाक्षरी केली आहे ना (email किंवा JSON वर नाही), योग्य identity_secret वापरला आहे ना आणि लोअरकेस hex दिला आहे ना, हे तपासा. एजंटचा identity_secret रिकामा असेल, तर पडताळणी बंद असते आणि userId / email जसेच्या तसे स्वीकारले जातात.

identity_secret बदलणे म्हणजे प्रत्यक्षात एकाच क्षणी होणारा पूर्ण बदल: जुन्या सीक्रेटने काढलेला प्रत्येक हॅश लगेच पडताळणीत नापास होतो, त्यामुळे आधीच साइन इन असलेले वापरकर्ते गुपचूप अनामिक होतात — जोपर्यंत तुमचा बॅकएंड नव्या सीक्रेटने त्यांचा userHash पुन्हा काढून देत नाही. स्वाक्षरी करणारी बाजूही त्याच वेळेत बदलता येत असेल, तेव्हाच सीक्रेट बदला.