I’‘m considering using wildfire as communication server, but I already have a user database. Although I had to write my own user/auth/group providers because of numerous reasons (like the fact I’‘m using DES3 encryption for the passwords), this wasn’'t a problem. The real problem is, that my usernames are case sensitive, and wildfire is widely lowercasing everything. For me, this is a total showstopper ! Is there a plan to solve this in some way ?
Another aspect of this : shall I expect the same problems with Smack, if I use it to build a custom client ?
+Node identifiers are restricted to 256 bytes, They may contain any Unicode character higher than #x20 with the exception of the following:
#x22 (")
#x26 (&)
#x27 (’’)
#x2F
#x3A (
#x3C (<)
#x3E (>)
#x40 (@)
#x7F (del)
#xFFFE (BOM)
#xFFFF (BOM)
Case is preserved, but comparisons will be made in case-normalized canonical form.+
I have some user names that contain underscores and others (exclamation marks etc.) and Wildfire complains with “Invalid JID” about them. Do you know why is that ?
As others have mentioned, the server conducts comparisons (for routing and store-and-forward) based on a string-prep version of the JID. The string-prep is rather complicated but for good old US-ASCII it boils down to case-insensitive matching - I don’'t think Wildfire actually carries out the full string-prep but does do case insensitive matching that catches ~99% of actual cases).
You can go into the code and look at the source for JID handling and write some test cases to see how it affects your JIDs:
Note that the code is in the Whack library repository, not the Wildfire repository. Wildfire relies on Whack for it’'s XMPP handling.
As for your particular problem, you should be able to work around wildfire by making your custom user/auth provider smarter. Usernames coming from Wildfire should be assumed to be string-prepped. To do a proper comparison, have your system automatically convert your backend’‘s usernames into wildfire usernames using the JID class. Usernames you provide to Wildfire should also be string-prepped using the JID class. Finally, you can setup your own transcoding from unsupported characters to a wildfire representation (e.g. always translate unsupported characters to the ‘’_’’ underscore character before stringprepping). The trick for your provider is that when you receive a request for "matt@domain.com" you’'ll need to search for any account that contains any case version of “matt” as a username - and your algorithm for how to generate the variations during the search will determine what accounts are “favored” by your provider. (see paragraph below)
The ‘‘kicker’’ is that wildfire will treat string-prepped usernames as equal - but if your backend thinks they’‘re different you could have weird behavior. E.g. sending XMPP IMs to Matt@domain.com and matt@domain.com will all get delivered to matt@domain.com within wildfire (wildfire thinks they’‘re one account), and Matt@domain.com will only be able to login to the matt@domain.com account since Wildfire will always request a login to the lowercase (stringprepped) version of the username. This essentially means that Matt@domain.com won’'t exist in Wildfire even though he may exist in your backend system as a separate account. And possibly confusing, if you delete the matt@domain.com account in your backend, wildfire will magically start working for Matt@domain.com since your custom provider will now automatically find Matt@domain.com.
If you can be a username czar, you can eliminate the problem by enforcing an XMPP compatible username for all users and forcing users with “bad” usernames to change them.
Another way around the whole mess is (if possible) to create another “XMPP username” field in your backend system for each user account. For most of your user accounts (I’‘m assuming) you can automatically provide and keep synchronized a unique XMPP username based on their normal username (a lowercase, stringprepped version of their username). For ambiguous usernames (where you have a Matt and a matt user account) you’‘ll gave to generate some sort of new unique XMPP username, (e.g. you could make all lowercase usernames the same, and any username with capitols gets lowercased and add a ‘‘1’’, ‘‘2’’, etc to the end of their names so they have something unique. For those users affected they’‘ll have a different XMPP username than their normal username (presumably you’‘re using that for email too). But that’'s probably a better tradeoff than not letting them login at all.
Oh, I should add to this a note: Wildfire is not be unique in it’‘s failure to tell the difference between usernames that are equal after running string-prep on them (e.g. differs only in case for us-ascii). JID equivalence Wildfire uses is the XMPP standard for username matching - “matt” == “Matt” in all cases. So you’‘ll have to do something like what I described if you want to use these “odd” usernames in XMPP no matter what server you use. It’‘s not something that can be “fixed” (I don’‘t see the XMPP standard being changed). Since most email systems also are case-insensitive (and XMPP and email usernames are typically shared), I’'m not sure of the benefits of supporting separate user accounts with usernames differing only in case.
The string-prep is rather complicated but for good old US-ASCII it boils down to case-insensitive matching - I don’'t think Wildfire actually carries out the full string-prep but does do case insensitive matching that catches ~99% of actual cases).
Actually, we are doing full string-prep – it was a major pain to implement.