CMS DataLife Engine - Система управления сайтами

Sign in to follow this  
webair

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

Recommended Posts

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

Обнаружил, что у 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() избавиться.

 

Edited by webair

Share this post


Link to post
Share on other sites
3 часа назад, webair сказал:

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

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

 

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
18 минут назад, celsoft сказал:

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
42 минуты назад, webair сказал:

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
3 часа назад, celsoft сказал:

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

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

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

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

Share this post


Link to post
Share on other sites
20 часов назад, webair сказал:

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

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

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

Share this post


Link to post
Share on other sites
45 минут назад, celsoft сказал:

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

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

 

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

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

 

Share this post


Link to post
Share on other sites
37 минут назад, webair сказал:

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

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

Share this post


Link to post
Share on other sites
В 23.08.2018 в 15:22, celsoft сказал:

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

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

Share this post


Link to post
Share on other sites
14 часов назад, Яйцерезка сказал:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this