அடையாளச் சரிபார்ப்பு

உங்கள் backend கட்டுப்படுத்தும் ஒரு கையொப்பத்தைப் பயன்படுத்தி, உள்நுழைந்த நபரை அடையாளம் கண்டு, அவரின் உரையாடல் வரலாற்றை எல்லாச் சாதனங்களிலும் மீட்டெடுங்கள்.

ஏன் சரிபார்க்க வேண்டும்#

இயல்பாக SDK அநாமதேயமானது: அது நிலையான visitor_id ஒன்றை உருவாக்கி, தளத்தின் keystore-இல் வைத்திருக்கிறது. ஒரு சாதனத்தில் ஒரு உரையாடலுக்கு அது போதும். ஆனால் ஒரு குறிப்பிட்ட பயனரை அடையாளம் காணவும், மறுஉள்நுழைவின் போதோ வேறு சாதனத்திலோ வரலாற்றை மீட்டெடுக்கவும், உரையாடலை ஒரு தொடர்பு விவரத்துடன் நம்பகமாகப் பிணைக்கவும், கிளையண்ட் தான் சொல்வதுதான் என்பதற்கான ஆதாரம் backend-க்குத் தேவை. SDK வெறுமனே "நான் பயனர் 42" என்று அனுப்பினால், யார் வேண்டுமானாலும் இன்னொருவரின் id-ஐப் போலியாகச் சொல்லி அவரின் அரட்டையைப் படிக்க முடியும் — அதனால்தான் Respondo, உங்கள் backend-ஆல் மட்டுமே உருவாக்க முடிந்த ஒரு குறியாக்கக் கையொப்பத்தை — userHash-ஐ — கோருகிறது.

identity secret-ஐப் பெறுதல்#

identity_secret என்பது உங்கள் முகவருடன் (உங்கள் விட்ஜெட் சேனல் இணைக்கப்பட்டுள்ள AI முகவருடன்) பிணைக்கப்பட்ட ரகசிய சரம். டாஷ்போர்டில் Channels → Widget → Identity verification பகுதியில் அதை உருவாக்குங்கள். அது முகவரிடம் இருப்பதால், அந்த முகவரால் இயங்கும் ஒவ்வொரு சேனலும் — வலை விட்ஜெட்டும் மொபைல் SDK-வும் ஒருசேர — ஒரே ரகசியத்தையே பகிர்ந்துகொள்கின்றன. அது அடையாளங்களில் கையொப்பமிடும் உரிமையைத் தருகிறது; எனவே அது உங்கள் backend-இல் மட்டுமே இருக்க வேண்டும், செயலியுடன் ஒருபோதும் அனுப்பப்படக் கூடாது.

userHash சூத்திரம்#

userHash என்பது கையொப்பமிடப்படும் ஒரே ஒரு அடையாளச் சரத்தின் மீதான HMAC-SHA256, சிறிய எழுத்து hex ஆகக் குறியீடு செய்யப்பட்டது:

சூத்திரம்text

userHash = HMAC_SHA256( identity_secret, payload )

payload = userId          // userId அமைக்கப்பட்டிருந்தால்
        = email           // இல்லையெனில், email அமைக்கப்பட்டிருந்தால்
        = (invalid)       // இரண்டும் காலியாக இருந்தால், கையொப்பமிட எதுவும் இல்லை

ரகசியம்தான் HMAC-இன் சாவி; அடையாளச் சரம்தான் செய்தி — அதற்கு நேர்மாறாக அல்ல.
சரியாக ஒரே ஒரு சரத்தில் கையொப்பமிடுங்கள் — உப்பு (salt) அல்லது JSON உறை எதுவும் இல்லாத மூல userId (அல்லது மின்னஞ்சல்).
userId-ஐயும் மின்னஞ்சலையும் இரண்டையும் அனுப்பினால், userId-இல் கையொப்பமிடுங்கள் (அதற்கே முன்னுரிமை).
வெளியீடு hex (SHA-256-க்கு 64 எழுத்துகள்), base64 அல்ல.

backend எடுத்துக்காட்டுகள்#

கையொப்பத்தை உங்கள் backend-இல் கணக்கிட்டு, தயாரான 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 ஏற்கெனவே அனுப்பும் கோரிக்கைகளுடன் பயணிக்கும் ஒரு புலம்.

இரண்டு தாவல்கள்; அவற்றில் முதலாவதை மட்டுமே நீங்கள் கட்ட வேண்டும்:

