Форум PHP

подскажите пожалуйста, как передать параметры из формы в функцию (например для проверки заполнения полей) ?? и что надо прописывать в action?

переменные формы (как правило) доступны в массиве $_POST[]

Вы учебник какой-нибудь не хотите почитать?

это я знаю.. и могу проверить в скрипте котрый вписан в action.. я просто преследую другую цель, я не знаю как вписать в action функцию?? напрмер которая проверяет клочество попыток ввода логина и пароля в форме авторизации... к сожалению в вашем учебнике PHP5 этого не написано...

action, это не место для указания функций РНР. Устанавливайте счетчик в сессии, и делайте ему декремент с каждым получением формы, так и узнаете что все попытки кончились, в том скрипте, которому как раз место в action.

Устанавливайте счетчик в сессии
Я понимаю что это пример, но лично я бы не стал количество вводов логин+пароль привязывать к сессии.

Привязывайте к чему хотите, но только не к функции указанной в action :) Кстати, чем вас сессия пугает?

Про экшин естественно, тут и к "бабке не ходи")
А вот сессия в данном случае не имеет смысла, "закрыл браузер" и сбросил счётчик. Если будут брутофорсить, то будут каждый раз стартовать новую сессию.

И что?

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

Кстати, по поводу проверок числа попыток аутентификации valick прав. Такие вещи не замыкают на сессию. Если делать - то прямо на БД. Точнее - на том, что хранит пароли.

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

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

Вы хотите сказать, что при обращении к этому скрипту (при отправке формы), будет создаваться новая сессия? Это будет при новом старте браузера, в другом случе нет. Теперь, мы проверяем это в том случае, когда неверен ввод логина и пароля, и если бы я с каждым запросом мог гарантировано идентифицировать запрашиваемого, тогда я бы понял разницу, иначе не могу.

гарантировано идентифицировать запрашиваемого
А это ещё зачем? Как вы думаете сколько раз ошибётся реальный пользователь в наборе собственного пароля?
Чем выше безопастность, тем больше неудобств для пользователя. Тут нужна золотая серидина. И если брутофорсят мой аккаунт... лично меня необломает потерпеть несколько минут или ввести логин пароль несколько раз.

>Вы хотите сказать, что при обращении к этому скрипту (при отправке формы), будет создаваться новая сессия? Это будет при новом старте браузера,

Этого достаточно

гарантированная идентификация запрашиваемого - это и есть цель любой аутентификации.

Ну при закрытии браузера, вам и в случае работы с базой все заново придется начинать - со 100% вероятностью узнать, что это один и тот же ломиться, можно только, если ломится дилетант. Я просто не вижу разницы от куда вы будете брать итирацию счетчика.

Так а такие системы не проверяют, один и тот же ломится, или разные.
Если число неудачных попыток на некотором интервале времени превышает допустимое, эккаунт блокируется [на некоторый карантинный период].
При этом неважно, откуда идут попытки.

Вы мне объясните, какая разница будет при этом от куда берется счетчик попыток, браузер не закрывается - 1, и браузер закрывается - 2? При закрытии браузера, вы будете заново инициализировать счетчик попыток?

При закрытии браузера, вы будете заново инициализировать счетчик попыток
Нет. В базе хранится число попыток (или просто флаг неудачной авторизации) и время последней неудачной попытки. Как только интервал времени между неудачными попытками превышает заданный (допустим 1 минута) счётчик, к примеру, обнуляется.
В прошлом году я думал над защитой при подборе пароля, и нюансов там много (но речь сейчас не об этом) вплоть до создания ложного аккаунта, так как брутофорс работает "до удачной авторизации" это создаст массу проблем при подборе пароля.

Valick только не надо ля-ля. Если я буду знать, что меня Петя Иванов беспокоит, и что этот счетчик, это счетчик Пети Иванова. Иначе я могу пропустить куда более злостного фигуранта.

Valick только не надо ля-ля
Ля-ля - это я так с дочкой общаюсь))) А здесь вроде-бы выражаюсь куда уж яснее.
Тем более что брутофорсы "злостного фигуранта" обращаются к вам через кучу прокси серверов, понять от одного это клиента или нет практически невозможно, да и ненужно это вовсе.
Главное это частота обращения к вашему скрипту авторизации, ко всему остальному жёстко привязыватся нельзя (хотя и стоит учитывать).
А вот после успешной авторизации надо уже "охранять" сессию. О чём мы жарко дискутировали совсем недавно. Да так и не сошлись во мнениях с БенЛаданом (ну непонимаю я что даст хранение пароля в сессии, ну да ладно кто старое помянет....) и это уже совсем другая история.

Вы скажите в чем разница между тем, что я буду держать число 5 в базе или сессии. Закрыли браузер и что? Какая разница в том, что число привязано к базе или число привязано к сессии? Мне в любом случае придется инициировать счетчик, если оборвали попытки, а потом возобновили вновь.

Вы скажите в чем разница между тем, что я буду держать число 5 в базе или сессии.
Говорю (не первый раз):
Если каждый раз стартовать сессию (и поверьте мне нормальный брутофорс будет этто делать), то у вас никогда небудет числа 5, а максимум число 1.
Базе абсолютно без разницы закрываете вы браузер или нет)))

Если каждый раз открывать сессию, это значит заново стартовать регистрацию. Если ваше число в базе, тогда что, при каждом старте вы его будете уменьшать, в независимости от того, кто стартует регистрацию?

