Webchat 4.0.0 source code

Openfire Plugins FastPath Web Chat
1

I am having a problem with webchat and openfire. I get an error in the logs

"WARNING: Error joining room:

No response from server.: "

This only happens when certain characters are entered in the name field in the webchat

For example. The following characters will cause a chat to fail: “¸”

I need to source code so i can debug the problem.

I am trying to checkout the webchat source code for version 4.0.0 .

I have gone to http://svn.igniterealtime.org/svn/repos/fastpath/webchat/ but the only code available is that on trunk. Both branch and tag folders are blank. How can I get the version I need?

Also I had a look at the jars in the .war file at /WEB-INF/lib/ and need to know what version smack and smackx are used here?

2

It looks like the client isn’t connecting because it’s waiting for a response from the server with its exact name, and the server has mutated the name due to an incompatability with “¸”.

I’m guessing this was simply an oversight, but nicknames should really be escaped for XML using the included StringUtils class. (This function filters out “bad” characters like <, >, /, etc. and also handles Unicode characters (like “¸”)).

This is an important bug for english users too, since a very knowledgable user could inject XML into their nickname, and given enough knowledge of the packet structure (obtained from a simple packet capture) they could cause issues.

But, fixing that issue didn’t solve the problem, and it seems the root cause is that the server doesn’t like that character. Here’s an excerpt from my server log with my domain censored:

C2S - RECV (20577663):

C2S - SENT (20577663): <x

As you can see, the server receives the character correctly, but when it sends it out, it’s garbled, and doesn’t match the incoming name (so it’s ignored by the client).

Since I don’t know a sufficient ammount about the server’s packet routing (and don’t feel like tracing this all the way through), I’ll simply suggest a sort of “band-aid” fix to the issue, which is to make the client’s filter more lenient. Instead of requiring that the server respond with their exact nickname, only require that the response contains the room name and a slash (so the response nickname could be ANYTHING).

You’ll need to make these changes to Smackx\muc\multiuserchat.java:

add after line 46: import org.jivesoftware.smack.filter.FromContainsFilter;

now change the following lines:

line 343: new FromContainsFilter(room + “/”),

line 482: new FromContainsFilter(room + “/”),

line 1004: new FromContainsFilter(room + “/”),

Recompile smack. Copy smack.jar, smackx.jar, and smack-debug.jar to your webchat source folder (more specifically, webchat\trunk\src\webapp\WEB-INF\lib) and overwrite the old jar’s. Recompile webchat and deploy it to your app server. (you’ll need to reconfigure your settings, or copy chat-settings.xml from your old deployment).

The clients can now connect, but there are a number of remaining bugs. Clients with “¸” will see double messages but the agent will not (nor will “normal” clients), and the name of the client will be garbled (see results below):

Additionally, the agent’s name got mixed up with the client’s name in the “you are now chatting with” (only for “¸” clients)

You are now chatting with test ̧

Jeff: YES!

test¸: YES!

test ̧: YES!

test¸: what?

test ̧: what?

Ideally, I could find where in the server it is mutating the customer’s name. Can you tell me if agents have this same problem if their name contains “¸”?

3

Hello. Thanks for the answer. What logs did you see the presence xml ?

C2S - RECV (20577663):

C2S - SENT (20577663): <x

I could not find the presence information in any of my logs. I get the same problem if the agents have a name that contains “¸”

I have the openfire source. I can help find the problemWhere do you recommend I start to look?

Thanks for you help

4

I found the function in Tinder that escapes certain characters from JID’s. It’s in org.xmpp.packet.JID. I’ve created a patch file since the edits are a bit more complicated this time (but not much). See the attached file. )If you don’t have the tinder source, you can get it here http://svn.igniterealtime.org/svn/repos/tinder )

It should fix the root problem, and you can reverse my earlier webchat “fix”.

Recompile Tinder, put it in openfire’s build/lib/merge folder, recompile Openfire, and you’re good!

