Some users don't have a username in the RC database

[chagai95]

I found 3 users in an old db we were using, but maybe there are more. Just wanted to mention this, but it was easy to exclude them, should I close this ticket?

[HerHde]

Indeed, I could find a user in one of our DBs as well, using jq -s 'map(select(has("username") | not))' < users.json.

Before closing, I should check the impact

[HerHde]

Now I finally added some end to end testing, including a user without username. This is exactly, where the script crashed: https://ci.netzbegruenung.verdigado.net/repos/938/pipeline/504/9

Now I want to handle them in the script. The question is what to do with these users? Warn and skip would be my go-to.

[chagai95]

Maybe add a config option to choose what to do? One thing I could imagine might be useful is to just generate a username either a random string or somehow use the name?

[HerHde]

Would that be helpful for your use-case? And do your affected users have a name attribute?
Another consideration is that some things reference these users by login name, so I'd expect a bit more effort handling them

[chagai95]

I'll check on that, I guess we'll need to decide.

[janonym1]

Would that be helpful for your use-case? And do your affected users have a username attribute? Another consideration is that some things reference these users by login name, so I'd expect a bit more effort handling them

We are using a keycloak for handling oauth and SSO login, so we could maybe fallback on the preferred_username attribute we get from there, when the name is empty.

preferred_username is usually a email-address: [email protected] but the @ sign is ugly when escaping, so maybe we should just use name.sirname prefix

[chagai95]

As you can see we are still not sure exactly how to handle this case, but these are some of the considerations, I'll update here when we have made some decisions. Maybe we can just create a PR then with some of the options that we would like.

[HerHde]

Hmm, using emails and slicing them up, using just the local part seems a bit naive, as many assumptions about email are in general. What if there are duplicates, then, like [email protected] and [email protected]?

Furthermore, our Use-Case is that LDAP or OIDC provides the synapse authentication based on the same login name. Slicing would not be helpful for that case, either.

Using the whole email does not work either, as User ID can only contain characters a-z, 0-9, or '=_-./+'.

We could check if the preferred_username is valid (for synapse) and use it then, otherwise throw a warning or fail hard.

[pierreozoux]

@chagai95 I have the same case, and we are migrating with keycloak, so, I actually want to map keycloak username, and not rcUsername...

look at: #10

(I actually did a lot of research to slice emails, normalise username in keycloak...find users with same username, how to avoid new user to create doubles... a big rabbit hole...)

hope it helps!

[HerHde]

@pierreozoux would it be sufficient to use preferred_username for that case?

[pierreozoux]

It is what I did :)

In fact, I used a transformation on preferred_username that I also implemented in Kc, and then synpase use this.

[HerHde]

Ah, sorry. I missed that line and basically, where the attribute is coming from. 😅

I'll review #10 and see how to adapt it for general usage, thank you!

[svenseeberg]

I think this is probably a highly individual problem and it will be difficult to catch all cases in the migration script. In my opinion we should assume that we use one attribute for the migration and that it contains a valid value for all users, for example username. Choosing another attribute should be possible with https://github.com/verdigado/rocketchat2matrix/pull/10/files, which I find a useful option.

I think it would be best to simply update the MongoDB with the necessary attribute. As this is done right before the migration, it should not interfere with the RC operations (if it would be a problem at all even while RC is running). The sanitation of the MongDB could look like this (not tested):

db.collection.updateMany({ username: { $exists: false }}, { $set: { username: { $trim: {input: "$name", chars: " " }}}})

And if different OIDC or SAML attributes are used in Rocket.Chat and Matrix to map the Keycloak users, it is easily possible to update the user_external_ids table of matrix-snapse. The rows have the following format:

auth_provider  external_id                           user_id                                     
-------------  ------------------------------------  -----------------------------
oidc-keycloak  6e93f496-917e-4bbf-852e-7e3d999b2006  @test.user:matrix.example.com

You can enter whatever attribute you need to map in external_id.

[railsmechanic]

Thank you very much for the idea. We have connected RocketChat to Keycloak and therefore need the username from Keycloak as the username for Matrix. I have developed a script that processes the JSON files generated by mongoexport and replaces the RocketChat username with the username from Keycloak. This way, the migration worked smoothly. It was even unnecessary to make the corresponding entries in the user_external_ids table, as this is done automatically upon login (when Keycloak is configured for authenticating users).