Стратегия уникального пользовательского голосования, такого как Stackoverflow? - PullRequest
Новая
       17

Стратегия уникального пользовательского голосования, такого как Stackoverflow?

2 голосов
/ 12 января 2010

Я заметил, что для голосования SO реализует метод XHR, который отправляет POST-сообщение контроллеру сообщений и отправляет идентификатор сообщения и тип голосования через URL, кроме того, отправляется параметр fkey, например: 

http://stackoverflow.com/posts/1/vote/2

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

Схема таблицы, в которой я буду их хранить: 

thread_id   user_id   vote_type
2334        1         2

Пока я придумал следующие пункты:

  • убедитесь, что пользователь вошел в систему
  • обеспечить отправку действительного идентификатора записи и типа голосования
  • убедитесь, что после POSTing пользователь ранее не голосовал
  • код, который создает хеш, не может содержать динамическую информацию, такую ​​как пользовательский агент, поскольку пользователь может находиться в другом браузере, другой ОС, верно?

Обновление:

"Вероятно, SO использует cookie для входа в систему для идентификации пользователя." - Андрей

Может ли кто-нибудь продемонстрировать, как это будет сделано, или, другими словами, более конкретно привести пример того, как генерируется fkey, который представляет собой буквенно-цифровую 32-битную строку?

Вопрос:

  • , поскольку я нигде не отправляю фактический идентификатор пользователя с моим кодом XHR, означает ли это, что мне нужно обновить схему таблицы, чтобы я мог сохранить fkey вместо, скажем, user_id? fkey, вероятно, должен быть уникальным для каждого пользователя, и поэтому я, вероятно, могу спросить, есть ли в таблице голосования строка, в которой есть кнопка fkey.

Буду признателен за любые советы или советы любому, кто внедрил подобную технику.

Ответы [ 3 ]

2 голосов
/ 12 января 2010

создайте УНИКАЛЬНЫЙ индекс по полям (thread_id, user_id), и DBengine защитит вас от многократных комментариев в одной теме :)

1 голос
/ 12 января 2010

Я думаю, это зависит от того, насколько сильно вы хотите помешать людям повторно отправлять или возиться с вашими данными. Ничто не будет на 100% (если только ваш бюджет не зашкаливает), но вы можете сделать хорошую работу, чтобы удержать большинство людей от повторной подачи по:

  • проверить их UID - или сгенерированный идентификатор из UID (я объясню)
  • записать свой IP-адрес и проверить в базе данных IP и идентификатор отправки (вместе с сгенерированным UID)

Использование только IP-решения, может быть побеждено с помощью прокси-сервера или соединения, которое часто меняет IP-адреса, например, как оператор DSL в моем городе (но даже тогда, каждые пару дней). Я лично генерирую уникальный ключ на основе UID этого человека и передаю его обратно и четвертый при необходимости. Соленый хеш MD5 обычно работает нормально, или даже реализация AES, если MD5 рассматривается как слишком слабый. В сочетании вы должны иметь хорошее стартовое место.

1 голос
/ 12 января 2010

Вы можете просто как-то подписать URI, чтобы пользователи не могли манипулировать valuse. Например, вы можете хэшировать части URI с секретом и добавлять хэш к URI. Когда пользователи копируют URI и изменяют значения, URI и подписанная часть становятся недействительными.

Это часто делается в API RESTful, и ваш текущий подход похож на.

...