Форум PHP

Я делаю регистрацию, и мне нужно обработать 2 поля, это "passw" и "passw_re"
сперва я проверяю на наличие записей в двух полях:

if (! strlen($_POST['passw'])) {print 'Вы не ввели <b>пароль</b>!<br>';} if (! strlen($_POST['passw_re'])) {print 'Вы не <b>поттвердили пароль</b>!<br>';}

потом я проверяю количество введённых символов:

if (isset($_POST['passw']) && (strlen($_POST['passw']) <6 )) {print '<b>Пароль</b> не может состоять меньше чем из <b>6</b> символов!<br>';} if (isset($_POST['passw']) && (strlen($_POST['passw']) >12 )) {print '<b>Пароль</b> не может состоять больше чем из <b>12</b> символов!<br>';} if (isset($_POST['passw']) && (strlen($_POST['passw_re']) <6 )) {print '<b>Пароль</b> не может состоять меньше чем из <b>6</b> символов!<br>';} if (isset($_POST['passw']) && (strlen($_POST['passw_re']) >12 )) {print '<b>Пароль</b> не может состоять больше чем из <b>12</b> символов!<br>';}

а теперь как мне сверить введённые данные в двух полях, но при условии, что оба поля должны быть заполнены(если одно из них, или они оба не заполнены, то проверку на сходство не проводить, и не выдовать ошибку о том, что они не схожи.)

Я пытался написать так:

if (strlen($_POST['passw']) != (strlen($_POST['passw_re']) && (isset($_POST['passw']) > 0 &&  (isset($_POST['passw_re']) > 0 )))) {print '<b>Пароли</b> не совпадают!<br>';}

но не получается... он не выдаёт ошибку, что поля не совпадают...

if (! isset($_POST['passw'])){print 'Вы не ввели пароль';}
if (isset($_POST['passw']) && ((strlen($_POST['passw']) <6 ) || (strlen($_POST['passw']) >12 ))) {print '<b>Пароль</b> не может состоять меньше чем из <b>6</b> символов и больше чем из 12!';}
if ($_POST['passw'] !== @$_POST['passw_re']) {print '<b>Пароль</b> не совпадает с подтверждением!';}
Можно, конечно, вначале проверить, введено ли подтверждение пароля, но зачем? Достаточно отсутствие совпадения.

Спасибо вам огромное... сократили код вдвое и сделали более грамотным! =)
Прислушаюсь к вашему совету!

надеюсь, там нет грамматических ошибок и опечаток и оно заработает с первой попытки.

да работает!..
то что мне и надо!
извините, хотел у вас спросить,

if ($_POST['passw'] !== @$_POST['passw_re']) {print '...';}

для чего сабака нужна? чтобы на будующее знать...

сабака экранирует ошибки))) фу на неё)

<?php if (! isset($_POST['passw']))     print 'Вы не ввели пароль'; else{     if((strlen($_POST['passw']) <6 ) || (strlen($_POST['passw']) >12 ))         print '<b>Пароль</b> не может состоять меньше чем из <b>6</b> символов и больше чем из 12!'; }else{     if ($_POST['passw'] !== @$_POST['passw_re'])          print '<b>Пароль</b> не совпадает с подтверждением!';     else{         //мегаинструкции=)     } } ?>

Надеюсь, тут тоже нет, а то залипаю=)

да, через иф-елсе более правильно, впринципе. В моем случае он может выдать сразу несколько предупреждений. Например, при пустом пароле, выдаст "Вы не ввели пароль. Пароль не может быть меньше 6 и больше 12 символов". Нельзя сказать, что это плохой вариант. Но вобщем-то, пустить через иф-элсе может быть и лучше (однако я в своих скриптах проверяю именно в таком духе, как показал, что дает возможность сразу вывести все ошибки, если не соблюдено несколько условий).
Что касается собаки, то она исключает необходимость проверять наличие $_POST['passw_re']. Если $_POST['passw_re'] нет, то без собаки выскочит ошибка. Но нам-то все равно, есть или нет, нам нужно, чтоб совпало с паролем (наличие которого проверяется в первом условии). Поэтому, ставим собаку. Если $_POST['passw_re'] нет, благодяря собаке ошибка не вискочит, но сравнение будет идти с фальшивым условием. Это все равно, как с пустой строкой. Сравнение НЕПУСТОГО пароля с пустой строкой приведет к сообщению о несовпадении пароля и подтверждения.
Вроде доступно объяснил... Если нет - смотрим справочник.

Посмотрел более внимательно на свой код, заметил пару косяков. Нужно так:
if (! isset($_POST['passw'])){print 'Вы не ввели пароль';}
if (strlen(@$_POST['passw']) <6 || strlen(@$_POST['passw']) >12 ) {print '<b>Пароль</b> не может состоять меньше чем из <b>6</b> символов и больше чем из 12!';}
if (@$_POST['passw'] !== @$_POST['passw_re']) {print '<b>Пароль</b> не совпадает с подтверждением!';}

Или так:

if (! isset($_POST['passw'])){
print 'Вы не ввели пароль';
}else if (strlen($_POST['passw']) <6 || strlen($_POST['passw']) >12 ) {print '<b>Пароль</b> не может состоять меньше чем из <b>6</b> символов и больше чем из 12!';
} else if ($_POST['passw'] !== @$_POST['passw_re']) {print '<b>Пароль</b> не совпадает с подтверждением!';
}
(по варианту от Boeing)

Ну, на вкус и цвет...=) я предпочитаю грузить юзера поэтапно, а кое-в-каких местах вообще return'ом пользуюсь: ну не всю же логиику хакерам рассказывать, верно?:) Логика программная - это вообще вещь у каждого индивидуальная))) Когда нам в своё время давали задание сделать капчу и сгенерировать для неё случайную строку,... сразу было понятно, кто у кого списывал=)))... ибо у каждого своё мышление. Ещё пример, более простой, может быть: дано слово root. Надо сделать так, чтобы оно было написано с заглавной буквы. Те, кто не знал про ucfirst(), не сдались=))) они разобрали строку на части, выдернули первую букву... ну и т.д. Зато каждый показал, как можно "создать" встроенную функцию ucfirst() .=))) Была и куча заданий по воссозданию уже существующих встроенных функций... Но справились все=) и каждый по-своему)))

