ਦਸਤਾਵੇਜ਼

ਪਛਾਣ ਦੀ ਪੁਸ਼ਟੀ

ਲੌਗ-ਇਨ ਕੀਤੇ ਵਿਅਕਤੀ ਨੂੰ ਪਛਾਣੋ ਅਤੇ ਹਰ ਡਿਵਾਈਸ ਉੱਤੇ ਉਸ ਦੀ ਗੱਲਬਾਤ ਦਾ ਇਤਿਹਾਸ ਬਹਾਲ ਕਰੋ — ਉਸ ਦਸਤਖ਼ਤ ਨਾਲ, ਜੋ ਤੁਹਾਡੇ backend ਦੇ ਕਾਬੂ ਵਿੱਚ ਹੈ।

ਪੁਸ਼ਟੀ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹੈ#

ਮੂਲ ਰੂਪ ਵਿੱਚ SDK ਗੁਮਨਾਮ ਹੁੰਦਾ ਹੈ: ਇਹ ਇੱਕ ਸਥਿਰ visitor_id ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਪਲੇਟਫ਼ਾਰਮ ਦੇ keystore ਵਿੱਚ ਸਾਂਭਦਾ ਹੈ। ਇੱਕ ਡਿਵਾਈਸ ਉੱਤੇ ਇੱਕ ਗੱਲਬਾਤ ਲਈ ਇੰਨਾ ਹੀ ਕਾਫ਼ੀ ਹੈ। ਪਰ ਕਿਸੇ ਖ਼ਾਸ ਵਰਤੋਂਕਾਰ ਨੂੰ ਪਛਾਣਨ ਲਈ, ਮੁੜ ਲੌਗ-ਇਨ ਕਰਨ ਜਾਂ ਦੂਜੀ ਡਿਵਾਈਸ ਉੱਤੇ ਇਤਿਹਾਸ ਬਹਾਲ ਕਰਨ ਲਈ, ਅਤੇ ਗੱਲਬਾਤ ਨੂੰ ਭਰੋਸੇ ਨਾਲ ਕਿਸੇ ਸੰਪਰਕ ਪ੍ਰੋਫ਼ਾਈਲ ਨਾਲ ਜੋੜਨ ਲਈ backend ਨੂੰ ਸਬੂਤ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਉਹੀ ਹੈ ਜੋ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ। ਜੇ SDK ਸਿਰਫ਼ ਐਨਾ ਭੇਜ ਦੇਵੇ ਕਿ "ਮੈਂ user 42 ਹਾਂ", ਤਾਂ ਕੋਈ ਵੀ ਹੋਰ id ਦਾ ਭੇਸ ਧਾਰ ਕੇ ਕਿਸੇ ਹੋਰ ਦੀ ਚੈਟ ਪੜ੍ਹ ਸਕਦਾ ਹੈ — ਇਸੇ ਲਈ Respondo ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਦਸਤਖ਼ਤ userHash ਮੰਗਦਾ ਹੈ, ਜੋ ਸਿਰਫ਼ ਤੁਹਾਡਾ backend ਹੀ ਬਣਾ ਸਕਦਾ ਹੈ।

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 ਦੀ key ਹੈ; ਪਛਾਣ-ਸਤਰ message ਹੈ — ਉਲਟਾ ਨਹੀਂ।
  • ਦਸਤਖ਼ਤ ਬਿਲਕੁਲ ਇੱਕੋ ਸਤਰ ਉੱਤੇ ਕਰੋ — ਕੱਚਾ userId (ਜਾਂ email), ਨਾ ਕੋਈ salt, ਨਾ JSON ਰੈਪਰ।
  • ਜੇ ਤੁਸੀਂ userId ਅਤੇ email ਦੋਵੇਂ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਦਸਤਖ਼ਤ userId ਉੱਤੇ ਕਰੋ (ਪਹਿਲ ਉਸੇ ਦੀ ਹੈ)।
  • ਨਤੀਜਾ hex ਹੁੰਦਾ ਹੈ (SHA-256 ਲਈ 64 ਅੱਖਰ), base64 ਨਹੀਂ।

ਬੈਕਐਂਡ ਲਈ ਉਦਾਹਰਨਾਂ#

