Комментарии 59
так что почтовый адрес John@Gıthub.com после обработки превращается в John@Gıthub.com:видимо во втором случае должно быть John@Github.com?
Мало кто знает все хитрости
Спасибо за ссылку на статью! Берём на вооружение :)
У кого-нибудь это работает? У меня почему-то получается'ß'.toLowerCase() === 'SS'.toLowerCase() // true
false.
'ß'.toUpperCase() == 'ss'.toUpperCase()
eng.getwisdom.io/awesome-unicode/#lowercasetransformationcollisions
Это John@Gıthub.com → xn--john@gthub-2ub.com кажись должно быть так John@Gıthub.com → john@xn--gthub-n4a.com но punycoder делает первый вариант.
Выполняю:
var_dump(strtolower('ß')); // ßКоллизии нет
Выше написали, что автор ошибся. Нужно в верхний регистр переводить.
PHP по умолчанию умеет работать только с кодировкой ASCII (пример: strlen('я') даст результат 2)
Для работы с Юникодом нужно подключить плагин mbstring. И правильный пример будет такой:
var_dump(mb_strtoupper('ß'));
var_dump(mb_strtoupper('ß')); //string(2) "ß"php -i | grep -i mbstring
/etc/php/7.2/cli/conf.d/20-mbstring.ini,
Zend Multibyte Support => provided by mbstring
Multibyte decoding support using mbstring => enabled
mbstring
mbstring extension makes use of "streamable kanji code filter and converter", which is distributed under the GNU Lesser General Public License version 2.1.
mbstring.detect_order => no value => no value
mbstring.encoding_translation => Off => Off
mbstring.func_overload => 0 => 0
mbstring.http_input => no value => no value
mbstring.http_output => no value => no value
mbstring.http_output_conv_mimetypes => ^(text/|application/xhtml\+xml) => ^(text/|application/xhtml\+xml)
mbstring.internal_encoding => no value => no value
mbstring.language => neutral => neutral
mbstring.strict_detection => Off => Off
mbstring.substitute_character => no value => no valueЧто я делаю не так?
Проверил через сайт http://sandbox.onlinephpfunctions.com, что если версия php меньше 7.3.5, то коллизия не проявляется.
Так эта функция не работает с многобайтными кодировками, включая юникод. Используйте mb_strtolower. Но там написано что может преобразовывать, вот только не понятно правильно или нет.
Вы указали в тексте решение проблемы.
Зачем менять регистр почты или логина?
Мог при регистрации ввести John, а при восстановлении забыть и писать john.
Адрес почты регистрозависим! По крайней мере до знака @.
Нет. Локальная часть до @ интерпретируется сервером. Домен к регистру не чувствителен.
https://tools.ietf.org/html/rfc5321#section-2.3.11
Так вы ссылку кинули как раз на документ, который говорит, что после @ по факту регистронезависим, а до собаки — зависит от реализации сервера. К чему тут "нет"?
Давайте по честному. Не принято, а легче так думать и так её обрабатывать. Но из этого следует не то, что можно это считать стандартом де факто, а то, что просто всем лень её обрабатывать правильно.
Просто почтовик, который разрешит регистрировать разные адреса отличающиеся только регистром и сортировать почту с учетом регистра никто не будет использовать.
Потому что преимуществ ровно ноль, а вот проблем посыпется с головой.
Зачем условному админу почты может захотеться иметь регистрозависимою почту? Просто зачем?
За тем, что логины могут быть и не только от почты, а браться например из совершенно другой системы? Например если бы хабр решил всем раздать мыльники с @habr.com, то он бы скорее всего взял в качестве имени ящика именно ник пользователя. А если их приводить к одному регистру, то начнутся проблемы.
И это синтетический.
Практический юзкейс — русские имена в почте.
русские имена в почте.
Такого не должно быть потому что не должно быть.
Например если бы хабр решил всем раздать мыльники с habr.com, то он бы скорее всего взял в качестве имени ящика именно ник
Вы правда думаете, что ники регистрозависимы?
Даже столкнувшись с такой задачей никто в здравом уме не влезет в такое legacy. Скорее выберут какое-то компромиссное решение.
Скорее выберут какое-то компромиссное решение.
Это совершенно не значит, что какой-нибудь админ не засядет и не сделает всем русские мыльники. Точно так же это не значит, что в каком-то нормальном почтовике вдруг не реализуют полную поддержку стандарта этого.
Слишком много в этом всём деле "скорее всего", "вдруг" и "никто в здравом уме". Это подход, который как раз и тянет за собой опасности по типу "никакое устройство в здравом уме не будет нам подкидывать битые пакеты". А получается из этого много и много уязвимостей.
Ну а проблемы людей, которые захостились на такой почте врядли стоит учитывать вообще, их слишком мало, даже в теории.
Проблема этих людей будет в первую очередь бить по хостеру решившему сделать дичь, а не по сервису считающему почту регистронезависимой, ибо это стандарт дефакто.
Адрес почты регистрозависим! По крайней мере до знака @.
Строго говоря, строка ДО знака @ НЕ является регистрозависимой или регистронезависимой. Это определено реализацией сервера. Строка ПОСЛЕ @ адресует сервер, и она является регистроНЕзависимой. Извините за мой французский.
Конечно, обрабатывать UNICODE не просто.
Но дело в том, что программисты часто обрабатывают то, чего не надо обрабатывать совсем.
Пример с email показателен! Почтовые адреса чувствительны к регистру! Зачем надо было преобразовать? Сравнивайте напрямую. Потребитель который хочет сменить пароль очень хорошо знает какой у него адрес!
И вообще, тема валидации почтовых адресов совершенно неоднозначная. И в ней правило "меньше лучше" действует на все 100%.
The standard mailbox naming convention is defined to be local-part@domain;… the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.Иными словами, это дело хоста решать, зависимы ли имена в его домене от регистра или нет. Клиент должен исходить из худшего, и хранить/посылать емейлы в том регистре, в каком его ввели изначально. Поиск среди сохранённых емейлов можно вести регистронезависимо.
Почтовые адреса чувствительны к регистру!
В нормальных почтовиках нет. И условный gecube@gmail.com будет то же самое, что и GECUBE@GMAIL.COM
Хуже того. G.E.C.U.B.E@GMAIL.COM может быть эквивалентом GECUBE@GMAIL.COM. Как и GECUBE+TAG@GMAIL.COM
Что это за "нормальный почтовик"????
Регистрозависимость решает получатель, а не отправитель! И тот клиент, который отправляет почту по собственным правилам рискует эту почту просто не доставить. Если "почтовик" не доставивший почту, хотя это было вполне возможно, "нормальный", то спасибо, но нет. Возьму ненормального.
Так об этом и речь, что если на стороне получателя почтовый сервис различает юзеров в зависимости от регистра и позволяет регистрировать одинаковые, но разные почтовые адреса, то это первый шаг в сторону ада. Про сторону отправителя я ничего не говорил — как отправитель написал, так и письмо должно уйти. Благо обычно проблемы нет, т.к. почтовый адрес берется из известного источника — визитка, контакт, сайт и пр.
Так об этом и речь, что если на стороне получателя почтовый сервис различает юзеров в зависимости от регистра и позволяет регистрировать одинаковые, но разные почтовые адреса, то это первый шаг в сторону ада.
Ну-у-у, ад-не-ад, а стандарт этого допускает. Так что вся обработка адресов (вкл. валидация) должна соответствовать. И кстати это по сути значительно упрощает обработку и делает жизнь легче.
Введённый адрес переводится в нижний регистр с помощью метода toLowerCase.
Введённый адрес сравнивается с адресом в базе зарегистрированных пользователей.
Если найдено совпадение, пароль из базы данных высылается на введённый адрес.
Причем тут юникод не совсем понятно. Джуновская ошибка, старая как мир.
Если найдено совпадение, пароль из базы данных высылается на введённый адрес.
Надеюсь, что пароля в базе данных никогда не было, а высылается токен авторизации процедуры смены пароля…
Так, вы сказали, что в Юникоде 216 символов, а там можно хранить 231, но используются только 1 112 064. Видимо вы перппутали с размером плоскости, который как раз 2**16 (информация из Википедии)
Взлом с помощью Юникода (на примере GitHub)