Let me know if you need any other characters escaped in a similar fashion. (or to look them up yourself, use this link and convert the decimal values it gives to hex: http://www.w3schools.com/tags/ref_entities.asp ex: ¸ for cedil becomes b8)

Also, to answer your other question, I’m running Openfire as a Windows Service, so my stdout (text that would display in a console) is directed to a log file (automatically). It’s also possible that there is a log level setting somewhere to show C2S SENT and RECV messages in the log. (mine just always has).

I’m very excited to get this fixed since I spent a decent chunk of time on it, and it helps you out. I’m not sure how handy it will be for us though, and it adds overhead to JID parsing…

If you find that agents still can’t login with a cedil, try also escaping/unescaping node. (ex: if (!(node == null)) resource = escapeNode(node); )

Always glad to help!

Jeff

Edit: I also attached my JID.java file in case you find the patch file too confusing.
JID.java.zip (6152 Bytes)
JID.java.patch.zip (894 Bytes)

5

Thanks for your help on this Jeff. What version of openfire are you using? I’m on 3.6.4

I have found a bunch of characters which don’t work. Will I have to edit this file for all the characters I find?

I’ll let you know you know how it goes.

Cheers,

Chris

6

Hey Jeff. I had a look at this yesterday and also applied your patch but it didn’t work for me. When examining this presence element I found that the “¸” was direct under the quote. Which is strange. I tracked this back to the StanzaHandler class (openfire/net/StanzaHandler.java). It looks like the problem happens after the DOM object is created.

Element doc = reader.read(new StringReader(stanza)).getRootElement();

It may be a problem when it parses the *stanza *string so I am investigating this now. If I can find a fix in the parser it might also fix other chactacters with the same problem.

I hope you are able to have a look at this area of code with me to help find a solution.

7

I’m running version 3.7.2 (fresh off SVN). It looks like Tinder was moved out of Openfire in version 3.7.0beta. (see http://issues.igniterealtime.org/browse/OF-1). So it’s likely that your version doesn’t know what to do with Tinder (since it didn’t exist before 3.7.0) You may be able to track down the code that was taken out of Openfire and replace it there (instead of using Tinder).

I don’t know much about 3.6.4, sorry.

Jeff

8

Hello Jeff. I have managed to fix the problem.

I got your patch working which worked great however there were a lot of character that didnt work. Having a massive switch and if statement would not do so I came up with a solution to cater for any character. The main problem I came across was with 3 or 4 byte characters. For example. The symbol ’ ˘ ’ should be encoded as \2d8 .

I have attach JID.java which has my solution.

To fix this character problem I ensured that the escapeNode and unescapeNode method could handle any character size. I also done a bit of refactoring to make the code more efficient and flexible.

Could you look at the changes I made (particulary the escapeNode and unescapeNode methods) ?

If you are satisfied with the changes then they should be commited to the product.

Thanks for all your help with this and I look forward to your reply to my solution.

Chris
JID.java.zip (5271 Bytes)

9

I agree with the change to an array of chars to escape. Maybe you could add some comments to explain that the second set of slashes is to delimit the escaped character (it makes sense when you consider your mention of 4 byte chars).

Also, it looks like you moved stringprep. Any reason?

Lastly, you might look into these improvements made to JID that were affected by your changes. The overal performance is greatly affected by the efficiency of JID processing and caching.

http://issues.igniterealtime.org/browse/JM-1210

http://issues.igniterealtime.org/browse/JM-1453

Perhaps the final solution will be a plugin or different “international” release that has support for extended character escaping.

I haven’t done any testing on the efficiency of the JID class. It’ll be interesting to see what those dev’s think of your changes.

Jeff

10

Hey Jeff. Thanks for the feedback.

The only change I made was to the escapeNode and unescapeNode methods and not stringprep. I am using openfire 3.6.4 so it maybe different in your version if you are using latest.

As I’ve only made changes the escapeNode and unescapeNode and not stringprep so will there actually be performance issues?

Would be great if you could get back to me oin what the dev’s think.

Chris

11

Hello Jeff. Have you got any update on whether my fix will be going into the product? I am about to move onto something else so is there anything you would like me help out with regarding this problem?

Cheers,

Chris