4 ms·
1. This is mostly MySQL's fault for default silently truncating values longer than the requested length. Postgres and SQL Server don't do this, but that's all I
by elchief 11y ago
1. This is mostly MySQL's fault for default silently truncating values longer than the requested length. Postgres and SQL Server don't do this, but that's all I tested
2. Lack of email validation by Bugzilla. Emails are max length 254, though this might not have been official when the code was written. See https://stackoverflow.com/questions/386294/what-is-the-maximum-length-of-a-valid-email-address https://stackoverflow.com/questions/386294/what-is-the-maxim...
3. Consider using an HMAC'd URL for registration email links instead of putting a token in the database, as per https://neosmart.net/blog/2015/using-hmac-signatures-to-avoid-database-writes/ https://neosmart.net/blog/2015/using-hmac-signatures-to-avoi...
- stinos 11y ago1. I copletely agree it isn't exactly the best design decision, on the contrary, but the developpers are still too blame as well in my opinion. They chose the datatype so they should have read the documentation, especially the caveats like this, and they should have done something to deal with this. This applies more generally. There are a ton of programming languages, standard libraries and APIs out there with weird/confusing/exceptional/undefined-behavior-invoking types and functions depedning on how they are used so a sane developper should alwyas check this and handle accordingly, even though it might lead to more code to handle edge cases than to the actual expected main code path.