Безопасен ли этот метод проверки «подарочного кода»?

Question

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

Я работаю над лучшим способом проверки правильности кодов без коллизий / дуплисов или чего-то в этом роде. Мне нужно 1) подтвердить код 2) собрать информацию о доставке

Мой первый черновик был

A) Проверьте код с помощью формы, если это хорошо, перейдите к вводу адреса. Когда вход получен, сохраните код и адрес / имя и т. Д.

Это терпит неудачу, потому что если в коде 75 использовалось 74 использования, 25 человек могли бы «подтвердить», но еще не ввести свой адрес, и мы получили бы более 75 действительных погашений.

Мое текущее решение больше похоже на:

B) Просто укажите код в качестве первого поля в форме для сбора информации, и, когда введен действительный код, измените его и проверьте в реальном времени по БД. Если код действителен, он показывает остальную часть формы, и эта запись кода «запрашивается» в течение получаса или чего-то еще. Если через полчаса нет записи в БД, она освобождается.

Это кажется довольно сложным, и мне интересно, нужно ли мне делать удушение против попыток ajax, чтобы убедиться, что люди не переборщили действительный код.

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

Answer 1

Пусть каждый введет свой подарочный код и адрес, а затем отправит

В серверной части проверьте адрес и подарочный код.

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

Это должно быть сложнее, чем это?

Answer 2

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

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

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

Answer 3

Почему бы вам не иметь одну форму со всей информацией (код погашения и информация о доставке)?

Затем, когда пользователь отправляет запрос, атомарно (используя транзакции в вашей базе данных) проверяет его действительность и фиксирует информацию пользователя.

Если код больше не действителен, просто покажите сообщение «Извините, использованный вами код погашения исчерпан и больше не действителен».

Answer 4

Мы делаем шифрование низкого уровня (RC4) с добавленной контрольной суммой для этого типа вещей. Поскольку RC4 генерирует проблемный набор символов, мы также преобразовали его в HEX. Комбинация относительно безопасна и самопроверка. Расшифрованное значение - это просто число, которое мы можем проверить в базе данных. Это работает как с нашими напоминаниями по электронной почте, так и с подарочными сертификатами.

Answer 5

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

То есть:

• Клиент вводит код
• Проверить код - если он действителен и еще не используется MAX + раз, добавьте дополнительную запись в таблицу использования кода с отметкой времени, срок действия которой истекает через x минут.
• Сбор другой информации
• При отправке навсегда пометить код как использованный (удалить срок действия записи)
• Если клиент никогда не делает заказ, запись с меткой времени удаляется (или игнорируется) после времени x и освобождается для использования другими.

Answer 6

Вариант B кажется разумным. Просто используйте капчу, а не пытайтесь ее задушить. Капчи не идеальны, но они менее неприятны, чем, скажем, неправильное прочтение кода три раза, а затем отказ в возможности попробовать другой в течение 24 часов. Это будет работать особенно хорошо, если вы уже планируете делать это AJAXy.

Итак -
Пользователь заполнит поле кода и код с картинки.
Вы подтвердите код проверки, а затем подтвердите код.
В случае успеха, пользователь заполнит другую информацию и отправит.

Используя этот метод, вы также можете, вероятно, блокировать код только на 5 минут (в стиле агентства по продаже билетов) и показывать таймер в форме, где-то уведомляя пользователя.

Answer 7

Ваше текущее решение выглядит как правильное, хотя я думаю, что вы исключили метод, с помощью которого вы связываете пользовательскую ассоциацию с кодом. Тем не менее, обеспечение функциональности «резервирования» погашения кода для пользователя является хорошим решением.