41–50 of 231 posts
Why would you write a general function that resets an account password but also accept an email address as a parameter? What use-case exists to change the email address sending the message?
The likelihood of such a “hack” happening using the Turkish dotless “I” is ZERO as all Turkish email addresses and website domains are formatted WITHOUT using Turkish characters which include examples like: ç, ı, ü, ğ, ö, ş, İ, Ğ, Ü, Ö, Ş, Ç If you are at interested in Turkish characters: https://en.wikipedia.org/wiki/Wikipedia:Turkish_characters https://www.turkcebilgi.com/türkçe_karakter This should be called the T…
I love Unicode, but I'm more and more coming to the conclusion that strings are evil and should be treated as opaque byte arrays, whose only available operation is rendering into a bounded area. I now see any other string operation as code smell. It's scary how much of our infrastructure relies on strings, given how few guarantees string operations actually give. Take files names, for example. Two visually identical…
Now take all that and multiply by the complexity of world languages, many which don't even map to one glyph == one morpheme. The ol' apple message crash bug was due to the property of some Arabic not being monotonic in rendering space vs string length.
I think we could have skipped utf8 and just gone to 4byte runes. But even then, that would not have avoided the above bug.
Utf16 is a hot mess though, worst of all worlds.
Now that I think about it as far as I remember the local part of mail is actually not defined as cases insensitive , through all? mail programs treat it as such. The important part her is to always use data from your database for any security relevant parts.
Earlier quoted context omitted.
I am well aware of that, but I'm comfortable requiring that new customers don't register an account with an email address foolishly designed to resemble another customer's email address in this particular way. We don't throw away their specified mailbox address, we just don't accept registrations which look suspiciously similar, or intended to cause confusion. I repeat, this has absolutely nothing to do with the mail…
You can't decide for yourself what the semantics of someone else's address do or do not mean.
You can't break user expectations and mental models by pointing to the spec as justification. The spec exists to serve users, not the other way around.
The examples in the initial "quick example" are backwards, no? It's `'ß'.toUpperCase()` that is `"SS"`, not `'ß'.toLowerCase() === 'ss'`. As the later chart makes clear. Same with turkish ı.
Unicode actually has an uppercase ß though I don't understand why.
So if I understand this right, what GitHub did was something like: user = get_user_from_valid_email(params[:email]) send_reset_email(params[:email]) # instead of # send_reset_email(user.email) ? I've seen this pattern before and the reason is usually something about using the variable in memory as opposed to the function call. Total non-optimisation.
We use three versions of the email address internally: the exact verified address used at signup or the last valid email change, a normalized version of that (for identity) without + mailboxes, lowercased, de-accented, stripped of dots and other inert punctuation, and normalized in a number of other ways... and then of course the email parameter (only used during registration). We accomplish this with a slightly more…
Unicode actually has an uppercase ß though I don't understand why.
The examples in the initial "quick example" are backwards, no? It's `'ß'.toUpperCase()` that is `"SS"`, not `'ß'.toLowerCase() === 'ss'`. As the later chart makes clear. Same with turkish ı.
'ß'.toUpperCase() // = "SS"
'ß'.toLowerCase() // = "ß"