Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Регулярные выражения
Форумы портала PHP.SU » » Вопросы новичков » Регулярные выражения

Страниц (2): [1] 2 »
 

1. Hapson - 07 Июля, 2013 - 11:18:06 - перейти к сообщению
Всем привет!

Есть необходимость проверять некоторые поля на соответствие. Использую preg_match()
Вот например для пароля, который может состоять из a-z A-Z 0-9 ! ? . , @ # $ % - _
CODE (htmlphp):
скопировать код в буфер обмена
  1. $x = preg_match("/^[a-zA-Z0-9!?.,@#$%_\-]+$/", $x);

Вроде работает.
Но вот хочу уточнить. Внутри квадратных скобок нужно экранировать только \ ^ - ] правильно?
2. teddy - 07 Июля, 2013 - 11:24:58 - перейти к сообщению
PHP:
скопировать код в буфер обмена
  1. $password = $_POST['password'];
  2.  
  3.     if(!preg_match("/^[a-zA-Z0-9\!\?\.\,\@\#\$\%\_\\\-]+$/", $password))
  4.         {
  5.         echo "Что то не так";
  6.         }
  7.  

А вообще лучше для паролей использовать md5, не хорошо ограничивать пользователей в символах для ввода пароля...
3. EuGen - 07 Июля, 2013 - 11:37:47 - перейти к сообщению
teddy пишет:
А вообще лучше для паролей использовать md5, не хорошо ограничивать пользователей в символах для ввода пароля...

Не понятно, как связан хеш и исходное представление.
Hapson пишет:
Внутри квадратных скобок нужно экранировать только \ ^ - ] правильно?

Экранировать следует всё, что используется в качестве служебных символов в регулярных выражениях. Если не уверены, то есть preg_quote
4. teddy - 07 Июля, 2013 - 11:42:01 - перейти к сообщению
EuGen
Исходное представление чего? )

Hapson пишет:
например для пароля, который может состоять из a-z A-Z 0-9 ! ? . , @ # $ % - _


Вот придет пользователь, захочет ввести пароль Русскими буквами, а ему всплывет ошибка, вот о чем я...

Поэтому думаю лучше md5 и с точки зрения безопасности и с точки зрения свободы ввода пароля для пользователей ) Всем хорошо...
5. EuGen - 07 Июля, 2013 - 11:49:41 - перейти к сообщению
teddy
Исходное представление пароля.
И по-прежнему неясно, как связана валидация данных с тем, как они в конечном итоге будут храниться.
teddy пишет:

Вот придет пользователь, захочет ввести пароль Русскими буквами, а ему всплывет ошибка, вот о чем я..

- и при чём здесь md5, собственно - вот о чём я. Допустим, мы сделаем хранение в md5. Но регулярное выражение не пропустит пароль. Или мы не сделаем хранение в md5, но уберём регулярное выражение. Пароль не будет ограничивать ввод, но md5 использоваться при хранении не будет.
А, может, мы вообще решим использовать другой хеш. Поэтому - по-прежнему непонятно, как это связано.
Если боитесь за передачу данных и планируете считать хеш на клиенте - то мой совет - используйте https
6. Hapson - 07 Июля, 2013 - 11:52:13 - перейти к сообщению
teddy пишет:
PHP:
скопировать код в буфер обмена
  1. $password = $_POST['password'];
  2.  
  3.     if(!preg_match("/^[a-zA-Z0-9\!\?\.\,\@\#\$\%\_\\\-]+$/", $password))
  4.         {
  5.         echo "Что то не так";
  6.         }
  7.  

А вообще лучше для паролей использовать md5, не хорошо ограничивать пользователей в символах для ввода пароля...

Я думаю если написать, что пароль может состоять из латинских букв, цифр и спецсимволов, то будет понятно, что кроме русских букв.
После проверки конечно MD5. А как MD5 работает с кириллицей?
7. EuGen - 07 Июля, 2013 - 11:53:09 - перейти к сообщению
Hapson
md5
8. Denkill - 07 Июля, 2013 - 11:56:59 - перейти к сообщению
Hapson пишет:
А как MD5 работает с кириллицей?


