La possibilità di votare senza l'accesso è sempre una cattiva idea?

Ovviamente non è sempre una cattiva idea. È sempre un compromesso tra lo sforzo speso su una cosa e lo sforzo speso su un'altra e tra lo sforzo e il guadagno. Avete ovviamente pensato a questo e pensate che nel vostro caso lo sforzo dei controlli di programmazione non è giustificato dal valore aggiunto. Va bene.

Un problema si presenterà quando andrete a vivere con questa soluzione partendo dal presupposto che il ballottaggio non è un problema e non comunicare questa ipotesi agli utenti . Alla fine, la tua app sarà usata da persone che non condividono questa ipotesi e si sentono tradite quando il sistema si comporta in modo diverso da come si presuppone un voto dovrebbe comportarsi correttamente. Questo può essere un terribile shock per le persone e perderà gli utenti a riguardo. Quindi la prospettiva più appropriata è la seguente: "La programmazione anti-cheating verifica uno sforzo maggiore rispetto all'aggiunta di una lingua al progetto che informa gli utenti della loro assenza?" La risposta potrebbe essere ancora "sì", ma puoi decidere che meglio di noi.

se non autorizzi l'utente, non puoi garantire che non voterà cento volte .. solo per il divertimento della manipolazione ... o altri motivi. Alcune persone scrivono anche piccoli script di voto. Potrebbe "battere" il tuo contatore dei voti solo per il gusto di farlo.

Puoi salvare l'indirizzo IP per i voti e non lasciare che votino per 10 minuti, MA ci sono intere società / scuole ... dietro un indirizzo IP unico. Finisci per bloccarli nel loro complesso.

Quello che potresti fare è presentare un ID criptato con il voto. La crittografia nella tua app deve creare un ID univoco per il tuo utente che dovresti verificare nello script di votazione sul tuo server.

Un modo per farlo è un md5 ('someuniqueuseridstuff' + $ yoursecretpassintheapp) e trasmettere l'md5 con l'userid semplice ('someuniqueuseridstuff') in modo da poter verificare l'uniqueid sul server. È di gran lunga non inviolabile (usa un looong $ yoursecretpassintheapp) ma sfida un certo livello di tempra.

Modifica: hai una memoria locale del cliente? potresti distribuire id e salvarli nell'archivio locale del client ...

Se viene implementato solo per un'app mobile nativa, è possibile limitare il recupero di una sorta di ID dispositivo univoco, a seconda di ciò che è disponibile nell'API della piattaforma. Se nessuna cosa è disponibile, è possibile generare un GUID al primo avvio dopo l'installazione e memorizzarlo sul dispositivo.