如何实现无需登录的匿名单次评分组件？访客识别方案咨询

Great question! For your use case—letting unauthenticated users upvote/downvote once, no login required, no user tracking, and low security requirements (you don’t need to block determined bad actors)—here’s a breakdown of each approach and what works best:

1. Using IP Address Only #

• Pros: Super simple to implement. Just log the IP address of each vote on the backend, and block future requests from the same IP for that item. No frontend work needed.
• Cons:
  • Shared IP issues: Users on the same network (office, school, home WiFi) share an IP. If one person votes, everyone else on that network gets blocked—terrible for user experience.
  • Dynamic IPs: Mobile users switching between WiFi and cellular will get a new IP, letting them vote multiple times anyway.
• Verdict: Not recommended. The user experience tradeoffs are way too big for most cases.

2. Cookie or localStorage #

• Pros:
  • Targeted to the user’s browser/device: No shared IP false blocks. Each user’s browser stores a simple flag, so only they’re restricted after voting.
  • Low implementation cost: Frontend can just do localStorage.setItem('voted_post_456', 'true') after a vote, then check for that flag to disable the buttons on page load. For a tiny bit more robustness, use an HttpOnly cookie set by the backend (so users can’t easily edit it via dev tools).
  • Privacy-friendly: You’re only storing a minimal flag (e.g., "voted on post X")—no user identity data, so you’re not tracking anyone.
• Cons: Users can clear cookies/localStorage, use incognito mode, or switch browsers to bypass the restriction. But since you said you don’t need to stop determined bad actors, this is totally acceptable.
• Verdict: This is your best bet. It hits all your requirements with minimal effort.

3. Combining Multiple Methods (IP + Cookie/localStorage) #

• How it works: Check both the user’s IP and their stored flag (cookie/localStorage) on the backend. For example, if a user clears their cookie but uses the same IP, you can still block them; if their IP changes but the cookie exists, you block them too.
• Pros: Adds a small layer of robustness over single-method approaches, reducing accidental duplicate votes from edge cases (like IP changes without clearing storage).
• Cons: Slightly more complex to implement, and still won’t stop determined users (who can switch IPs and clear storage). For your low-security use case, this is overkill.
• Verdict: Only use this if you want slightly stricter vote integrity, but it’s not necessary for most scenarios matching your requirements.

Final Recommendation #

Go with localStorage (or a simple cookie) as your core solution:

1. Frontend check: When the page loads, check if localStorage has a flag for the current item (e.g., voted_post_456). If it exists, disable the upvote/downvote buttons.
2. Backend guard: When a vote is submitted, verify that either the cookie exists (if using cookies) or log a lightweight, non-identifiable record (like a hash of the IP + user agent) to block direct API calls that bypass the frontend.
3. Privacy note: Never store any personal or identifiable data—just a simple "has voted" flag tied to the specific item. This stays true to your "no user tracking" requirement.

内容的提问来源于stack exchange，提问作者Hongli