Question about SSO and username/userslug uniqueness
-
So our auth is handled by a third party service provider, so they handle the uniqueness of usernames etc and give us a cookie which we use with the session sharing plugin to create Nodebb accounts using that cookie which populates the Nodebb Username with the Auth Provider Username.
I have a requirement for select groups e.g. internal staff to be able to change their visible username on Nodebb while having the Auth Provider Username still as their main username in their data. This is to prevent Bad Actors harassing users on the third party service.
My initial thought was to create a plugin that hooks in and alters the display name attribute of the user data which would work but the users userslug would still be a slugified version of the Auth Provider Username which would defeat the point of the display name. Could do with a display userslug or a hook in the getDataFromUserSlug methods to convert display user slugs to actual user slugs from a data map in a plugin. Could be a feature request to add such a hook if its considered a good approach?
Another thought was to allow Nodebb username editing but save the Auth Provider Username as a different piece of information on the user data record (for moderation visibility). The issue with this is if someone changes their username for example "A User 123", then a user on the Auth Provider Service joins our site with exactly the same username, then it would clash and cause errors or start adding an extra index to the name which isn't ideal.
Is there anything I'm missing that could do what I'm looking for or does anyone have another approach I can try.
-
U uplift marked this topic as a regular topic on
-
U uplift marked this topic as a question on
-
@julian said in Question about SSO and username/userslug uniqueness:
Hmm, that's a tricky one. We do have the "display name" property, which could be changed at will. The username and userslug would indeed stay unchanged.
The display name is optional, you can see @baris uses one, but I don't.
isn't "display name" property abusable? I was first excited about this, but after implementing it in our forum I quickly realized there is nothing stopping users from changing their displayed username -for example- julian , and using your profile picture and pretending that it is you that is writing... I immediately disabled it...
-
@crazycells hmm, that's interesting. That could certainly be problematic!
Bears thinking through...
-
@crazycells
point taken -
one way to overcome this could be "admin approval for the displayed name"
there can be another page like "post queue" , where all name-changing requests have to be approved to be on.
I can see this is being useful if people would like to write their full name ( we had this request before in our forum) , or if they want to write their name in a fancy way like @baris lol ... Other than these two reasons, admin can check if that name is being used by another user or not and then approve it or reject it.
-
@julian said in Question about SSO and username/userslug uniqueness:
Either that or the display name cannot be an existing username?
nope, this is still not good. I believe twitter had this problem before... some folks imitated other users with creative ways...
for example, this letter in Turkish "ı" can be written as "I" as capital which is different than the capital version of "i"... but it looks the same...additionally, it looks like the small version of "L", and so people can imitate other users...
additionally, the username list is an evolving list...
-
@julian said in Question about SSO and username/userslug uniqueness:
For what it's worth, even with admin approval, you see issues if a new user registers with a username identical to a used display name...
yeah, I guess it depends on the forum, but it is anyway better than the current situation...
At least, you would reject if someone is trying to switch to "julian"...additionally, if you bring admin approval, I would implement this in our forum and announce users that it is only possible to use it several ways that I have mentioned before (either personal name/full name or name with titles, or other styles of writing the current username) , I would not allow switching completely different username...
moreover, thanks to @oplik0 we recently had this plugin that will restrict similar usernames from being taken as new usernames, and planning to implement this in our forum soon:
GitHub - oplik0/nodebb-plugin-restrict-usernames
Contribute to oplik0/nodebb-plugin-restrict-usernames development by creating an account on GitHub.
GitHub (github.com)
restrictions for username selection
is it possible to restrict username selection for new users easily? let's say someone is registering as Michael, then nodebb assigns Michael 0 , Michael 1 , ...
NodeBB Community (community.nodebb.org)
-
@julian said in Question about SSO and username/userslug uniqueness:
Similar usernames! Interesting, using levenshtein distance I wonder...?
I think it is based on Sørensen–Dice coefficient...
-
Yeah, it's Sørensen–Dice - though note that it wasn't really some well considered choice - I implemented it as part of an assignment earlier and just went with it because of that. I thought it might do a bit better than Levenshtein distance from my quick reading of a few articles related to discriminating identity based on username which suggested substring based algorithms are doing better for that task (LCS/GST for example).
I'll probably add phonetic similarity to the mix in the future, and perhaps actually do some tests to see what makes most sense
(and the future is most likely February...) -
We had similar requirments and ended up with a worflow that allowed the user to change the username rather than the displayname. This works well because the userslug changes along with the username. We lock down the displayname attribute and use that as a holder for the original id. If I recall correctly, we had to modify the session sharing plugin to use the email as the unique identifier to lookup the user.
All the user profile changes are handled outside of NodeBB in our app so that's something to keep in mind. We also maintain a history of usernames, so no one can appropriate another user's username even as an alias or nickname. -
Yes but we have no way to know the id from the "outside" when authenticating while we do know the email so it made sense to use the email as the glue between the 2 systems. I suppose we could lookup the id when creating/signing the JWT but ultimately it balances out.
-
@razibal Sounds like we have similar setup but while our profile changes happen outside of Nodebb they also happen outside our website so we don't have a complete list of usernames to check against (unfortunately) otherwise what you describe is the route I would take.
-
@uplift this may or may not work, but the 2factor plugin listens for
response:router.pagein order to check if the user has passed 2FA check, and if not, redirects them to the challenge route.In your case, you can check the slug, and rewrite the slug as necessary (use
helpers.redirectinsrc/controllers/helpers.js)
