You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Widget: fetch signed-in visitor tokens when a session is requested #461
The widget accepts userToken as a fixed string and sends it when requesting a session. A page can stay open for a long time before the visitor opens the chat, so a short-lived signed token may expire before the first /session request. The server correctly rejects expired identity tokens, but the host page currently has no way to provide a fresh one at that point.
What would you like to happen?
Add an optional async token provider (or equivalent callback) that the widget calls when it is about to request /session, so the host can return a current signed token. Keep the existing string userToken behavior backwards compatible, send the resolved token only to the configured ChatCops API, and document that signing secrets must remain on the host server. Add tests for fresh tokens, provider failures, and the existing static-token option.
This makes sense too, @piyusshhjangid. Today the token is a string, either userToken in the config or ChatCops.setUser({ token }) (packages/widget/src/api/client.ts:54). It's sent when the widget asks /session for a token (client.ts:141). A page can call setUser again with a fresh token, but it doesn't know when the visitor will open the chat, so a callback the client awaits right before that /session request is the right shape. For example, userToken: () => Promise<string | undefined>, with the string form still accepted.
Things to cover:
a callback that throws or times out: start the session without the identity, and log it, so the chat still opens
calling it once per /session request, not per message
docs on widget/api.mdx next to setUser
Same size note as #460: the panel has about 400 B left. Say if you want it.
Hey @anurag629, could you please add the Hacktoberfest label to this issue? I'd love to work on it after resolving #460. I'd appreciate it if you could assign this issue to me.
@piyusshhjangid, with #55 and now #460 you're at the two-issue limit, and @Saifjafri212213 asked for this one with a free slot, so it goes to him. If he passes, it's yours after #460.
Thanks @anurag629, I'd like to take this one. I have a free slot (#405 was just merged). Could you assign it to me? I'll start once it shows as assigned.
Activity
anurag629 commentedon Oct 29, 2026
This makes sense too, @piyusshhjangid. Today the token is a string, either
userTokenin the config orChatCops.setUser({ token })(packages/widget/src/api/client.ts:54). It's sent when the widget asks/sessionfor a token (client.ts:141). A page can callsetUseragain with a fresh token, but it doesn't know when the visitor will open the chat, so a callback the client awaits right before that/sessionrequest is the right shape. For example,userToken: () => Promise<string | undefined>, with the string form still accepted.Things to cover:
/sessionrequest, not per messagewidget/api.mdxnext tosetUserSame size note as #460: the panel has about 400 B left. Say if you want it.
piyusshhjangid commentedon Oct 29, 2026
Hey @anurag629, could you please add the Hacktoberfest label to this issue? I'd love to work on it after resolving #460. I'd appreciate it if you could assign this issue to me.
anurag629 commentedon Oct 30, 2026
@piyusshhjangid, with #55 and now #460 you're at the two-issue limit, and @Saifjafri212213 asked for this one with a free slot, so it goes to him. If he passes, it's yours after #460.
Saifjafri212213 commentedon Oct 30, 2026
Thanks @anurag629, I'd like to take this one. I have a free slot (#405 was just merged). Could you assign it to me? I'll start once it shows as assigned.
anurag629 commentedon Oct 30, 2026
Assigned, @Saifjafri212213. The pointers are in my comment above. Mind the size: after #468 the panel is at 17.02 of 18 kB.