Answered

Messenger cookies problem. User data being exchanged

  • 8 March 2022
  • 6 replies
  • 255 views
D
  • Davi
  • New Participant
  • 1 reply

Guys, we have the following problem in the chat integration:

 

We are a SaaS e-commerce platform, so we want to use chat for non-logged-in users (leads) and users logged into your store dashboard (users). For logged in users we are sending the account data to Intercom (email, telephone, name, company name).

 

The problem is a cookie that intercom stores in the user's browser and is stored for a few days. We have merchants with more than one account on our platform and when they enter both accounts the data is exchanged within the intercom. The name of account A goes to account B, in the company of account A a user is created with the data of company B. How can we solve this problem?

icon

Best answer by Eric Fitz 9 March 2022, 13:52

View original

6 replies

Eric Fitz
Userlevel 1

Hey @davi​, when your users log out of their accounts, are you calling the Intercom('shutdown'); method in JavaScript? This should clear the session and prevent this issue from happening in future.

D

That's the problem. In our system, casa conta has an independent domain, for example:

 

​

 

account1.sistema.com and account2.sistema.com. So we have users who have two accounts, with different emails and links but are logged in at the same time. So he doesn't usually leave the account to enter another one.

U

@eric f11​ That's a design oversight on the Intercom part. Session cookie shouldn't have its domain trimmed down to the second level (e.g. to the ".sistema.com" in the above case), it should use the full domain name (".account1.sistema.com"). Trimming full domain name to the SLD effectively prevents using Intercom widget in the SaaS platforms. Calling Intercom('shutdown') doesn't really solves anything because as @davi​ described, there are situations when user can have two or more tabs open for separate accounts with the same SLD.

 

Can this domain name trimming turned off or made configurable with some window.intercomSettings flag?

U

@eric f11​ Hi, we are facing similar issues. It will be great if domain name trimming can be turned on or off so that we can cater to situations where we need to contain the cookies and user history to a subdomain. Thank you.

U

@eric f11​ ​ Please escalate this. Your own domain structure suffers from this. See the attached image.

  • I am not logged into forum.intercom.com, as you can see from the Log In to Answer button
  • I am logged into app.intercom.com because I closed the tab I was using the Intercom App with, which is standard user behaviour (compounded by the fact that Intercom App's logout button is hidden behind an initial click, in the bottom-left corner which is not expected UI, but that is not my complaint here). This is only one example of legitimate ways a cookie may exist that should only exist for one full domain and not another, and one example of a case where shutdown may not be callable. Forcing logouts and calling shutdown does not make when there are different systems and different authentications on different subdomains: why would a user be required to log out of system X in order to use system Y? How would they even know of this requirement?
  • forum.intercom.com is a separate system, I'm required to OAuth myself before being able to write this message, even though I can access any historical chats in the chatbox, or initiate new ones.
  • The forum does not consider me to be authenticated, and yet the chat does
  • I should not be considered to be authenticated to chat if the underlying page does not consider me to be authenticated

 

nonanon 

S

@eric f11​ 

 

Just going back to the original point about the cookies.

 

When we call Intercom('shutdown'), it doesn't end the remote session. It deletes the cookie on the browser but using cURL we can access the chat data from any device (even when identity verification is enabled). 

 

Are we doing something wrong on our side or is this a known weakness?

 

Reply


Terms & ConditionsCookie settings