Рефакторинг регистрации

[webair 178]

Писал модуль (для админ части), где требуется в том числе регистрация пользователя.

Обнаружил, что у DLE нет готовой функции регистрации пользователя?!

Посмотрел, как написана регистрация в api, inc/editusers.php, modules/register.php

И обнаружил, что они немного различаются, а главное...

 

Если логин содержит недопустимые символы, то выводим ошибку

if( preg_match( "/[\||\'|\<|\>|\[|\]|\%|\"|\!|\?|\$|\@|\#|\/|\\\|\&\~\*\{\}\+]/", $name ) ) $stop .= $lang['reg_err_4'];

А если email содержит недопустимые символы, то вырезаем их и продолжаем дальше?

$not_allow_symbol = array ("\x22", "\x60", "\t", '\n', '\r', "\n", "\r", '\\', ",", "/", "#", ";", ":", "~", "[", "]", "{", "}", ")", "(", "*", "^", "%", "$", "<", ">", "?", "!", '"', "'", " ", "&" );
	$email = $db->safesql(trim( str_replace( $not_allow_symbol, '', strip_tags( stripslashes( $_POST['email'] ) ) ) ) );

 

Немного не понятна разница, почему в одинаковой ситуации принимаются разные решения?

Смоделируем ситуацию: Вход на сайте по email. Пользователь при регистрации вводит email, вырезаются недопустимые символы, пользователь не может зайти из-за того, что он не в курсе, что его email изменили и вводит ровно тот же email, что и при регистрации.

 

В таком случае, нужно и в sitelogin.php сделать замену недопустимых символов в email, если оно в качестве логина, чего сейчас не сделано.

 

И нет проверки, содержит ли email хотя бы @ и . или использовать FILTER_VALIDATE_EMAIL

 

P.S. Всё описанное мной лишь мое мнение и не претендует на истину. @celsoft, а ведь всё таки был прав @Gameer на счет того, что копипастить плохо и нужно создавать функцию, хотя с некоторыми другими его суждениями и не согласен.

 

UPD:

 

trim() удаляет пробел, табуляцию, символ возврата каретки и переноса строки из начала и конца строки, что уже перечислено в массиве заменяемых данных для str_replace(), а значит, trim() тут не нужен. Ну, можно дополнить массив "\x0B" и "\0", которые удаляет trim(). Кажется, с таким внушительным массивом символов, можно и от safesql() избавиться.

 

Изменено 23 августа 2018 пользователем webair

[celsoft 6 072]

3 часа назад, webair сказал:

Немного не понятна разница, почему в одинаковой ситуации принимаются разные решения?

В первом случае символы которые не приемлет DLE, он выдает на них ошибку. Во втором случае это символы не приемлимые стандартом rfc соответственно не могут быть в реальном адресе, поэтому они воспринимаются как за опечатку и удаляются.

 

3 часа назад, webair сказал:

И нет проверки, содержит ли email хотя бы @ и . или использовать FILTER_VALIDATE_EMAIL

На сайте в модуле регистрации проверка на наличие @ есть, вы просто не заметили. FILTER_VALIDATE_EMAIL не применяется потому как он некорректно работает для ряда адресов в локальных системах, сайт может быть не только в сети интернет, но в локальной корпоративной сети. По крайней мере были проблемы с его работой ранее на старых версиях PHP, на актуальных не знаю, давно не проверяли, поэтому этот фильтр не используется. Лучший фильтр на самом деле это проверка реальности адреса, т.е. расширенная регистрация. Все остальные фильтры не точны и не позволяют 100% достоверно проверить адрес. Поэтому в DLE такой фильтр.

3 часа назад, webair сказал:

В таком случае, нужно и в sitelogin.php сделать замену недопустимых символов в email, если оно в качестве логина, чего сейчас не сделано.

Не имеет никакого смысла. В этом файле идет проверка по базе зарегистрированных. Соответственно, лишняя нагрузка, на то что в базе уже быть не должно по более ранним проверкам.

[webair 178]

18 минут назад, celsoft сказал:

Не имеет никакого смысла. В этом файле идет проверка по базе зарегистрированных. Соответственно, лишняя нагрузка, на то что в базе уже быть не должно по более ранним проверкам.