ਦਸਤਖ਼ਤ ਆਪਣੇ 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 ਦੀਆਂ ਪਹਿਲਾਂ ਤੋਂ ਹੁੰਦੀਆਂ ਬੇਨਤੀਆਂ ਨਾਲ ਹੀ ਚਲਾ ਜਾਂਦਾ ਹੈ।

ਦੋ ਪੜਾਅ, ਅਤੇ ਬਣਾਉਣਾ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਪਹਿਲਾ ਹੀ ਹੈ:

  1. ਤੁਹਾਡਾ backend → ਤੁਹਾਡੀ ਐਪ। ਹੈਸ਼ ਤੁਸੀਂ ਜਿਵੇਂ ਚਾਹੋ ਪਹੁੰਚਾ ਸਕਦੇ ਹੋ। ਸਭ ਤੋਂ ਸਸਤਾ ਤਰੀਕਾ ਹੈ ਉਸੇ login/bootstrap ਜਵਾਬ ਵਿੱਚ ਇੱਕ ਵਾਧੂ ਫ਼ੀਲਡ ਜੋੜ ਦੇਣਾ, ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਭੇਜਦੇ ਹੋ — ਕੋਈ ਵਾਧੂ ਗੇੜਾ ਨਹੀਂ। ਆਪਣੇ backend ਉੱਤੇ ਵੱਖਰਾ ਐਂਡਪੌਇੰਟ (ਮੰਨ ਲਵੋ POST /myapp/identity, ਜੋ { userId, userHash } ਵਾਪਸ ਕਰੇ) ਵੀ ਓਨਾ ਹੀ ਵਧੀਆ ਚੱਲਦਾ ਹੈ। ਇਹ ਐਂਡਪੌਇੰਟ Respondo ਨਹੀਂ ਦਿੰਦਾ — ਇਹ ਤੁਸੀਂ ਆਪ ਬਣਾਉਂਦੇ ਹੋ।
  2. ਤੁਹਾਡੀ ਐਪ → Respondo। ਇਹ ਤੁਹਾਡੇ ਲਈ ਆਪੇ ਹੋ ਜਾਂਦਾ ਹੈ। ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ 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 ਉੱਤੇ ਕੀਤੇ ਹਨ (email ਜਾਂ JSON ਉੱਤੇ ਨਹੀਂ), ਸਹੀ identity_secret ਵਰਤਿਆ ਹੈ, ਅਤੇ ਨਤੀਜਾ ਛੋਟੇ ਅੱਖਰਾਂ ਵਾਲੇ hex ਵਿੱਚ ਦਿੱਤਾ ਹੈ। ਜੇ ਏਜੰਟ ਦਾ identity_secret ਖਾਲੀ ਹੋਵੇ, ਤਾਂ ਪੁਸ਼ਟੀ ਬੰਦ ਰਹਿੰਦੀ ਹੈ ਅਤੇ userId / email ਜਿਵੇਂ ਦੇ ਤਿਵੇਂ ਮੰਨ ਲਏ ਜਾਂਦੇ ਹਨ।

identity_secret ਬਦਲਣਾ ਅਸਲ ਵਿੱਚ ਇੱਕਦਮ ਕੀਤੀ ਤਬਦੀਲੀ ਹੈ: ਪੁਰਾਣੀ ਕੁੰਜੀ ਨਾਲ ਬਣਿਆ ਹਰ ਹੈਸ਼ ਉਸੇ ਵੇਲੇ ਪੁਸ਼ਟੀ ਵਿੱਚੋਂ ਲੰਘਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਸੋ ਪਹਿਲਾਂ ਤੋਂ ਲੌਗ-ਇਨ ਵਰਤੋਂਕਾਰ ਚੁੱਪਚਾਪ ਗੁਮਨਾਮ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਦ ਤੱਕ ਤੁਹਾਡਾ backend ਨਵੀਂ ਕੁੰਜੀ ਨਾਲ ਉਨ੍ਹਾਂ ਦਾ userHash ਦੁਬਾਰਾ ਬਣਾ ਕੇ ਨਹੀਂ ਦਿੰਦਾ। ਕੁੰਜੀ ਉਦੋਂ ਹੀ ਬਦਲੋ ਜਦੋਂ ਤੁਸੀਂ ਦਸਤਖ਼ਤ ਵਾਲਾ ਪਾਸਾ ਵੀ ਉਸੇ ਸਮੇਂ ਅੱਪਡੇਟ ਕਰ ਸਕੋ।