உங்கள் backend → உங்கள் செயலி. ஹாஷை நீங்கள் விரும்பிய வழியில் வழங்குங்கள். மலிவான வழி — நீங்கள் ஏற்கெனவே திருப்பித் தரும் உள்நுழைவு/bootstrap பதிலில் ஒரு கூடுதல் புலம் சேர்ப்பது; அப்போது கூடுதல் கோரிக்கையே தேவையில்லை. உங்கள் சொந்த backend-இல் ஒரு தனி எண்ட்பாயிண்ட்டும் (எடுத்துக்காட்டாக POST /myapp/identity → { userId, userHash }) அதே அளவு நன்றாக வேலை செய்யும். அந்த எண்ட்பாயிண்ட்டை Respondo வழங்குவதில்லை — அதை நீங்களே எழுத வேண்டும்.
உங்கள் செயலி → Respondo. இதை SDK பார்த்துக்கொள்கிறது. நீங்கள் identify-ஐ ஒரு முறை அழைத்ததும், தொடர்புடைய ஒவ்வொரு கோரிக்கையிலும் SDK ஹாஷை இணைக்கிறது; backend ஒவ்வொரு முறையும் அதை மீண்டும் சரிபார்க்கிறது.

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 மட்டும் தனியாகப் பயனற்றதாக இருப்பதற்குக் காரணம் இதுதான்.

உங்கள் backend-இல் வழங்கும் எண்ட்பாயிண்ட் இன்னும் கட்டப்படவில்லை என்றால், உங்கள் செயலியின் சொந்தக் கோரிக்கை 404 திருப்பும், identify ஒருபோதும் அழைக்கப்படாது, அரட்டை அநாமதேயமாகவே இயங்கும். இது எதிர்பார்க்கப்படும் நடத்தை, Respondo பிழை அல்ல — உங்கள் சொந்த வழியில் வரும் 404 என்பது உங்கள் பக்கத்தில் மீதமுள்ள வேலை, உடைந்த இணைப்பு அல்ல.

அடையாளத்தை SDK-க்கு அனுப்புதல்#

கையொப்பமிடப்பட்ட அடையாளத்தை உங்கள் backend-இலிருந்து பெற்று, எந்தத் தளத்திலும் 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-இன் நடத்தை#

முகவரில் சரிபார்ப்பு இயக்கப்பட்டிருக்கும்போது கையொப்பம் இல்லாவிட்டாலோ தவறாக இருந்தாலோ, backend அமைதியாக அநாமதேய நிலைக்குத் தரமிறக்குகிறது: அரட்டை தொடர்ந்து வேலை செய்யும், visitor_id தக்கவைக்கப்படும், உரையாடல் அநாமதேயத் தொடர்புடன் பிணைக்கப்படும் — ஆனால் விவரக்குறிப்புடன் எந்த இணைப்பும் இருக்காது, சாதனங்களுக்கு இடையிலான வரலாறும் இருக்காது. ஒரு பயனர் "அடையாளம் காணப்படவில்லை" என்றால், கிட்டத்தட்ட எப்போதும் காரணம் கையொப்பம்தான்: நீங்கள் userId-இல் (மின்னஞ்சலிலோ JSON-இலோ அல்ல) கையொப்பமிட்டீர்களா, சரியான identity_secret-ஐப் பயன்படுத்தினீர்களா, சிறிய எழுத்து hex-ஆக வெளியிட்டீர்களா என்று பாருங்கள். முகவரின் identity_secret காலியாக இருந்தால் சரிபார்ப்பு அணைந்திருக்கும், அப்போது userId / மின்னஞ்சல் அப்படியே ஏற்கப்படும்.

identity_secret-ஐ மாற்றுவது நடைமுறையில் ஒரே கணத்தில் நிகழும் முழு மாற்றம்: பழைய ரகசியத்தால் உருவாக்கப்பட்ட ஒவ்வொரு ஹாஷும் உடனே சரிபார்ப்பில் தோற்கும்; அதனால் ஏற்கெனவே உள்நுழைந்த பயனர்கள், உங்கள் backend புதிய ரகசியத்துடன் அவர்களின் userHash-ஐ மீண்டும் கணக்கிட்டு வழங்கும் வரை, அமைதியாக அநாமதேய நிலைக்கு மாறுவார்கள். கையொப்பமிடும் பக்கத்தையும் அதே நேரத்தில் புதுப்பிக்க முடியும் என்றால் மட்டுமே ரகசியத்தை மாற்றுங்கள்.