D'accord, je prévois donc de créer un site Web avec la fonctionnalité UPVote / Downvote. Sans entrer dans trop de détails sur le reste du site, les utilisateurs pourront soumettre des contenus pouvant être votés (similaires à Reddit dans ce sens - et dans ce sens uniquement). Les seuls "comptes" sur ce site seront destinés aux administrateurs et aux modérateurs, ce qui m'amène à la question principale: p>
Le site sera également effectué avec Django et MySQL, ce qui m'amène à ma deuxième question: p>
Quelqu'un pourrait-il me dire dans la direction générale de la manière de mettre en œuvre les fonctionnalités que je veux? J'y ai pensé et j'ai pensé à des méthodes utilisant des variables de session, des cookies et / ou des adresses IP. Je sais qu'aucune solution n'est parfaite sans comptes, mais je veux juste quelque chose qui fonctionne assez bien pour empêcher les gens de spammer des votes. Je suis désemparé, alors toute aide est appréciée. P>
5 Réponses :
avec beaucoup de difficulté. P>
La raison pour laquelle la plupart des autres sites qui effectuent des comptes upvote / bowvote-ing sont parce qu'il n'y a pas à peu près autrement que de garantir à un utilisateur ne pourra pas voter deux fois sur la même chose. P>
Les informations à votre disposition qui devraient "réduire" votre portée de savoir si cet utilisateur a voté avant: p>
Comme vous pouvez le voir clairement, toutes ces informations sont sujettes à modification et la plupart d'entre elles peuvent être contrôlées à volonté par un utilisateur malveillant. Si vous souhaitez vous protéger des utilisateurs malveillants, la meilleure voie à suivre concerne les comptes d'utilisateurs. P>
Si vous voulez simplement vous protéger des utilisateurs légitimes votants deux fois, utilisez simplement des adresses IP - ils sont persistants suffisamment em> que les utilisateurs moyens ne pourront pas voter deux fois dans un court espace de temps. . p>
Je suis désolé, je ne peux pas être plus assistance, je suis au courant, cela est toujours l'une de ces grandes questions sans réponse. Beaucoup de gens aimeraient pouvoir garantir un visiteur est identique ou différent du visiteur précédent qu'ils ont obtenu, pour des centaines de raisons différentes, mais ce n'est pas possible en utilisant la technologie actuelle. P>
Toujours pas possible 6 ans plus tard, hélas. L'empreinte digitale du navigateur est une technique que vous pouvez utiliser, mais elle n'est nulle part près d'une garantie et également facile à contourner comme un utilisateur malveillant. Les comptes d'utilisateurs sont toujours la voie à suivre.
Stocker une table des votes: Vérifiez cela lors de la publication pour vérifier que cette adresse IP n'a pas été affichée sur cette question. Pas parfait, mais plutôt bon. P> Somme de cette table sur le vote_value code> Colum pour un post_id code> pour trouver les votes d'un post. P > p>
Pour mettre le meilleur moyen de limiter les utilisateurs de voter plus d'une fois sur piste par IP ( en supposant que vous ne souhaitez pas forcer l'utilisateur à vous connecter et à avoir un compte em>. Les cookies peuvent être effacé facilement ou l'utilisateur pourrait simplement changer de navigateur. p>
Recherchez sur le suivi de l'adresse IP à l'aide de PHP et rangez-les dans une DB.
http://php.net/manual/fr/function.getenv.php p>
Je recommande vivement d'utiliser des comptes d'utilisateurs pour minimiser les problèmes. L'utilisation de la propriété iPaddress n'est pas une tâche facile. Prenez l'exemple simple Certaines entreprises ne fournissent qu'une iPaddress au monde extérieur. Dans ce cas, votre communauté n'aura pas une distribution appropriée et les personnes peuvent interroger votre système de vote. Mais si vous avez décidé d'y aller avec le système de compte d'utilisateur, vous pouvez suivre quelque chose comme ceci:
post_table +------------+------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+------------------+------+-----+---------+----------------+ | postId | int(10) unsigned | NO | PRI | NULL | auto_increment | | userId | int(10) unsigned | NO | MUL | NULL | | | postTime | bigint(20) | NO | | NULL | | | post | text | NO | | NULL | | | upVote | int(11) | YES | | 0 | | | downVote | int(11) | YES | | 0 | | +------------+------------------+------+-----+---------+----------------+ user_of_website +--------------+------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------+------------------+------+-----+---------+----------------+ | userId | int(10) unsigned | NO | PRI | NULL | auto_increment | | userName | varchar(50) | NO | | NULL | | | numPosts | int(10) unsigned | NO | | 0 | | | postsCount | int(11) | NO | | 0 | | +--------------+------------------+------+-----+---------+----------------+
Une ancienne question mais je vais prendre un coup de feu. p>
En fin de compte, tout système tentative de légitimité de vote contre les utilisateurs malveillants devra exploiter le CAPTCHA (ou certains équivalents empêchant le bot), mais la création de compte réelle n'est pas nécessaire. Une fois qu'un utilisateur vérifie son humain-ness via Captcha, stockez un cookie sur son ordinateur qui code ses données d'adresse IP. Tant que l'utilisateur conserve ce cookie, il peut voter avec elle comme une clé et vous pouvez utiliser la touche (adresse IP) comme identifiant. Si le cookie est supprimé d'une manière ou d'une autre, vous le récidiviez simplement à travers CAPTCHA et récupéré son adresse IP. p>
Bien sûr, un utilisateur malveillant pourrait facilement spoiser une adresse IP, mais CAPTCHA l'empêcherait de faire plus que quelques-uns à la fois, il ne s'agirait donc que de perturber comme un utilisateur malveillant sur un réseau basé sur un compte. faux comptes. p>
Vous devez stocker des upvotes et des bowvotes séparément, notamment en raison de problèmes de concurrence à la mise à jour du nombre de vote.
En limitant via une adresse IP, vous perdez une grande partie de votes possibles. De nombreuses écoles, entreprises et même dortoirs utilisent 1 adresse IP extérieure pour de nombreux utilisateurs. Il n'y a pas de bon moyen de mettre en œuvre un système sans avoir des comptes d'utilisateurs. Parce que la limitation de 100 employés d'avoir 1 personne vote sera inexacte, tout comme n'ayant aucune limite IP.
@JCLASPILL J'aurais dû mentionner cela dans ma question, mais le site Web est en fait ciblé pour les élèves de mon université (j'ai même prévu de faire de l'affichage de contenu exclusivement exclusif). Quelles sont les chances que mon université de plus de 28 000 étudiants utilise la même adresse IP pour tout le monde?
@Garbb tous 28000? Meugler. De beaux morceaux de ce 28000? Je dirais assez haut si vous faites cela des salles de classe. Si elle est hébergée en interne, pas une grosse affaire, je ne penserais pas, comme vous pouvez détecter leur adresse IP informatique et non réelle IP du monde. Cependant, si vous l'hébergez sur un système extérieur, je vais deviner que cela vous fera mal de vos chances. Le meilleur moyen est de demander votre service informatique comment les réseaux sont configurés. Si chaque bâtiment est un système distinct, je devine 1 vote par bâtiment serait mauvais. J'essaie de vous «tristesse», mais assurez-vous de vous assurer de connaître les chances.
@JCLASPILL Merci pour le conseil. Je vais certainement essayer de comprendre comment les réseaux sont installés avant de faire quelque chose de stupide.