search

RocketChat / Rocket.Chat

The communications platform that puts data protection first.
https://rocket.chat/
Other
40.37k stars 10.48k forks source link

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

Open Wouter0100 opened 6 years ago

Wouter0100 commented 6 years ago

Description:

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

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:

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:

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

Using FreeIPA as LDAP provider.

TwizzyDizzy commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

Cheers Thomas

Wouter0100 commented 6 years ago

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 commented 6 years ago

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.

image

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

Cheers Thomas

TwizzyDizzy commented 6 years ago

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:

ASCII table

Cheers Thomas

Wouter0100 commented 6 years ago

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:

image

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 commented 6 years ago

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 commented 6 years ago

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:

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 commented 6 years ago

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! :+1:

TwizzyDizzy commented 6 years ago

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