Which means the app was crap. Rather the rules it used to validate a valid name are garbage.
Usually because someone tried to be too strict. E.g. names are space delimited A-Za-z strings, rather than just accepting any old Unicode string and safely processing it (e.g. with an SQL prepared statement).
I’ve had websites reject email addresses with one of the newish TLD’s because someone decided they new how to validate an email address (it’s more a more flexible spec than you might think).
Well then someone with a Tagalog name gets caught in your filter…
I mean if it’s “perfect” they yes, it’ll work, but in production…
Also, you sometimes want to be able to store “1); Drop table abc;” in your database, I mean how do you otherwise store this comment right here? Sanitizing.
I agree with everything in your comment except the last word. Only sanitize in cases where there isn’t a better option like html or terminal escape sequences. SQL had prepared statements, which are better.
That’s conforming (to what ever criteria). Send me a UTF-16 string of at most 100 code points. Send me a 7-bit ASCII string of only A-Z0-9. Reject anything that doesn’t comform.
sanitizing is trying to clean an input. That’s “lemme just double escape some special characters” or stripping/replacing/encoding characters or truncating strings, coercing types. Don’t do this, your sanitization code will have bugs or edge cases.
Don’t sanitise inputs. Reject non-conforming inputs entirely.
But otherwise: yes.
No fuck both of those, just use prepared statements so user input can’t be interpreted as SQL.
And end up having loads of valid requests rejected 😁
If they were valid they wouldn’t be rejected.
I’ve managed webapps which rejected “René”. Heck, my deadname has a hyphen, which often is considered illegal
Which means the app was crap. Rather the rules it used to validate a valid name are garbage.
Usually because someone tried to be too strict. E.g. names are space delimited A-Za-z strings, rather than just accepting any old Unicode string and safely processing it (e.g. with an SQL prepared statement).
I’ve had websites reject email addresses with one of the newish TLD’s because someone decided they new how to validate an email address (it’s more a more flexible spec than you might think).
Well then someone with a Tagalog name gets caught in your filter…
I mean if it’s “perfect” they yes, it’ll work, but in production…
Also, you sometimes want to be able to store “1); Drop table abc;” in your database, I mean how do you otherwise store this comment right here? Sanitizing.
I agree with everything in your comment except the last word. Only sanitize in cases where there isn’t a better option like html or terminal escape sequences. SQL had prepared statements, which are better.
That’s conforming (to what ever criteria). Send me a UTF-16 string of at most 100 code points. Send me a 7-bit ASCII string of only A-Z0-9. Reject anything that doesn’t comform.
sanitizing is trying to clean an input. That’s “lemme just double escape some special characters” or stripping/replacing/encoding characters or truncating strings, coercing types. Don’t do this, your sanitization code will have bugs or edge cases.
I’ll never conform!
Righteous.