Вы не поняли мысль.

Человек, допустим, пытается ввести при авторизации тот же некорректный email, который вводил при регистрации. В случае регистрации, вы вырезаете символы из $_POST, а при авторизации не вырезаете, в итоге пользователь не может войти.

 

Ок, вы ссылаетесь на RFC. Посмотрите, чуть ли не все символы, которые вы вырезаете, поддерживаются RFC. Но я не из-за этого написал сюда.

Тему продолжать не буду)

[celsoft 6 072]

42 минуты назад, webair сказал:

Ок, вы ссылаетесь на RFC. Посмотрите, чуть ли не все символы, которые вы вырезаете, поддерживаются RFC. Но я не из-за этого написал сюда.

Тему продолжать не буду)

Для еmail? Нет не поддерживаются. Какие символы из списка допустимы в e-mail? Перепроверю еще раз.

44 минуты назад, webair сказал:

Вы не поняли мысль.

Человек, допустим, пытается ввести при авторизации тот же некорректный email, который вводил при регистрации. В случае регистрации, вы вырезаете символы из $_POST, а при авторизации не вырезаете, в итоге пользователь не может войти.

Возможно вы и правы, я просто на практике еще ни разу не сталкивался с такой ситуацией. Можно подумать над этим.

[webair 178]

3 часа назад, celsoft сказал:

Для еmail? Нет не поддерживаются. Какие символы из списка допустимы в e-mail? Перепроверю еще раз.

Возможно вы и правы, я просто на практике еще ни разу не сталкивался с такой ситуацией. Можно подумать над этим.

https://habr.com/post/224623/

Но мне без разницы на RFC. Тему не из-за этого создавал.

[celsoft 6 072]

20 часов назад, webair сказал:

https://habr.com/post/224623/

Но мне без разницы на RFC. Тему не из-за этого создавал.

Ну так вы и почитайте внимательно что там пишут  DLE как раз таки и следует описанным там правилам, если вы не заметили. Он удаляет все символы, которые в реальности не имеет поддержку со стороны реальных почтовых серверов и сервисов.

[webair 178]

45 минут назад, celsoft сказал:

Ну так вы и почитайте внимательно что там пишут  DLE как раз таки и следует описанным там правилам, если вы не заметили. Он удаляет все символы, которые в реальности не имеет поддержку со стороны реальных почтовых серверов и сервисов.

А я и не имел к этому претензий. Это вы сами начали ссылаться на RFC, что они неприемлемы RFC, но они приемлемы. Но не в этом дело. Всё, проехали ))

 

В 23.08.2018 в 13:22, celsoft сказал:

это символы не приемлимые стандартом rfc

 

[celsoft 6 072]

37 минут назад, webair сказал:

А я и не имел к этому претензий. Это вы сами начали ссылаться на RFC, что они неприемлемы RFC, но они приемлемы.

Я могу конечно ошибаться, нужно перечитать RFC, но эти символы там недопустимы, или были ранее, или наоборот сейчас. Статья старовата, да и я сам давно не читал актуальных версий RFC, т.к. жалоб еще на проверку недопустимости адреса еще не разу не было.

[Яйцерезка 7]

В 23.08.2018 в 15:22, celsoft сказал:

На сайте в модуле регистрации проверка на наличие @ есть, вы просто не заметили. FILTER_VALIDATE_EMAIL не применяется потому как он некорректно работает для ряда адресов в локальных системах, сайт может быть не только в сети интернет, но в локальной корпоративной сети.

Мне кажется мазохизмом сейчас локалхост делать под корпоративный сайт, для этого можно внутренний поддомен сайта использовать, который доступен только внутри сети.
FILTER_VALIDATE_EMAIL отлично сейчас уже работает, не нужно идти на поводу у старых извращенцев, пусть делают более менее современные адреса даже внутри корпоративной сети, а не плодят сущности 90-ых в 2018 году.

[celsoft 6 072]

14 часов назад, Яйцерезка сказал:

Мне кажется мазохизмом сейчас локалхост делать под корпоративный сайт, для этого можно внутренний поддомен сайта использовать, который доступен только внутри сети.

Не нам и не вам решать, как людям делать сайты.