>if (! isset($_POST['passw'])) print 'Вы не ввели пароль';

- не совсем корректно вы не находите?
Поле может существовать но быть пустым.

нахожу. Если оно пустое, будет выдано сообщение, что оно короче 6 символов ;)
Вообще, тут, наверное, лучше так проверять:
if (! @$_POST['passw']) - если его нет, или оно пустое...
Тут же не стоит задача сделать идиальный код. Мы между делом даем подсказки. Не мудрено, что они не самые идиальные. Но, по крайней мере, это рабочие варианты.

хотя и проверяеться количество символов, но думаю немного получше будет:

if (empty($_POST['passw']))  print 'Вы не ввели пароль';

.

чем if (! @$_POST['passw']) плох?

Я не стал использовать функцию empty() вместо strlen() , чтобы точнее провериль поле ввода.
Т.К. насколько я знаю, одна строка символов 0 имеет значение false согласно правилам логических вычислений PHP. Это означает, что если ктото напечатает в поле "0", элемент $_POST['поле'] с содержанием "0", empty($_POST['поле']) имеет значение true, что с точки зрения проверки корректности заполнения формы является неправильным...

правильно я думаю или нет?

про empty - в десятку!=)))

а все таки, чем if (! @$_POST['passw']) плох?

я про тот, который вместо isset, а if (! @$_POST['passw']) , по-моему, ничем))) просто кто как привык)))

на счет isset - да. Тут и я и ты пошли по линии, изначально заданной автором топика :)
Я просто сайт верстаю, иногда поглядывая на форум - внимание рассеяно.

да я воще уже хочу три часа пойти спать))) ща сморю фильм))) Я всегда практически просо переписываю по-своему то, что мне дали, ну ты понял))) ну, чтоб работало. А более детальное рассмотрение - это уже тема отдельная.

Я дак лично if (! @$_POST['passw']) - вообще ниразу не встречал и не представляю что это значит

Я дак вообще вот как делаю:

<? $pass = mysql_escape_string(trim($_POST['pass1'])); $pass2 = mysql_escape_string(trim($_POST['pass2'])); ..................... if($pass!=$pass2) {$error = 1; $dis .="-Пароли не совпадают<br>";} ..................... if (!preg_match ("|^[0-9A-Za-z]{6}[0-9A-Za-z]*$|",$pass)) {$error=1; $dis .= "-В поле \"пароль\" нельзя использовать кириллицу, и пароль должен содержать больше 6 символов!<br>";} ..................

Кстати вроде из php6 убрали mysql_escape_string()(видел где-то на этом форуме, а сейчас не могу найти темы), а что-нибудь анологичное там есть?

завтра с утра проанализирую))) а пока бросилось mysql_escape_string. Пииши лучше mysql_real_escape_string, потому что первого в 6 версии уже не будет, вроде, а переписывать всё, я думаю, тебе бы вряд ли хотелось.

