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.

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.

@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?

@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.

@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

@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?

Hi all, 

As I read now, this problem has been around for a while over 2 years], has there been a good solution for this problem in the meantime?

If so, where can I find more information regarding the solution to the problem?