Я так и не увидел, что Вы согласились, со своей неправотой. Вы ведь навязываете свою точку зрения, при этом говорите, что нужно больше свобод - парадокс. При этом аргументы воспринимаете, как демагогию. Вы говорите, что нужна кириллица - я не против. Но пусть каждый решает сам для себя. --- Добавлено --- Аргументы - это не Ваше субъективное мнение. Я бы хотел увидеть аргументы по поводу этого оскорбления. При этом я еще никого не оскорблял, а на меня накинулись уже два модератора.
ты к своим тезисам приведи аргументы, тогда мы к своим начнём. --- Добавлено --- вот это называется демагогия и словоблудие разговор не про каждого, который там что-то себе решает, а про архитектуру приложения, которая должна вытекать из технических возможностей и ограничений используемых инструментов. Всё остальное - от лукавого.
ну... очевидно, что ты написал просто вещей с потолка, которые считал правильными, но не знал почему. можно копнуть и выяснить, какие из них действительно имеют смысл и почему, как например ограничение на запуск js. Но оно тоже довольно шаткое. А можно забить и вернуть с гордо поднятым носом в свою нору неведенья и дальше считать, что в запрете дефиса есть смысл не меньший, чем в других запретах, т.к. "они же нужны".
Второй демагогический страйк. И да, твои попытки перевода темы не являются аргументами. Они как минимум в принципе не имеют отношения к теме разговора. И я не навязываю свою точку зрения. Я ее объясняю. А ты свою объяснить так и не смог. Но зато начал переводить разговор на меня, ударился в философию и софистику. И в этом снова обвиняешь меня. Это голая демагогия. По этому я ее так и называю. И да, третий демагогический страйк - это вылет на неделю. Так, на всякий. А, постой, или ты имел ввиду, что я посягаю на твою свободу страдать херней и заблуждаться? Типа невежество и непрофессионализм - это право каждого специалиста-профессионала? Нет, это так не работает. Ты или профессионал или нет.
PHP: $ARGS = [ 'username' => [ 'filter' => FILTER_VALIDATE_REGEXP, 'options' => [ 'regexp' => '/^[A-Za-z0-9_-]{3,25}$/' ] ], 'email' => FILTER_VALIDATE_EMAIL, 'password' => FILTER_UNSAFE_RAW, 'confirm_password' => FILTER_UNSAFE_RAW ]; $INPUTS = filter_input_array ( INPUT_POST, $ARGS ); $E = []; if ( $INPUTS['username'] === NULL ) { $E['username'] = 'Undefined username :('; } elseif ( $INPUTS['username'] === FALSE ) { $E['username'] = 'Пожалуйста, введите имя, содержащее от 3-х до 25 латинских символов.'; } elseif ( SQL::P( 'SELECT ID FROM USRACCOUNT WHERE lower ( USERNAME ) = ?', [ strtolower ( $INPUTS['username'] ) ] ) -> rowCount() > 0 ) { $E['username'] = 'Введенное имя уже используется.'; } if ( $INPUTS['email'] === NULL ) { $E['email'] = 'Undefined email :('; } elseif ( $INPUTS['email'] === FALSE ) { $E['email'] = 'Адрес электронной почты должен быть валидным.'; } elseif ( SQL::P( 'SELECT ID FROM USRACCOUNT WHERE lower ( EMAIL ) = ?', [ strtolower ( $INPUTS['email'] ) ] ) -> rowCount() > 0 ) { $E['email'] = 'Введенная почта уже используется.'; } if ( $INPUTS['password'] === NULL ) { $E['password'] = 'Undefined password :('; } elseif ( empty ( $INPUTS['password'] ) ) { $E['password'] = 'Пожалуйста, введите пароль.'; } elseif ( $INPUTS['password'] != $INPUTS['confirm_password'] ) { $E['password'] = 'Введенные пароли не совпадают.'; } --- Добавлено --- даже в фильтрах плоха регулярка? При 10милл. цикле фильтр обгоняет прег мач на 2 секунды
Я просто вижу двух модераторов, которые провоцируют срач. Я не собираюсь спорить - наши точки зрения очень субъективны. Спор бесполезен. А забанить можете меня навсегда.
твоя - субъективна моя исходит из ограничений технических средств и не является субъективной ничего плохого в выявлении заблуждений и их изучении я не вижу --- Добавлено --- плоха для чего?
В том что без регулярки можно обойтись функцией strlen для подсчета, но код порядком длиннее будет и не по оптимизации
А я вижу дискуссию между тремя участниками форума. Я б не сказал, что strlen длиннее, чем PHP: $ARGS = [ 'username' => [ 'filter' => FILTER_VALIDATE_REGEXP, 'options' => [ 'regexp' => '/^[A-Za-z0-9_-]{3,25}$/' ] ], 'email' => FILTER_VALIDATE_EMAIL, 'password' => FILTER_UNSAFE_RAW, 'confirm_password' => FILTER_UNSAFE_RAW ]; $INPUTS = filter_input_array ( INPUT_POST, $ARGS ); Это раз. Ну и данный фильтр, как по мне, сделан не для проверок длины строки. Скорее уж для какой-то экзотики, связанной именно с анализом контента переданного. А длину строки регуляркой измерять - с пушки по воробьям палить, имхо.
Сверяя со всем кодом? или с нюансом в рег-выражении {3,25}? --- Добавлено --- это часть от кода регистрации, не залил пока в Git
@Fell-x27 Мое мнение на счёт кириллицы, а зачем она нужна в логине, если на сайт авторизуешся по логину, какая кириллица при входе не пойму. Хватит того что можно инфу посмотреть реальное имя и фамилия юзера. Вот там и будет кириллица я не видел сайты которые используют кириллицу при входе в него.
Отсыплю вам немного валидных email`ов в нагрузку к кириллическим логинам ) Код (Text): "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com #!$%&'*+-/=?^_`{}|~@example.org user@domain
Обычная. Чем логин "_не_скажу_" не логин? Ты прямо сейчас сидишь на таком. --- Добавлено --- Про валидацию имейлов целую статью на хабре помню по части того, что она не нужна Суть идеи в том, что валидность email не гарантирует его реальность и тот факт, что пользователь им владеет. Это все проверяется отправкой письма юзеру.. В итоге, бритвой Оккама можно нафиг срезать все проверки почты. И что единственное, для чего имеет смысл делать базовую проверку типа валидации пхпшным фильтром вкупе с выставлением типа input как email - это чтобы пользователю напомнить, что он забыл собаку написать или точку где-то после нее. Остальное же - пустая трата времени.
последний не проходит --- Добавлено --- PHP: <?php $E = [ '"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com', "#!$%&'*+-/=?^_`{}|~@example.org", 'user@domain' ]; echo implode ( '<br>', array_map ( function ( $A ) { return ( filter_var ( $A, FILTER_VALIDATE_EMAIL ) ? "$email is valid" : "$email is NOT valid" ); }, $E ) );
@Fell-x27 Согласен это логин, на счет эмайла согласен проверка не нужна, как описали выше. А с логином регулярках, ещё не убедили, вот например, юзер регается и себе ник создаёт такой (я пробел их тоже можно ставить) представьте себе такой ник? Или все же это нормально? Вот убедите меня и я соглашусь с вами.
А что с ним не так? На этом форуме можно такой ник зарегать, к примеру. Ну..почти такой. Тут выставлено ограничение на длину ника в 25 символов, а он чуть больше. Это, все же, индексируемое поле и все такое прочее.. Но ники на кириллице люди юзают тут. Какая разница-то, на каком языке ник? Ну кроме разрыва шаблона от того, что такое, оказывается, возможно? В чем проблема наличия пробелов, к примеру? У ряда работодателей на форуме вместо ников инициалы. Фамилия. И. О. Почему бы нет? И на кириллице и с пробелами. Не знаю, в чем я тебя должен убедить, если честно. Может быть ты расскажи, в чем видишь проблему? В техническом плане.
одно поле в БД состоит из транслит name, а второе real_user_name https://php.ru/forum/members/aleks8.63378/ --- Добавлено --- в пхпюру вовсе ид используют, для красоты и СЕО приписывают перед ID названия форума / ника - транслит версию кирилицы
ЧСВ, потому что могу и потому что хочу, хозяин - барин и делает свои правила, вот поэтому всегда будут ограничения в наборе символов. И если ресурс интересный и полезный, будут следовать не смотря на "бессмысленную глупую хрень". И спорить либо что то тут доказывать бесполезно, не доросли общим развитием, это как требовать одного браузера на всех и единого языка программирования
@Fell-x27 Меня просто безопасность беспокоит, если они вместо ника что то другое вставят, знаю можно экранировать данные htmlspecialchars. Ну все же... Или дайте советик как поступить мне по другому, что в таких случаях делать, чтобы не писать регулярках. Длину я понял можно считать функцией strlen().
Беспокоит абстрактно так, на всякий случай, или же ты знаешь конкретную уязвимость, связанную с пробелами или черточками в логинах? Я вот не знаю. Чем отличается символ пробела от символа "_"? Номером. Все. На низком уровне любая строка - просто набор байт. Так какая нам разница, какие там байты прописаны? Опасность тут ровно та же, что и с любыми другими данными, приходящими от пользователя. Но мы же знаем, как их избежать? Мы же выставляем соединение БД с явным указанием кодировок? Мы же экранируем строку спец функциями? Мы же, раз на то пошло, знаем про подготовленные выражения и умеем их применять, верно? Поле ввода комментариев на сайте не менее опасно, чем поле ввода логина - с ним легче работать, и нагрузка на него гораздо больше. Но ты же не боишься кириллицы и пробелов с черточками в комментах? Ну а те же SQL-инъекции, или PHP-инъекции, или JS-инъекции и прочие XSS, они разве на кириллице пишутся? Нет. Получается, безопаснее латиницу запретить... Не можно, а нужно. Иначе безобидная угловая скобочка в любой точке сайта, пришедшая в каком-нибудь комменте, сломает тебе нафиг верстку. Не говоря уже о тоннах XSS-а, который тут же повсюду расцветет. И это, в общем-то не экранирование, а подмена данных. По этому делать ее надо на выводе, а не на приеме. Лучше mb_strlen, когда речь идет о многобайтовых кодировках типа UTF-8. Это давняя багофича PHP. Суть в том, что strlen возвращает длину в байтах, а не в символах. Кириллические буквы занимают по 2 байта. mb_strlen учитывает этот нюанс и возвращает длину строки в символах. --- Добавлено --- Ды вот же. И это грустно.
@Fell-x27 Ой да mb_strlen функция для проверки длины, вы меня убедили, серьезно нафиг уберу с регистрации эти как их там забыл ну короче ты понял.
Это еще что. Некоторые люди ограничения ставят на символы в пароле. Или чистят его стриптагами и прочей бесовщиной. А потом пускают под хэш, хотя казалось бы, какая нафиг разница хэш-функции, что там было изначально? А все от непонимания происходящего. Люди чот делают, но сами не знают что и зачем. В видеокурсах увидели, и повторяют бездумно.
@Fell-x27 О вспомнил как их там регулярки три минуты и убрал их все их было штук 5 я просто не знал этой всей инфи которую перечитал в данном посте, теперь закрепил и знаю. Вот теперь еще вопрос про функции, стоит ли при вводе реальных имён и фамилий использовать функцию ucfirst() для чего она я читал и не понял розжуйте для меня ее. И ещё одна функция которую использую ctype_digit() читал тоже, преобразует первый символ в верхний регистр, но для меня это не о чем не говорит, использую эту функцию для имён фамилии и логина юзера, одним словом эту функцию тоже пожалуйста розжуйте для меня, спасибо.
Как по мне - вообще не нужно пользовательские данные своими руками трогать. Хочешь отображать что-то с большой буквы? Юзай CSS. Там есть свойство text-transform, у которого есть значение capitalize. Чот ты путаешь. Она ничего не преобразует. Она просто проверяет, все ли символы в строке являются цифрами. Ну а чего непонятного? Первый символ в строке делает заглавным. Это в доке написано же. А для чего ее применять в конкретном случае - ну тут уж тебе решать. Это инструмент, как и все остальное. Ну если именя и фамилии еще куда ни шло, то вот логин преобразовывать ни в коем случае нельзя. Как его человек ввел, таким он и должен быть. Значит так нужно пользователю. Логин - не имя. С маленькой так с маленькой.