I ran into some trouble with the application when I implemented our own custom ChatProvider that inherited from the ChatProvider. What I discovered was that the application at times can imply an incorrect "UserId". I found a case of this in the sample code, and can witness similar issues coming from the encapsulated LiveChat assemblies. The two forms of UserId’s we would witness are: "User:LoginName" for authenticated users, and if the user is anonymous, then it returns "Guest:LoginName".
We ran into a problem where a user in the cross domain using the cross domain monitoring script would look like "Guest:LoginName", but when invited to chat by the agent, the user would become "User:LoginName" in the LiveSupport web site. The users chat room would be named "LiveSupport:Guest:LoginName" and then the chat window would show an error saying that the User or Agent needed to be in the chat room, and the user would show as offline in the agents chat UI.
We tried to fix this by Overriding the Virtual ToUserId(string loginName) method in the ChatProvider, and making all calls to the method ToUserId return the formatted sting of "User:LoginName". This caused more problems because we discovered that the application was not using this overridden method and was still implying the format "Guest:LoginName" on the user. So then we changed it to always return "Guest:LoginName" and that fixed the problem as long as we did not authenticate the user in .Net on the live chat site. If we do Authenticate the user, then the "User:LoginName" format is applied in the application and the same behavior as described before will occur in some case when coming across the cross domain.
Keep in mind the ChatProvider was implemented, and the LoginName is always correct. We were able to validate that the same AppChatIdentity was returned by the provider along with the correctly matching strings from both GetUserInfo methods. Regardless of the provider retuning the same values and objects in both the cross domain calls and the local domain calls, the application was still not always calling the ChatProvider for the UserId and creating (implying) it’s own userid based on whether they were authenticated in .Net or not.
Our current work around is to not authenticate the User on the live chat site, and to overide the method ToUserId, to always return a string formatted like "Guest:UserName".