Deploy
Identidad de usuario final
Que cada visitante vea solo sus propias conversaciones.
Sin esto, todos los visitantes de un sitio comparten el mismo historial. Con esto, cada uno ve solo el suyo.
El problema
Una clave de consumo identifica el embed, no la persona. Es publicable y es la misma para todo el sitio, así que no sirve para separar conversaciones: si el historial se acotara solo por clave, el visitante 2 vería el del visitante 1.
Cómo funciona
Es el esquema que usa Intercom. El backend del cliente —no la página— firma el id de su usuario con un secreto compartido, y el widget manda las dos cosas:
<ai-chat
end-user-id="usuario-482"
end-user-hash="EL_HMAC_CALCULADO_EN_EL_SERVIDOR"
...
></ai-chat>
// En el backend del cliente. El secreto NUNCA llega a la página.
const hash = crypto.createHmac("sha256", SECRETO).update(userId).digest("hex");
El servidor recalcula el hash y compara. Que el secreto no viaje a la página es
lo que impide que un visitante edite end-user-id y lea las conversaciones de
otro.
Se activa por clave, y solo al crearla
El secreto se genera al crear la clave y se muestra una sola vez, igual que la clave.
Cuidado
No se puede activar después. Encenderlo más tarde dejaría huérfanas todas las conversaciones que la clave ya abrió: no tienen usuario final, así que quedarían ocultas para todos. Y apagarlo desharía la separación que a sus autores se les prometió.
Si la necesitas y la clave ya existe, crea una clave nueva.
Qué cambia cuando está activa
- Una clave sin secreto funciona exactamente como antes. Los embeds existentes no se enteran.
- Una clave con secreto falla cerrada: sin un par válido, no hay petición. Degradar a «solo por clave» ante una cabecera ausente convertiría un error de configuración en una fuga silenciosa entre visitantes.
- El widget guarda la sesión por usuario. Sin eso, el caso de dos personas en el mismo navegador vuelve a entrar por la puerta principal: la primera cierra sesión, entra la segunda, y el widget restaura el id de la primera desde el navegador antes de preguntarle nada al servidor.
- El control de historial del widget aparece solo cuando el servidor reporta
que la identidad está en vigor — no cuando la página pone el atributo. La
diferencia importa: una página puede poner
end-user-idsobre una clave sin secreto, y ahí el servidor ignora las cabeceras. El servidor es el único que sabe si la identidad está activa.