Question about SSO and username/userslug uniqueness
-
@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)
