Nyaraka

Uthibitishaji wa utambulisho

Mtambue mtu aliyeingia na urejeshe historia ya mazungumzo yake kati ya vifaa, kwa kutumia sahihi inayodhibitiwa na backend yako.

Kwa nini kuthibitisha#

Kwa chaguo-msingi SDK haimtambui mtumiaji: hutengeneza visitor_id thabiti na kuihifadhi katika keystore ya mfumo. Hiyo inatosha kwa mazungumzo moja kwenye kifaa kimoja. Ili kumtambua mtumiaji mahususi, kurejesha historia baada ya kuingia upya au kwenye kifaa kingine, na kufunga mazungumzo kwenye wasifu wa mwasiliani kwa uhakika, backend inahitaji uthibitisho kuwa kliyenti ni yule anayedai kuwa. Kama SDK ingetuma tu "mimi ni mtumiaji 42", mtu yeyote angeweza kujifanya kuwa na kitambulisho kingine na kusoma gumzo la mtu mwingine — kwa hiyo Respondo huhitaji sahihi ya kriptografia, userHash, ambayo backend yako pekee inaweza kuizalisha.

Kupata identity secret#

identity_secret ni mfuatano wa siri uliofungwa kwa wakala wako (mfanyakazi wa AI ambaye kituo cha wijeti yako kimeunganishwa naye). Itengeneze katika dashibodi chini ya Channels → Widget → Identity verification. Kwa kuwa inakaa kwa wakala, kila kituo kinachotumia wakala huyo — wijeti ya wavuti na SDK ya simu vilevile — hushiriki siri ileile. Inatoa haki ya kutia sahihi vitambulisho, kwa hiyo lazima ikae kwenye backend yako pekee na haipaswi kamwe kusafirishwa ndani ya programu.

Fomula ya userHash#

userHash ni HMAC-SHA256 juu ya mfuatano mmoja wa utambulisho unaotiwa sahihi, uliosimbwa kama hex ya herufi ndogo:

Fomulatext
userHash = HMAC_SHA256( identity_secret, payload )

payload = userId          // ikiwa userId imewekwa
        = email           // vinginevyo, ikiwa email imewekwa
        = (invalid)       // ikiwa vyote viwili ni tupu, hakuna cha kutia sahihi
  • Siri ndiyo ufunguo wa HMAC; mfuatano wa utambulisho ndio ujumbe — si kinyume chake.
  • Tia sahihi mfuatano mmoja tu — userId ghafi (au barua pepe), bila salt wala kifunga cha JSON.
  • Ukipitisha userId na barua pepe kwa pamoja, tia sahihi userId (ndiyo yenye kipaumbele).
  • Matokeo ni hex (herufi 64 kwa SHA-256), si base64.

Mifano ya backend#

Kokotoa sahihi kwenye backend yako na umkabidhi programu userHash iliyokamilika.

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

// HMAC_SHA256(identity_secret, userId) kama hex ya herufi ndogo.
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");

// Hurudisha userHash ya kupitishwa kwenye Respondo.identify kwenye kliyenti ya simu.
function computeUserHash(identitySecret, userId) {
  return crypto
    .createHmac("sha256", identitySecret)
    .update(userId, "utf8")
    .digest("hex");
}
Pythonpython
import hmac
import hashlib

# Hurudisha userHash ya kupitishwa kwenye Respondo.identify kwenye kliyenti ya simu.
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
// Hurudisha userHash ya kupitishwa kwenye Respondo.identify kwenye kliyenti ya simu.
function computeUserHash(string $identitySecret, string $userId): string {
    return hash_hmac('sha256', $userId, $identitySecret);
}

Jinsi hash inavyofika Respondo#

Respondo haina endpoint ya utambulisho. Hakuna njia ya /identity ya kuita wala kitu cha kusajili. userHash ni uga unaosafiri ndani ya maombi ambayo SDK tayari inayatuma.

Hatua mbili, na ya kwanza tu ndiyo yako kuijenga:

  1. Backend yako → programu yako. Unafikisha hash kwa njia yoyote unayotaka. Chaguo rahisi zaidi ni uga wa ziada katika jibu la kuingia au la kuanzisha ambalo tayari unalirudisha — bila safari ya ziada. Endpoint maalum kwenye backend yako mwenyewe (mfano POST /myapp/identity inayorudisha { userId, userHash }) inafanya kazi vivyo hivyo. Respondo haiendeshi endpoint hiyo — wewe ndiye unayeitengeneza.
  2. Programu yako → Respondo. Hii inashughulikiwa kwa niaba yako. Mara tu unapoita identify, SDK huambatisha hash kwenye kila ombi husika na backend huithibitisha upya kila mara.
Mahali SDK inapoiweka (kwa marejeo — huhitaji kutuma haya kwa mkono)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

Hash hukaguliwa upya kwa kila ombi, haibadilishwi mara moja kwa kipindi kizima — ndiyo maana userId iliyoibiwa haisaidii chochote peke yake.

Ikiwa endpoint ya kufikisha hash kwenye backend yako bado haijajengwa, ombi la programu yako lenyewe hurudisha 404, identify haitwi kamwe, na gumzo huendeshwa bila utambulisho. Hiyo ni tabia inayotarajiwa, si kosa la Respondo — 404 kwenye njia yako mwenyewe ni kazi iliyosalia upande wako, si muunganisho ulioharibika.

Kupitisha utambulisho kwa SDK#

Chukua utambulisho uliotiwa sahihi kutoka backend yako, kisha pitisha userHash kwenye identify kwenye mfumo wowote:

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,
));

Tabia wakati userHash si sahihi#

Pale uthibitishaji umewashwa kwa wakala na sahihi haipo au si sahihi, backend hushusha kimya kimya hadi hali ya kutokujulikana: gumzo bado hufanya kazi, visitor_id huhifadhiwa, na mazungumzo hufungwa kwa mwasiliani asiyejulikana — lakini hakuna kiungo kwenda kwenye wasifu wala historia kati ya vifaa. Ikiwa mtumiaji "hatambuliki", karibu kila mara chanzo ni sahihi: hakikisha ulitia sahihi userId (si barua pepe wala JSON), ulitumia identity_secret sahihi, na ukatoa hex ya herufi ndogo. Ikiwa identity_secret ya wakala ni tupu, uthibitishaji umezimwa na userId / barua pepe hukubaliwa kama zilivyo.

Kubadilisha identity_secret kwa kweli ni mpito mkali: kila hash iliyozalishwa kwa siri ya zamani huacha kuthibitika mara moja, hivyo watumiaji ambao tayari wameingia hurudi kimya kimya kwenye hali ya kutokujulikana hadi backend yako ikokotoe upya na kuwapa userHash mpya kwa siri mpya. Badilisha siri pale tu unapoweza kusasisha upande unaotia sahihi ndani ya dirisha lilelile.