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

Question

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

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

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

Схема для таблицы я буду хранить их:

thread_id user_id vote_type 
2334  1   2 

До сих пор я пришел с этими точками пулевых:

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

Update:

"Так, вероятно, используя логин куки для идентификации пользователя" - Andrew

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

Вопрос:

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

Поблагодарите за подсказку и профайл для тех, кто реализует подобную технику.

Answer 1

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

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

Answer 2

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

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

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

Answer 3

создать уникальный индекс на полях (thread_id, user_id) и DBEngine защитит вас от Multy комментариев на одну нить :)