Я делаю всё через фильтровальную функцию, посколько я жуть-ленивый))) писать всё по сто раз)))

я делаю так:

function check(&$item, $key) {/     if (is_array($item)){         array_walk($item, 'check');// пока не доберемся до строки     }else{         // всяко-разно, смотря, что делать с данными планируется         // предположим, что их писать в базу, тогда так:         if (get_magic_quotes_gpc()) {             $item = stripslashes($item);         }         // Если переменная - число, то экранировать её не нужно         // если нет - то окружим её кавычками, и экранируем         if (!is_numeric($item)) {             $item = "'" . mysql_real_escape_string($item) . "'";         }         $item=trim($item);      } } @array_walk($_GET, 'check');

И весь ввод обработан одним махом

красиво) ладно я на боковую=) а то пятый час утра уже=)))

А зачем их mysql_escape_string до внесения в базу? Если они не совпадают, записи не будет. Зачем тогда лишние движения? ;)
Да и зачем подтверждение mysql_escape_string? Сначала сравнить пароли, потом основной mysql_escape_string и в базу...
А на счет этого: if (! @$_POST['passw'])...
Копирайт ;)
Бери на вооружение, пока не запатентовал и не начал продавать лицензии ;)

>А зачем их mysql_escape_string до внесения в базу?
Согласен не нужно их вообще, так как регулярка все равно кавычки не пропустит, а дальше все хешируеться, так что действительно лишние телодвижения, просто что-то автоматически получилось написать.

кстати, $item=trim($item); нужно сделать до escape_string. Это я просто собирал 2 функции в одну и неправильно местами поставил (у меня проверка ввода идет отдельно от mysql_real_escape_string. Блок с mysql_real_escape_string вызывается только тогда, когда нуно писать в базу).

if (@$_POST['passw']) то же самое, что if (!empty($_POST['passw'])), зачем лишние ! ставить?

это неакадемический финт. К нему еще адаптироваться нужно ;)

Либо я че-то путаю сейчас, либо если я введу такой пароль:
d'arta - вроде как шесть символов, но ведь вы их сначала экранируете - d\'arta - а потом длину проверяете. Итого у меня уже семь символов, а я буду в десятый раз печатать d'arta и не врубаться, где скрипт проверки нашел седьмой символ.
Да и вообще нахрен пошлют, типа низя такой пароль. А может я хочу, какое вам дело, будут в пароле кавычки или нет?
trim - еще ладно, но mysql_real_escape_string.. Пароли принято хранить в хэшированном виде. Так проверяйте на длину и хэшируйте :)

я привел обобщенный пример проверки. Другие люди привели свои примеры, которые применяют они. Может им вообще не нужно хранить пароли в базе? Тут реч уже зашла не столько о паролях, сколько о методах проверки ввода как такового.
Что же касается трим и ескейпстринг в моем примере, то я указал, что это вариант для записи данных в базу (данных вообще). О том, что ескейпстринг должен применяться ПОСЛЕ проверки пароля, ы уже тоже тут переписывались.
Так что, кто тусовался тут ночью, нормально друг друга понял и обменялся мнениями. Если кто-то из пришедших спустя несколько часов, не въехал - мы не виноваты :)
Читай внимательно. Мы начали с конкретного примера и перешли на обсуждение абстрактных идей.

Спасибо всем за советы, сейчас буду извлекать общий урок из всего этого.

думаю, все участники согласятся, что есть два хороших варианта (полцченных нами в ходе обсуждения):

if (! @$_POST['passw']){print 'Вы не ввели пароль';} if (strlen(@$_POST['passw']) <6 || strlen(@$_POST['passw']) >12 ) {print '<b>Пароль</b> не может состоять меньше чем из <b>6</b> символов и больше чем из 12!';}  if (@$_POST['passw'] != @$_POST['passw_re']) {print '<b>Пароль</b> не совпадает с подтверждением!';} Или так: if (! @$_POST['passw']){ print 'Вы не ввели пароль'; }else if (strlen($_POST['passw']) <6 || strlen($_POST['passw']) >12 ) {print '<b>Пароль</b> не может состоять меньше чем из <b>6</b> символов и больше чем из 12!'; } else if ($_POST['passw'] != @$_POST['passw_re']) {print '<b>Пароль</b> не совпадает с подтверждением!'; }

На проверку ввода на всякие иньекции пока можешь внимания не обращать. Субя по всему, тренировка пока идет на локалке и злые хакеры пока не страшны.

