marazmatik Ты тупой и поришь фиг-ню =) в пхп для таких случаев есть хтмлспешалчарс и хтмлэнтитис Удачи
Если регулярка написана правильно - то чисто с точки зрения безопасности - хватит. Просто у тебя обе регулярки (что в первом, что в предыдущем комментарии) - с косячками Аккуратней составляй их, тестируй как следует - и нормально, будет достаточно регулярки. Чисто на всякий случай, для большего личного спокойствия - можно добавить mysql_real_escape_string() или приведение к int, например.
Да ты уже показал интеллект, иди дальше косички на мудях плети. Если ты в регулярках плохо шаришь, какого чёрта ты тут отписываешься, или у тебя мания трольская, набивать количество сообщений?
Вот есть люди =) которые по делу постятся на форуме. Я конечно проверяю, и для верности, написал функцию, где чистятся тэги, и экранируются скобки, и другая вредоносная ересь. -------------------------------------------------- Укажи пожалуйста косяки =) в последнем не хватает конца строки, или ещё чего то? А что с первой /^[\d]+$/D знаю что если не указать модификатор D можно вставить символ переноса строки \n то есть такой запрос пройдет index.php?act=1464%0a ----------------- В общем хочеться услышать твой ответ. :roll:
Слушай, не занимайся ерундой, зачем ты тут пишешь? Мне хватило твоего первого сообщения, о доверии к пользователям, что тот кто захочет заполнит верно номер icq Но ведь вопрос был не в этом, да и icq просто проверка, это так второстепенное поле, личная информация пользователям. Зачем применять при выводе htmlspecialchars() если можно записать нормально, без лишних символов если это тот же icq то целые числа (Integer), если это логин то латинские буквы и цифры определенной длинны а не 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 А если ты формой передаешь id к примеру поста, да тут можно применить mysql_real_escape_string() чтобы не вышло sql инъекции, но почему не проверить регуляркой, и вывести сообщение с ошибкой? Нормальный пользователь не будет туда лезть, но расчет не только на нормальных пользователей.
Где я говорил о доверии, курица слепая? =) я сказал, что если с этим полем не будет работать робот, то в таких случаях требовать труЪ валидности данных не имеет большого смысла. А для защиты БД достаточно эскейпа. Про вывод вобще не было разговора. А почему ты считаешь что в логине должны быть сугубо латинские символы вобще не ясно. На дворе век utf. На рутрекере всегда норм пахали русские логины и никогда никого это не напрягало. Больше похоже что ты застрял в своих подходах в прошлом десятилетии. Просыпайся давай.
Ну насчет логина из любых утф8 - вопрос спорный, если 0 и o еще можно отличить то есть символы в утф полностью идентичные, да и другие косяки повалятся
Но, в принципе-то, ничего не мешает использовать любые символы в качетстве логина... Как хочется пользователю - так пущай и называет себя, кому какое дело? Нравится ему комбинация каких-то непонятных символов - ну и пусть, что тут такого... А так-то всё как обычно - эскейпим перед отправкой в б.д., htmlspecialchars перед выводом в html.
marazmatik Ну, в первой - я уже писал, у тебя она пропускает любое кол-во цифр. Взломать-то не взломают, но при вставке данных на 5-м MySQL запрос обломается (хотя, не уверен, может там от настроек зависит). Скрипт будет думать, что аська правильная, отправит пользователю письмо, что тот успешно зарегился, а на самом деле его в списке пользователей нет. В общем, нарушение работы скрипта. Во второй - да, не указан признак конца строки. В результате регулярка будет просто проверять, начинается ли логин с не менее четырёх символов из набора [a-z0-9], но ей будет пофиг, что там идёт за ними.
sobachnik Свободу нельзя давать, надо чтобы логины у всех были визуально различны, да и для других не было двух пользователей "по 4 квардратика", но вот если прокрадутся управляющие символы, тогда пиши пропало =))
Вот блин чего вы себе воображаете? Кто вы блин такие чтобы ограничивать людей и объяснять как им жить. =) Хорошо что кроме таких как ты есть те, кто придумывает вещи типа utf и прочего. Нет никаких объективных причин для ограничения символов в логине. Никаких.
А у нас в паре проектиков было в ТЗ указано, что поле пароль ДОЛЖНО содержать хотя бы одну букву, хотя бы одну цифру и хотя бы один символ не являющийся ни буквой ни цифрой При этом общей длиной пароль должен быть не короче 6 символов. Но с паролем-то вообще пофиг - он нигде не выводится и в базе хэш солёный хранится...
Ты тупой петух, и твоё место на параше... Все данные полученные от пользователя нужно проверять, и форматировать, чтобы потом не ломать голову ШО-же не так, указывать человеку где он совершил ошибку, без перезагрузки страницы, а не выводить одну месагу на всё. die('Ууу ошибка') Век WEB2 а твои куриные подходы. Заебал ей богу, свою дрочь нести про ютф никто не спорит, хоть на украинском пусть вводят логин. Но для каждого проекта свой функционал своё техническое задание (ТЗ) Петух ты не доношенный...
=) Всё верно говорите товарищ. Но я где-то ниже уточнил что там не хватает ограничения символов что то тип {3,9} Иначе выйдет ошибка что то типа: Warning: mysql_fetch_row() expects parameter 1 to be resource, boolean Ну и в последнем тоже, верно подмечено не хватает знака, конца строки. Но там же чёрным выделено было Это всего лишь пример на скорую руку. В общем спасибо за ответ.
блин, читайте не между строк, я гворю, что нельзя все символы разрешать, а четко их ограничивать, хотя бы той же регуяркой, а то иначе вставит пользователь символ, что след текст идет справо налево и будет каша у вас
igordata Кстати да, как DTS купила ICQ, в логине теперь может быть e-mail, при чем хоть кириллица, хоть иероглифы. Поэтому пора забыть про регулярки для мыла. Вместо этого кодировать его в пуникод, проверять на валидность, и в базу записывать в исходном виде.