ctm
commented
3 months ago I'm going to go the newtype route. I'll have to look up how to do a custom deserializer.
As for detection of invalid strings, It seems to me the first step is running it through UnicodeNormalization::nfc and then either disallow it if it
- includes a
NonspacingMarkor - it's not either alphanumeric, an emoji or an ascii space.
The latter is more restrictive but also prevents confusion from people adding punctuation like "," or "?" So far, those haven't been abused, but there is a "Not, Sure" who would have to become "NotSure", "Not Sure" or some other variant. Even allowing ascii spaces invites tomfoolery, but hasn't been abused yet.
Detect zalgoed usernames and completely reject them.
This is similar to what I just did with chat (#1341), but instead of dezalgoing and moving forward, it's better to disallow the creation since there's no point in cluttering up the database with an account that is unlikely to be used.
The implementation should be trivial: just see if the username and the dezalgoed username are different and if so, send back an error.Although there's a trivial solution, it may make sense to use a newtype or two and have restrictive constructors and de-serializers so that the server simply can't even accept Zalgo text inside a nick. We can then do detection on the client as well. The nice thing about doing it via a newtype is that we don't have to worry about someone later adding code that winds up using a String that can be Zalgoed, and we're already using newtypes for some other similar functionality, so doing it this way tends to push things in the right direction.
FWIW, I haven't made up my mind and I have some non-programming things to attend to now, so I may change my mind before I write any code (or change it after…)