Распространенная ошибка при проверке капчи

[@jandosul]

PHPShop — плохая шутка, черный юмор

[@nerezus]

У нас в 1C свои индусы битрегз делали ;)

[@ZiNTeR]

Нет, не соласен — на такое даже Индусы не пошли :)

[@bloodmoon]

«техподдержка работает только для покупателей скрипта.» — оригинальная защита от хакеров :)

[@pyatin]

Вечный редирект на help.phpshop.ru тоже очень оригинально выглядит.

[@azizoid]

логичнее сначала проверить !empty а потом уже сравнивать.

[@filipchuk]

еще логичнее сначала проверить на существование переменных, isset(...)

[@ivolodin]

Еще одна расспространенная ошибка использовать и isset и empty…

[@ivolodin]

Вместе я имел ввиду

[@devolonter]

это не ошибка, если переменная будет не isset то при включенном показе warningов будет выдано предупреждение. Empty не тоже самое что не isset, так как isset проверяет существует ли перменная(но она будет существовать даже если она пустая), а empty проверяет на пустоту

С уважением Кэп

[@ivolodin]

Никто и не говорит, что «тоже самое». Empty просто уже включает проверку как на «не существование» переменной, так и на ее пустоту и warning`а не даст.
Я к тому, что вместе их использовать не имеет смысла (часто встречаю запись у некоторых перестраховщиков):
if ( isset($a) && !empty($a) ) {
...
}

достаточно
if ( !empty($a) ) {
...
}


[@ivolodin]

так, что господин abdalAziz несомненно прав, а filipchuk — перестраховывается

[@devolonter]

действительно, извиняюсь. Вы подтвердили что это «еще одна распространенная ошибка») Почему то был уверен что empty при работе с несуществующей переменной выкинет warning.

[@ivolodin]

Не выкинет

[@ivolodin]

Поймите наконец
<?php
if (!empty($a)) {
...
} else {
...
}

echo $b;
?>

При отсутствующих переменных $a и $b нотис только на $b

[@pixxxel]

Вы несомненно правы, спасибо

[@cachealot]

перешел по ссылке и зарегался :)
круто, ничего не скажешь

[@pixxxel]

Интересно смотреть на список пользователей в админке
demo.phpshopcms.ru/phpshop/admpanel/admin.php
(Пользователи → Обзор пользователей)
Кстати, почему некоторые получаются «оптовиками»?

[@Sk8er]

А в чём она? Всё равно уже спалили :)

[@misterio]

Так капча же каждый раз вроде перезаписывают $_SESSION или я не прав?

[@second_pilot]

если перезапись стоит на запросе к картинке, то не факт

[@azizoid]

Вы меня убили. Как вообще можно делать иначе?

[@egorinsk]

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

[@pixxxel]

> чтобы не перевводить ее при каких то ошибках
Тогда можно будет один раз ввести капчу, а дальше спокойно переберать ботом ваш пароль на сайт
(если капча при входе на сайт, как на хабре)

[@AzriMan]

Сам столкнулся с подобным года 2 назад, когда вставлял каптчу в один проект. некоторое время не мог понять — почему с отключенными картинками проходила любая каптча :) причина была аналогичная.

[@Scala]

Хорошо сделана платформа для магазинов у Shopify(http://www.shopify.com/)
Для любой «халтуры» надо брать Hosted-решения: Shopify, Wordpress.com, Google Sites.
В остальных случаях: фреймворк(Zend, RoR, Grails) + плагины Shopping Cart/CMS/etc, поддерживать, развивать и лезть внутрь будет куда удобнее чем с Bitrix/Joomla/PHPShop и прочими монстрами.

[@Scala]

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

[@beono]

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

$_SESSION['captcha']

приведет к тому, что капча из первой страницы автоматом будет неверной т.к. затрется капчей со второй страницы.

[@VEG]

Это проблема многих движков. Проще сохранить одно значение на пользователя, чем целую таблицу.
Например в phpBB3 для всех диалогов и форм генерируется случайный код и вставляется в скрытый input. Если этот код не совпал с последним сгенерированным — действие не производилось. То есть если открыть в одном окне диалог удаления сообщения, а во втором — диалог удаления пользователя, то после подтверждения обоих действий сработает только второе.
Разработчики подобное поведение связывают с повышенной безопасностью скрипта, я не разделяю их мнение.
Вот небольшая статья по поводу: veg.slutsk.net/blog/2008/08/10/phpbb3-multiple-confirm-box/

[@VEG]

Удивлен, но мне совсем недавно пришлось исправлять такой же код в совершенно другом скрипте (F-CMS). Боты просто не загружали картинки, и без проблем отправляли спам в гостевую. Не знаю, было ли это скопировано из phpshop. Что-то мне подсказывает, что где-то подобный код приведен в качестве примера использования капчи.

[@halawin]

да что вы говорите, PHPShop — одна сплошная ошибка.

[@KOS_MOS]

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

[@michas]

похоже что исправили уже

[@pixxxel]

Действительно. И базу пользователей очистили.

[@Elvalery]

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