3 ms·
is it wise to just take this list "as is" as a black list for, say, valid usernames, on a backend system ? are there any drawbacks to this that i can't think o
by frankmoodie 10y ago
is it wise to just take this list "as is" as a black list for, say, valid usernames, on a backend system ?
are there any drawbacks to this that i can't think of ?
in terms of perfomance - i guess it could be somehow optimized (with dictionary and sorting algorithms etc etc)
edit: newlines
- detaro 10y agoNot really, since a lot of the lines are examples of classes of input -> good for testing, but if you have an actual problem with one of them blacklisting them only protects you against this single example.
- manarth 10y agois it wise to just take this list "as is" as a black list for, say, valid usernames? I interpret this as a list of input that you should accept, and it's test-data to verify that the input is correctly handled. After all, I imagine Linda Callahan would be upset if she couldn't use her name when registering, especially if she couldn't flip a table in comments afterwards. (╯°□°)╯︵ ┻━┻)
- andrewaylett 10y agoDefinitely not -- these are examples of classes of strings that should be OK but might potentially cause issues, that can be used for testing. But the issues they might cause are not all malicious: some are people's names, added to the list because an over-zealous profanity or offensiveness filter once choked on them. So my suggestion is that you shouldn't block any of the strings in this file, but should use the file to make sure that your code works successfully when any of the strings are given. Where "successful" is naturally dependent on context: you may have a policy in place that says that messages may not consist solely of whitespace, so the correct response to receiving any of the whitespace strings is to return the correct error to let the user know that, avoiding Twitter's example of an internal server error in that case.