Comments 43
«техподдержка работает только для покупателей скрипта.» — оригинальная защита от хакеров :)
Вечный редирект на help.phpshop.ru тоже очень оригинально выглядит.
логичнее сначала проверить !empty а потом уже сравнивать.
еще логичнее сначала проверить на существование переменных, isset(...)
Еще одна расспространенная ошибка использовать и isset и empty…
Вместе я имел ввиду
это не ошибка, если переменная будет не isset то при включенном показе warningов будет выдано предупреждение. Empty не тоже самое что не isset, так как isset проверяет существует ли перменная(но она будет существовать даже если она пустая), а empty проверяет на пустоту
С уважением Кэп
С уважением Кэп
Никто и не говорит, что «тоже самое». Empty просто уже включает проверку как на «не существование» переменной, так и на ее пустоту и warning`а не даст.
Я к тому, что вместе их использовать не имеет смысла (часто встречаю запись у некоторых перестраховщиков):
достаточно
Я к тому, что вместе их использовать не имеет смысла (часто встречаю запись у некоторых перестраховщиков):
if ( isset($a) && !empty($a) ) {
...
}
достаточно
if ( !empty($a) ) {
...
}
Вы несомненно правы, спасибо
перешел по ссылке и зарегался :)
круто, ничего не скажешь
круто, ничего не скажешь
Интересно смотреть на список пользователей в админке
demo.phpshopcms.ru/phpshop/admpanel/admin.php
(Пользователи → Обзор пользователей)
Кстати, почему некоторые получаются «оптовиками»?
demo.phpshopcms.ru/phpshop/admpanel/admin.php
(Пользователи → Обзор пользователей)
Кстати, почему некоторые получаются «оптовиками»?
Так капча же каждый раз вроде перезаписывают $_SESSION или я не прав?
Хехе :)) Актуальная тема кстати, наверно из-за популярнорсти той же kcaptcha, которая сама создает сессию и сохраняет код при обращении к картинке. По идее, код капчи должен генерироваться при выдаче формы (ну или при первой выдаче, чтобы не перевводить ее при каких то ошибках).
Сам столкнулся с подобным года 2 назад, когда вставлял каптчу в один проект. некоторое время не мог понять — почему с отключенными картинками проходила любая каптча :) причина была аналогичная.
Хорошо сделана платформа для магазинов у Shopify(http://www.shopify.com/)
Для любой «халтуры» надо брать Hosted-решения: Shopify, Wordpress.com, Google Sites.
В остальных случаях: фреймворк(Zend, RoR, Grails) + плагины Shopping Cart/CMS/etc, поддерживать, развивать и лезть внутрь будет куда удобнее чем с Bitrix/Joomla/PHPShop и прочими монстрами.
Для любой «халтуры» надо брать Hosted-решения: Shopify, Wordpress.com, Google Sites.
В остальных случаях: фреймворк(Zend, RoR, Grails) + плагины Shopping Cart/CMS/etc, поддерживать, развивать и лезть внутрь будет куда удобнее чем с Bitrix/Joomla/PHPShop и прочими монстрами.
ну это дебилом нужно быть :)
более того, если пользователь откроет хотя бы две разные страницы, на которых нужно вводить капчу, то этот вариант
$_SESSION['captcha']
приведет к тому, что капча из первой страницы автоматом будет неверной т.к. затрется капчей со второй страницы.
более того, если пользователь откроет хотя бы две разные страницы, на которых нужно вводить капчу, то этот вариант
$_SESSION['captcha']
приведет к тому, что капча из первой страницы автоматом будет неверной т.к. затрется капчей со второй страницы.
Это проблема многих движков. Проще сохранить одно значение на пользователя, чем целую таблицу.
Например в phpBB3 для всех диалогов и форм генерируется случайный код и вставляется в скрытый input. Если этот код не совпал с последним сгенерированным — действие не производилось. То есть если открыть в одном окне диалог удаления сообщения, а во втором — диалог удаления пользователя, то после подтверждения обоих действий сработает только второе.
Разработчики подобное поведение связывают с повышенной безопасностью скрипта, я не разделяю их мнение.
Вот небольшая статья по поводу: veg.slutsk.net/blog/2008/08/10/phpbb3-multiple-confirm-box/
Например в phpBB3 для всех диалогов и форм генерируется случайный код и вставляется в скрытый input. Если этот код не совпал с последним сгенерированным — действие не производилось. То есть если открыть в одном окне диалог удаления сообщения, а во втором — диалог удаления пользователя, то после подтверждения обоих действий сработает только второе.
Разработчики подобное поведение связывают с повышенной безопасностью скрипта, я не разделяю их мнение.
Вот небольшая статья по поводу: veg.slutsk.net/blog/2008/08/10/phpbb3-multiple-confirm-box/
Удивлен, но мне совсем недавно пришлось исправлять такой же код в совершенно другом скрипте (F-CMS). Боты просто не загружали картинки, и без проблем отправляли спам в гостевую. Не знаю, было ли это скопировано из phpshop. Что-то мне подсказывает, что где-то подобный код приведен в качестве примера использования капчи.
да что вы говорите, PHPShop — одна сплошная ошибка.
могут возникнуть проблемы с проверкой через ajax — к примеру если юзер один раз неправильно ввел капчу, то необходимо перезагрузить изображение с капчой, так как значение из сесии уже удалено.
похоже что исправили уже
пользуйтесь reCapcha и будет счастье и отсутствие подобных проблем. а еще она она пользу приносит, да
Sign up to leave a comment.
Распространенная ошибка при проверке капчи