Type: Feature Request
Status: Contributed Solution
Affects Version/s: 6.1.0 CE RC1, 6.2.0 CE M3
Fix Version/s: None
Similar Issues:Show 5 results
LPS-4890 PortletPreferences may be at risk for concurrent modification issues LPS-14271 XSS issue when displaying social friend requests LPS-16689 Issue with Mutual "Add as a friend" request LPS-32915 Liferay's chat portlet throws NPE with some XMPP chat servers LPS-16823 Export pop up does not close after processing request in Trunk
We needed to use the latest trunk chat-portlet sooner than later, and as part of that, we had to make some modifications for it to work for us. Please let us know if these modifications could be added into the mainline trunk for 6.1 support.
Below they are described and included in a patch file, and hopefully these changes can be included/supported in the official 6.1 release whenever it comes out.
Please note the patch file also includes some service generation code which is not different than the trunk. The primary changes are all in the jabber.* package. and the main.js for 6.0 backport support.
In general our use case is that we needed to use it with Google Apps corporate accounts. Our users have corresponding accounts in our google apps corporate account and there are more than one @domainname (sub-domains) under our google apps account so assumptions currently in the trunk about all user's screen names existing within one domain, or screen name reliance only, does not work with Smack -> Google Talk for a corporate account.
Overall we are asking that configurable support for the changes we made be rolled into the planned mainline release of the chat-portlet so that we do not have to maintain our own branch of it.
OVERVIEW OF CHANGES WE MADE
(#1) Changed JabberImpl's sendMessage() to set the TO (destination user's) jabberId = the user's email address rather than just the screen name.
Can an config option be added for this behavior?
(i.e.) String jabberId = toUser.getEmailAddress();
(#2) Altered JabblerImpl.connect()'s Smack ConnectionConfiguration to set the service name equal to the user's email domain (right side of @) which is what is needed to work with google apps accounts.
Can an config option be added for this kind of behavior?
ConnectionConfiguration config = getConnectionConfiguration();
String serviceName = StringUtil.extractLast(user.getEmailAddress(), StringPool.AT);
connection = new XMPPConnection(config);
(#3) Altered the JabberImp.connect()'s smack connection login call to pass email address instead of screen name
Can an config option be added for this kind of behavior? Likely could read from the same config for the above.
connection.login(user.getEmailAddress(), password, PortletPropsValues.JABBER_RESOURCE);
(#4) Adjusted JabberMessageListener.processMessage() to retrieve the sender user by email address rather than screen name due to screen names being different (potentially) than the email for the user (which must match the jabberid MINUS the /resource). This change also added a new method on the Jabber interface: public String getEmailAddress(String jabberIdWithResource); plus on the implementing classes. Again the use of looking up by email might need to be controlled by a config property.
(#5) Adjusted the JabberImpl's getStatuses() method to fetch by email instead of screen name (same reasons as above) as well as catch Exceptions and do a null check in calls to "UserLocalServiceUtil.getUserByEmailAddress()" when a user returned by the XMPP server does not exist in the local liferay install. It seems legitimate that someone might connect this to an XMPP server where users in someone's roster are not in the local Liferay install. This should fail without error, (log/warn maybe) but not cause it to bomb out. Just filter the user from the roster returned. (i.e. _log.warn("XMPP Roster user: " + rosterEntry.getUser() + " not in local Liferay... skipping adding to chat roster..")
(#6) We front our liferay install via an SSO mechanism and have a custom AuthLogin hook implemented. Subsequently the LoginPostAction in com.liferay.chat.hook.events.LoginPostAction has no password available to us for Smack to consume in its login calls. We made a modification in our copy to fetch it via other means as Smack requires it.
*Please continue by looking at the attachments included in reading the description. The post was unexpectedly cut off.