Присоединяюсь, тоже интересно.
9. teddy - 07 Июля, 2013 - 11:59:18 - перейти к сообщению
EuGen
Спасибо за совет, Евгений )

Мой вариант - убрать регулярку и скормить пароль "солёному" md5 перед отправкой его в БД )

Таким образом мы получаем:
1. Свободный ввод пароля для пользователя
2. Исключаем к примеру, SQL иньекцию
3. Безопасное хранение паролей в БД(ну, если туда кто то проник это уже не есть хорошо то понятно, но хоть какие то палки в колёса взломщика мы уже понаставили)

Hapson
Hapson пишет:
А как MD5 работает с кириллицей?

Любой введенный символ или несколько символов и пропущенный через md5 имеет свой уникальный хеш, так что можете использовать смело... Пользовался - проблем не было.

А зачем вам в таком случае preg_match? Толку то от него нет, только проблемы для пользователя.. Вам в любом случае в итоге в БД запишется хеш...
10. Hapson - 07 Июля, 2013 - 12:04:34 - перейти к сообщению
Да, действительно, проверять нет смысла.
Посмотрел сейчас, md5 все что угодно принимает.

Ну еще вопрос тогда.
Имеет смысл такое:
PHP:
скопировать код в буфер обмена
  1. function form_clean($x, $y = 'db'){
  2.         switch($y){
  3.                 case 'db':
  4.                         $x = htmlentities(mysql_real_escape_string(trim(strip_tags($x))), ENT_QUOTES, "UTF-8");
  5.                         break;
  6.                 case 'file':
  7.                         $x = htmlentities(addslashes(trim(strip_tags($x))), ENT_QUOTES, "UTF-8");
  8.                         break;
  9.                 default:
  10.                         $x = htmlentities(mysql_real_escape_string(trim(strip_tags($x))), ENT_QUOTES, "UTF-8");
  11.         }
  12.         return $x;
  13. }

Функция пропускает через себя данные из формы. Если file, то это записывается в тектовый файл, а если db - в БД
11. EuGen - 07 Июля, 2013 - 12:04:40 - перейти к сообщению
Строго говоря, md5 является слишком быстро вычислимым для того, чтобы использовать его для безопасного хранения данных. Многие специалисты не рекомендуют использовать md5 для хранения хешей. Правда, этот недостаток можно компенсировать добавлением соли и вводом таймаута на попытки проверки верности вводимых данных.
teddy пишет:
Мой вариант - убрать регулярку и скормить пароль "солёному" md5 перед отправкой его в БД )

В итоге и пришли к тому, что оно не связано и регулярное выражение нужно будет убирать в любом случае.
12. Hapson - 07 Июля, 2013 - 12:05:53 - перейти к сообщению
или htmlentities() убрать?
13. vanicon - 07 Июля, 2013 - 12:07:04 - перейти к сообщению
Hapson
Убрать, он нужен при выводе данных на страницу.
И да не забудьте поставить ограничение на длину пароля...
14. Hapson - 07 Июля, 2013 - 12:08:15 - перейти к сообщению
vanicon пишет:
Hapson
Убрать, он нужен при выводе данных на страницу.
И да не забудьте поставить ограничение на длину пароля...

Спасибо. Да, про длину забыл.
15. EuGen - 07 Июля, 2013 - 12:09:18 - перейти к сообщению
Hapson
0. Нет смысла использовать addslashes и mysql_real_escape_string вместе.
1. Вообще, функции mysql_* являются устаревшими, вместо них следует использовать расширение mysqli
2. Недопустимо использовать проверку на html-сущности при записи в БД. Это портит пользовательский ввод и может привести к коллизиям. Так, к примеру, md5(htmlspecialchars('<')) совпадёт с md5(htmlspecialchars('&lt;')) - что является ошибкой. Общий совет - каждая проверка нужна в своём месте. Если данные из БД в дальнейшем отображаются в приложении - то именно там и нужно перед выводом пропускать данные через функции проверки на html

 

Powered by ExBB FM 1.0 RC1