SELECT id, attempts,  FROM users WHERE login = $login; UPDATE users SET attempts = attempts + 1 WHERE id = $id;

почему вне зависимости?

ps. упрощенно, конечно. Реальный код куда сложнее.

Нет, так не пойдет. Мне кто-то хочет впарить логин с паролем. Я проверяю, что такого в базе нет и ставлю товарища на счетчик. И куда и кому в таблице я должен писать это, если такового товарища у меня нет? Предположим тогда, что я этот счетчик храню в некой таблице "черного списка", пусть даже это то, что вы прописали. Вопрос - и чем это отличается от использования сессии?

Если логина нет - никому.
Если логин есть - логину.
На счетчик ставится именно логин. При чем на счетчик в пределах локального интервала времени.

Хотя, конечно точно также можно и IP на счетчик поставить...

Так в том и вопрос, что не всегда гарантированно можно узнать этот действительный IP. Я не вижу разницы между сессией и базой. Если обращается существующий логин, еще можно говорить о выгоде базы, иначе принципиальной разницы нет.

Я знаю, что не всегда. Но IP шлюза можно узнать в любом случае.
Конечно временно блокировать шлюз - ответ более жесткий, да и вообще с таким блокировками нужно быть предельно аккуратным.

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

>Если каждый раз стартовать сессию ... то у вас никогда небудет числа 5, а максимум число 1.

С чего бы это? Запрос на регистрацию идет не к сессии, а к скрипту обслужавающему эту сессию. При каждом новом запросе я инициализирую сессию и счетчик. Откуда 1?

Запрос идёт к скрипту, верно, но скрипт берёт данные из сессии и если сессии до этого небыло(данных естественно нет), то скрипт начинает считать с нуля.
Итак поехали.
1) Юзер открывает браузер.
2) Вводит логин и пароль.
3) Данные передаются скрипту обработчику.
4) Стартуется сессия. если переменные сессии неопределены (а они неопределены потому что это первое обращение к скрипту в рамках данной сессии), то счётчик равен нулю.
5) Скрипт проверяет логин пароль на соответствие. если да, то "в путь"..., если нет, то в сессию записывается 1 (первая неудачная попытка)
6) Юзер закрывает браузер.
7) Сессия ещё живёт какое-то время, но данные этой сессии вы уже "не достаните".
И теперь всё повторяете с пункта один.
В итоге в сесии максимум число 1.

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

<? session_start(); if (!isset($_SESSION['time'])) $_SESSION['time'] = 5; if ($_POST['log'] && $_SESSION['time']) $_SESSION['time'] -= 1; echo $_SESSION['time']. "<br>"; if (!$_SESSION['time']) echo "Приехали!"; ?> <form action="" method="post"> <input type="submit" name="log" value="Send"> </form>

Открыл

Notice: Undefined index: log in z:\home\localhost\www\Project\softtime\sim5.php on line 4 5

Нажал

4

Закрыл
Открыл

Notice: Undefined index: log in z:\home\localhost\www\Project\softtime\sim5.php on line 4 5

???

Разбирайтесь у себя, никаких ошибок у меня не выдает. Или добавьте проверку на isset($_POST['log'])

А чего тут разбиратся? Если перефразировать мои слова применительно к вашему скрипту, то: если открывать и закрывать браузер, то никогда не будет слова "Поехали", а только 5 (я говорил 0) и 4 (я говорил 1)
Нотисы естественно меня неволнуют в данном случае.

Если вы будете открывать и закрывать браузер, то это ваша проблема - не хотите регистрироваться не надо. Если вы говорите о блокировке "настырника", то вам и база не поможет. Если вы говорите что можно "завалить" сервер запросами, то разницы никакой - база или сессия работает. И вообще, такое впечатление от ваших слов, что базу можно "насиловать" так как она дева, а сессию нельзя так как она старуха. ;-)

Что касается 1, то совсем не понятно, о какой 1 вы твердите.

Если вы будете открывать и закрывать браузер, то это ваша проблема - не хотите регистрироваться не надо
У меня никакой проблемы нет... Может у вас там сейчас очень поздно и вы сильно хотите спать?))) А посему ваш разум затуманен слегка) Вы хотите сказать, что я как истинный владелец аккаунта не могу зайти в него набрав логин+пароль один раз?))

Если вы истинный владелец, то вас и не надо ставить на счетчик. Речь то идет о плохих мальчиках, которым даем попыток, бог любит троицу, значит 3. А коли такой будет отгадывать и логин и пароль, то вы будете вынуждены где-то временно чего-то записывать в базе. Я же буду использоваться сессию. Разница в данном случае будет только в том, что мои сессии будут удалены автоматом, а вы свой "мусор" накопленный в базе должны еще очистить сами. Другой принципиальной разницы я не вижу.

Разница в том, что ваш код (я даже название ему придумал "День сурка") работать не будет... вот и вся разница.
Я делаю первую попытку.. закрываю браузер.. открываю.. и у меня сова первая попытка и так тысячу миллионов раз...

Ну да, а ваш "день сурка" не будет учитывать кто к вам стучиться и будет с радостью сбрасывать счетчик с каждым запросом? Можно подумать, что неким волшебным способом ваш код идинтифицирует любого пользователя и таки работает. Напишете свой волшебный код, чтобы не пустословить зря.

-

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