candy-chat / candy

JavaScript-based multi-user chat client for XMPP.
http://candy-chat.github.io/candy
MIT License
1.32k stars 370 forks source link

Users with spaces #17

Closed jeotic closed 12 years ago

jeotic commented 13 years ago

Created a few mock users with spaces in their user name. This is allowed in OpenFire, and to make sure it wasn't just a bug with OpenFire, I used their client Spark to test them out. It is a valid username. Candy does not allow logging in with a user name with any spaces; at least not from my testing. It would be a nice feature to be able to do so.

pstadler commented 13 years ago

Please try to replace spaces with %20 (in Candy, not on server side) and tell me the result. If this works we should escape spaces automatically.

jstressman commented 13 years ago

Correct me if I'm wrong, but aren't spaces in a JID forbidden by the spec?

http://xmpp.org/rfcs/rfc6122.html#nodeprep-prohibited

The Prosody devs are actually looking at a way to handle this automatically in case of situations where authenticating against an external auth database etc, where users might have spaces in their names in spite of violating the spec, in which case they would be automatically translated into a conforming form (ie; replacement with non-violating char, escaping using valid methods, etc).

lboynton commented 13 years ago

http://xmpp.org/extensions/xep-0106.html

jeotic commented 13 years ago

Replacing spaces with %20 didn't work, but replacing spaces with \20 did. The name in the chat room is not the proper user name. It seems the display name has it's spaces replaced with "\5c20" (no quotes). It is not only Candy that has the user name appear that way, Spark does the same but with one less backslash.

BTW, if anybody was wondering, I'm not using an external database, or even a LDAP. Just using the internal DB that comes with OpenFire. All my users are managed through OpenFire.

jeotic commented 13 years ago

After logging in, I tested out the private chat. Private chat works great for single, non-spaced named users, but not for users with spaces. For the user with multiple spaces, initiating a chat will kick you out. For a non-space user, like admin, it will create a new tab, but not a new chat window. You cannot click on the tab, to either switch to it or close it out; although on first creation you can click out.

pstadler commented 13 years ago

It's interesting that they don't use standard URI encoding.

We should make sure that Candy works with special characters defined in XEP-0106.

Trandel commented 12 years ago

Any updates on this issue? I made a workaround for my users and changed thier spaces into dots "." and now Candy works, but it's not a good solution :)

jstressman commented 12 years ago

Trandel: Which xmpp server are you using? I believe ejabberd does the spaces/dots conversion stuff automatically. For instance "Joe Bob" can log in with "Joe.Bob" and ejabberd will handle the dot to space conversion automatically.

The Prosody guys wrote up a plugin (as part of mod_auth_phpbb3.lua) that uses xmpp escaping per the spec. So the users end up with \20 instead of a space etc. This plugin also handled several other "common" characters in our username database that were in violation of the xmpp spec for allows chars in JIDs.

I guess my question here is as to whether or not this should be done on the client or the server end? And if it is done on the server end, which at least 2 servers can do, or do, then how will Candy handle that etc.

For instance the \20's in the usernames break PMs. (I mentioned this in bug #30 on here as well.)

Trandel commented 12 years ago

@jstressman I use OpenFire and it's not auth problem. I use php pre-bind for the connection and then attach it to Candy, the problem is with those \20's that breaks all the funcionality. I didn't find any fix to change those \20's to normal spaces.

I can't afford to show users with dots because i use candy in my MMO via www and the nick is used in game engines as well, like profile pages. If some user will put the names with dots he woudn't fine any maching profile etc.

pstadler commented 12 years ago

XEP-0106 is an extension and not obligatory implemented by the servers.

We're still not sure if (and how) we should implement this. We could just make sure that escaped JID's work when received but we should probably also escape those entered in the login field / passed to the connect() method.

Trandel commented 12 years ago

I know it's not an easy task i tried to somehow replace it but i failed. Maybe You can point me how to change only the display in Rooster list, thats the most important place where i need spaces. I can live with dots in private tabs ;)

mweibel commented 12 years ago

I just saw that Strophe.Js has an "escapeNode" function. Maybe we could use that: http://strophe.im/strophejs/doc/1.0.2/files2/strophe-js.html#Strophe.escapeNode

Trandel commented 12 years ago

The function looks optimistic :) but do we need to escape string in view and unescape the same string when sending data to serwer?

mweibel commented 12 years ago

That's a good question ;) I'm currently trying to figure that out :) Maybe it's only necessary to do it in the view, but I'm not sure.

mweibel commented 12 years ago

Please take a look at the branch "issue-17-xep-0106" and try it. I hope it works. It's just a quick fix I made, maybe it needs some polishing.

Trandel commented 12 years ago

the name is showing correctly on users list, but when i click to send a private message then it stops working like in the beginning.I see a good escaped name in the tab but i can't write to that user and i get a "404 Invalid SID error".

Trandel commented 12 years ago

Maybe the problem is that the tab with param data-roomjid="" has a unescaped nick with additional "\".

mweibel commented 12 years ago

@Trandel: I fixed those things, please try it with the latest version of branch "issue-17-xep-0106". Thanks :)

Trandel commented 12 years ago

The PMs works!!! :D Thanks a lot, ill be customizing candy so i will have a lot of time to check it all. Looks good at first sight.