Да на денвере, но скоро нужно выгружать в инет...
Но проверку я сам напишу.
вот только скажите пожалуйста(я всего не знаю пока), что мне нужно запрещать?
думаю символы <>/ сто процентов надо запретить?

Зачем в пароле что-то запрещать? В пароле ничего запрещать не надо.
И вообще, к чему все эти проверки на длину и т.д. Пусть пароль будет такой, какой он хочет сам.
Логин - это уже другой вопрос, т.к. он будет выводиться в интерфейс.
Посмотрте задачу 21.

> На проверку ввода на всякие иньекции пока можешь внимания не обращать
Что за хрень вы говорите?! Вы понимаете вообще, что человеку советуете? Надо с первого же дня учить писать грамотно, без дыр в безопасности, а вы советуете забить на дыры. Так человек и сейчас забьет, и когда будет серьезный проект делать

Ну да... в логине нужно ведь проверку делать? длина, отсутствие кирилицы, и спец-символов?
Верно я рассуждаю? И нужно ли ещё чтото запретить в логине?

Чем вам мешает, например, крестик в логине? Если пользователь хочет каждый раз вводить этот спец символ - пусть вводят (правда, когда-то админил форум, где все поголовно наставили крестиков и всякой фигни, а потом начали плакать и просить убрать эти символы из логина)

Смотря для чего вы хотите использовать логин. На каких-то сайтах логин используется только для авторизации и имеется возможность ввести свое имя (а то и вообще обязательно), которое будет показываться другим пользователям. А на каких-то сайтах логин является также повсеместно выводимым идентификатором на фоне других пользователей (на форумах, например).
По логике - первый вариант надежнее, т.к. потенциальный брутфорсер не знает даже логина. А, пардон, пару логин+пароль брутить - это каким же дебилом надо быть, что собственно касатеся и программиста - надо пресекать возможность тысячу раз за секунду пробовать залогиниться.

На длину логин проверять конечно же надо, т.к. наверняка в базе есть ограничение на длину строки. Ну и чисто логически не может быть нормальным логин в 1-2 символа (я не говорю про имена людей, ведь есть Ян, Ю и тд)

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

При добавлении в базу никакие теги взломщику не помогут, главное не забывайте про mysql_real_escape_string()
При выводе из базы используйте htmlspecialchars()

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

Быстрой и качественной - говорите?
А вот у меня пароли по 25-30 символов.
Догадываетесь, что я говорю в адрес такого горе web-программиста, который мне предлагает уложиться в 12?

Читать внимательнее я бы советовал вам, ибо мой пост был обращен к другому человеку.

я взял на себя смелость ответить за всех участников обсуждения, так как к тому моменту все ушли спать, остался я один.

Насчет mysql_real_escape_string я уже признал ошибку и про хеширование написал, а что касаеться пароля, то я устанавливаю в правилах, что пароль и логин может содержать только цифры и латинские буквы, конечно с точки зрения пароля это не совсем граммотно, но как я успел заметить: пользователи натыкают всякой хрени в пароль, а потом забывают и далеко не на всех сайтах я могу позволить восстанавливать пароль на e-mail, поэтому если будет куча "забывчевых" пользователей, то сэтим могут возникнуть проблемы

А есть существенная корреляция между нетривиальными символами в пароле и числом заявок на восстановление доступа?

Конечно количество забывших пароль уменьшаеться не в разы, но все-таки на примерах 2-х практически идентичных сайтах(пароль можно было восстановить только при обращении к администратору) разница была видна в отношении количество зарегистрированных пользователей и количество забывших пароль

А еще мне интересно, на что рассчитывает человек, не указавший е-маил, забывший пароль и претендующий на восстановление доступа к эккаунту?
Какие аутентифицирующие аргументы он выдвигает?

>Какие аутентифицирующие аргументы он выдвигает?
Ну, например, общение через внутреннию почту веб-мани(вмид указываеться при регистрации)(получить доступ к вмид гораздо сложнее чем доступ к e-mail).
Сейчас хочу разобраться как сделать автоматическое восстановление пароля с отправкой сообщения на кипер, так чтобы данные по дороге не перехватили

А WMID подтверждается при регистрации?

Он подтверждаеться при автоматическом переводе через merchant, если введеный вмид расходиться с тем с которого пользователь сделал платеж(ввел деньги в систему), то администратору высылаеться уведомление и дальше в переписке по e-mail устанавливаеться причина этого.
Но чаще всего я делаю определение вмида автоматически при первом вводе средств и в дальнейшем клиент может выводить деньги только на кошельки этого вмида

чё-то тема совсем ушла от темы :)