[BUG] LDAP e-mails in viewed in comma seperated numbers

[Wouter0100]

Description:

E-mails are viewed in comma seperated numbers. I have for example 2 e-mails attached to my accounts, sync'ed from LDAP:

When I overwrite my e-mail to be readable, on the next background sync it just becomes numbers again. Seems to be stored in binary or so. LDAP is correct and shows the mails in plain text.

Server Setup Information:

• Version of Rocket.Chat Server: 0.61.2
• Operating System: Ubuntu 16.04 LTS
• Deployment Method(snap/docker/tar/etc): Docker
• Number of Running Instances: 1
• DB Replicaset Oplog: Disabled
• Node Version: v8.9.3

Steps to Reproduce:

1. Sync LDAP user with Rocket.Chat

Expected behavior:

Syncs plain text email adresses.

Actual behavior:

Syncs binary or comma seperated list of numbers for email adresses.

Relevant logs:

�[34mI20180221-00:08:41.194(0) rocketchat_logger rocketchat_logger.js:278 �[34mLDAP ➔ Connection.info Connecting ldaps://ipa.*:636 
�[34mI20180221-00:08:41.213(0) rocketchat_logger rocketchat_logger.js:278 �[34mLDAP ➔ Connection.info LDAP connected 
�[34mI20180221-00:08:41.215(0) rocketchat_logger rocketchat_logger.js:278 �[34mLDAP ➔ Bind.info Binding UserDN uid=*
�[34mI20180221-00:08:41.219(0) rocketchat_logger rocketchat_logger.js:278 �[34mLDAP ➔ Search.info Searching user * 
�[34mI20180221-00:08:41.233(0) rocketchat_logger rocketchat_logger.js:278 �[34mLDAP ➔ Search.info Final Page 
�[34mI20180221-00:08:41.234(0) rocketchat_logger rocketchat_logger.js:278 �[34mLDAP ➔ Search.info Final Page 
�[34mI20180221-00:08:41.243(0) rocketchat_logger rocketchat_logger.js:278 �[34mLDAPSync ➔ info Import finished. Users imported: 6 
�[34mI20180221-00:08:41.244(0) rocketchat_logger rocketchat_logger.js:278 �[34mLDAPSync ➔ info Import finished. Users imported: 6

Using FreeIPA as LDAP provider.

[TwizzyDizzy]

Hi @Wouter0100,

where exactly is this to be seen? Your screenshot unfortunately doesn't show the broader context of where that is.

Cheers
Thomas

[Wouter0100]

@TwizzyDizzy every single place where the e-mail adresses are shown. The context of the screenshot was in my profile when clicking on my own user in the Administration section under Users, but it also visible in the livechat when showing e-mails to users, other lists and so on.

[TwizzyDizzy]

Thanks! Unfortunately I cannot reproduce your issue in 0.61.2. My users also come from LDAP (MS Active Directory).

Cheers
Thomas

[Wouter0100]

Hmm - thanks for testing! I also find this really strange, as at first it did work properly, but since some months ago stopped working properly (in earlier versions of Rocket.Chat, but I'm not sure which).

When looking into the DB it seems to be stored as a binary.

Could this also maybe related to the notifications issues we're seeing in #9755? Where for example a worker crashes when sending e-mail notifications, and does also not send the mobile ones (just some guess work, as I haven't looked into the code).

[TwizzyDizzy]

When looking into the DB it seems to be stored as a binary.

Are you sure? Usually the address is not of type binData but of type string (see my screenshot). Also what we're seeing in your screenshot is not binary. Terminology is important here.

As for #9755 and just from my gut feeling: I don't think so.

Cheers
Thomas

[TwizzyDizzy]

Could you, by any chance, add the actual email address (or parts of it) of that user? I have the gut feeling that those numbers might be some ascii or ascii/html representation of those characters. See here for example:

Cheers
Thomas

[Wouter0100]

Thanks for looking into this! Yes - it seems to be the printed ISCII indeed, because the first characters seems to match (wvanos). It has been some time ago when I looked into the DB, so I was not completely sure about the binary part, but it is:

When overwriting the e-mailadres in any place, it syncs back to the binary format the next sync.

So as far as we currently conclude: it's stored in binary (atleast, Robo 3t says so) and is printed in ISCII.

Thanks!

[Wouter0100]

When receiving the binary from Mongo, it's returned as follows:

{ "$binary" : "d3XXXXXXXXXXXXVdQ==", "$type" : "00" },

X'es replaced, but it's base64. Not sure if that's Mongo's way of returning binary data, but when decoding the base64 to text it matches my e-mailadress.

[TwizzyDizzy]

Hi @Wouter0100 ...

this is intersting indeed. I would first like you to add your MongoDB version (as will I tomorrow). As I see it, there are - in theory and assuming that my setup is the correct(er) one because for me it works - those possibilities:

• your address field shouldn't or mustn't be binary
• your address field can be binary and Rocket.Chat did decide to put that field type into place in your case because of X
• your address field can be binary and Rocket.Chat does something wrong when retrieving that data from MongoDB
• your MongoDB version "doesn't work" with Rocket.Chat (the official guide on Ubuntu installation mentions both "2.4 and below" and "2.6 and above) so I assume Rocket.Chat itself is somewhat version-agnostic when it comes to MongoDB? (though that would surprise me)

I think this is the right time to get someone from @RocketChat/core aboard.

Cheers
Thomas

PS: Apart from anything else: you "ISCII" seems to be no spelling error, what's its relation to ASCII?

[Wouter0100]

Hey @TwizzyDizzy, thanks. I'm running Mongo 3.6.2 in a Docker container, setup by a docker compose file - which in theory should be compatible, I guess.

As far as I currently understand Mongo, the field type is determined by Rocket and not explicitly set like a RDBMS. Because if this, as far I understand, the error is most likely to come from Rocket.JS or my LDAP which may serve the passwords in a particular way, which is interpreted as binary or so.

Ah, - ISCII wasn't a spelling error, more a mind-mistake as I thought it was written that way out of me head. I meant ASCII! 👍

[TwizzyDizzy]

As far as I currently understand Mongo, the field type is determined by Rocket and not explicitly set like a RDBMS. Because if this, as far I understand, the error is most likely to come from Rocket.JS or my LDAP which may serve the passwords in a particular way, which is interpreted as binary or so.

If that's the case ("field type is determined by Rocket"), then I agree with your assessment.

My MongoDB version is 2.6.12.

Cheers
Thomas