Like systeem

[_Moe_]

Een van de dagen dien ik een Like systeem op te zetten voor niet geregistreerde gebruikers en dacht dit als volgt te doen:
- record toevoegen in de database waarin ik het ip en het tijdstip opsla (gekoppeld met desbetreffende artikel)
- cookie zetten waarin ik het artikel id zet

Van zodra er op like geklikt wordt, doe ik controle of het id voorkomt desbetreffende cookie en indien dit niet het geval is, ga ik na of desbetreffend ip de afgelopen x minuten nog op de like button gedrukt heeft.

Volstaat dit?

[Barryvdh]

Ligt aan de eisen die je stelt aan je Like systeem he

[_Moe_]

Barryvdh schreef op donderdag 15 mei 2014 @ 09:19:
Ligt aan de eisen die je stelt aan je Like systeem he

Zoals dat bij de meeste systemen is zeker, voorkomen dat je zomaar duizenden likes kan pushen.

[ErikKo]

Ik zou hier geen cookie voor gebruiken. Cookies worden client-side opgeslagen en dus te bewerken door kwaadwillenden. Ik zou het houden op een <ip, timestamp> tupel. Ieder ip kan een artikel maar 1 keer liken.

[_Moe_]

ErikKo schreef op donderdag 15 mei 2014 @ 11:01:
Ik zou hier geen cookie voor gebruiken. Cookies worden client-side opgeslagen en dus te bewerken door kwaadwillenden. Ik zou het houden op een <ip, timestamp> tupel. Ieder ip kan een artikel maar 1 keer liken.

En wat als er dan meerdere likes zouden zijn vanuit één gebouw (school)

[Verwijderd]

Dat is wel een afweging die je moet maken denk ik. Of je een waterdicht maar strict like systeem wil fabriceren of een open maar niet heel erg waterdicht systeem.
Beetje het probleem van gebruikers zonder enige identificatiefactor input geven op een site.

[ Voor 22% gewijzigd door Verwijderd op 15-05-2014 11:25 ]

[_Moe_]

Verwijderd schreef op donderdag 15 mei 2014 @ 11:23:
Dat is wel een afweging die je moet maken denk ik. Of je een waterdicht maar strict like systeem wil fabriceren of een open maar niet heel erg waterdicht systeem.
Beetje het probleem van gebruikers zonder enige identificatiefactor input geven op een site.

En strict wil dan zeggen dat je enkel op basis van een ip adres gaat bepalen of het er nog geliked mag worden. Ok, het is het meest dicht, maar niet echt mooi als je het mij vraagt.

[ocwil]

Hoe groot acht je de kans dat het misbruikt wordt?
anders kun je eventueel anti-botting toevoegen in de vorm van een simpele captcha of een extra indentifier("naam").

[kamerplant]

ocwil schreef op donderdag 15 mei 2014 @ 12:21:
Hoe groot acht je de kans dat het misbruikt wordt?
anders kun je eventueel anti-botting toevoegen in de vorm van een simpele captcha of een extra indentifier("naam").

Dan weet je zeker dat niemand gaat liken .

Alles hangt van je requirements af. Misschien is het wel verstandig om in te loggen met DigID voordat je een like kunt plaatsen . Als je het gewoon simpel wilt houden met minimale ergernissen, dan zou ik het houden bij een cookie zoals je al van plan was. Een IP registratie is niet toekomst proof (ivm ipv6) en levert irritatie op voor mobiele en zakelijke gebruikers.

[FotW]

Je zou dan naast de cookie ook nog een waarde in de local storage kunnen zetten

[xzaz]

Een combinatie van cookie en IP dus.

[Feanathiel]

_Moe_ schreef op donderdag 15 mei 2014 @ 09:28:
[...]
Zoals dat bij de meeste systemen is zeker, voorkomen dat je zomaar duizenden likes kan pushen.

ErikKo schreef op donderdag 15 mei 2014 @ 11:01:
Ik zou hier geen cookie voor gebruiken. Cookies worden client-side opgeslagen en dus te bewerken door kwaadwillenden. Ik zou het houden op een <ip, timestamp> tupel. Ieder ip kan een artikel maar 1 keer liken.

Totdat je ISP ineens een IPv6 range (/64) uitdeelt. Dan beschik je over een heel wat aantal likes.

[hommer]

_Moe_ schreef op donderdag 15 mei 2014 @ 11:16:
[...]
En wat als er dan meerdere likes zouden zijn vanuit één gebouw (school)

Ik weet niet weke taal je in programmeert, maar ik weet dat PHP bij requests via een proxy server in de $_SERVER variabele dan een HTTP_X_FORWARDED_FOR element heeft met het IP van de originele client in het LAN. Het staat dan namelijk in de HTTP header.
Je kunt daar niet van uitgaan, maar, indien beschikbaar, kun je hem natuurlijk wel gebruiken.

[Gomez12]

hommer schreef op donderdag 15 mei 2014 @ 22:33:
[...]
Ik weet niet weke taal je in programmeert, maar ik weet dat PHP bij requests via een proxy server in de $_SERVER variabele dan een HTTP_X_FORWARDED_FOR element heeft met het IP van de originele client in het LAN. Het staat dan namelijk in de HTTP header.
Je kunt daar niet van uitgaan, maar, indien beschikbaar, kun je hem natuurlijk wel gebruiken.

Je bedoelt zo'n header die je binnen 2 sec gefabriceerd hebt als je het systeem wilt misbruiken.

In wezen moet je je in 1e instantie afvragen : Waartegen moet het bestand zijn?

Want bijv geenstijl had een paar jaar terug een voting-systeem van (ik meen doritos) overhoop gegooid door simpelweg een posting te maken waarin ze iedereen opriepen om te stemmen op hun chips-naam, dat valt wellicht wel weer met een referer check te ontdekken, maar dan moet je weer oppassen dat je niet alle referers blokkeert.. Het is gewoon een afweging, VF hanteert bijv een proxy dus de meeste mobiele klanten komen maar van 1 of 2 ip-adressen en dan zeg je eigenlijk (met een ip-check) dat er maar x mobiele likes per tijdseenheid gegeven mogen worden, wil je dat?

[_Moe_]

Verder lijkt het me ook niet zo slim om dit enkel op basis van een ip adres te doen, omdat je hier ook wel eens met dynamische ip-adressen zit.

Momenteel blijf ik nog bij mijn eerste idee. Totdat iemand me weet te overtuigen

[Russel88]

_Moe_ schreef op donderdag 15 mei 2014 @ 09:16:
Een van de dagen dien ik een Like systeem op te zetten voor niet geregistreerde gebruikers en dacht dit als volgt te doen:
- record toevoegen in de database waarin ik het ip en het tijdstip opsla (gekoppeld met desbetreffende artikel)
- cookie zetten waarin ik het artikel id zet

Van zodra er op like geklikt wordt, doe ik controle of het id voorkomt desbetreffende cookie en indien dit niet het geval is, ga ik na of desbetreffend ip de afgelopen x minuten nog op de like button gedrukt heeft.

Volstaat dit?

Twee klasgenootjes die naast elkaar zitten op elk hun eigen pc mogen dus niet binnen een minuut liken?

[FotW]

Daarom mijn suggestie om een cookie en local storage te zetten, het eerste wat iemand die het systeem wil misbruiken zal proberen is z'n cookies weggooien. En als ik mij niet vergis wordt bij die actie niet automatisch de local storage geleegd.

[vistu]

Browserfingerprinting een optie? Zie bv https://panopticlick.eff.org/index.php?action=log&js=yes

[DXaroth]

FotW schreef op vrijdag 16 mei 2014 @ 10:31:
Daarom mijn suggestie om een cookie en local storage te zetten, het eerste wat iemand die het systeem wil misbruiken zal proberen is z'n cookies weggooien. En als ik mij niet vergis wordt bij die actie niet automatisch de local storage geleegd.

Altijd vertrouwen op regel 1 van webapps programmeren:

Never trust user input.

Zodra je zooi in hun local storage gaat zetten, is het niet jouw input, maar hun, dus is het niet te vertrouwen (Overigens zullen er vast genoeg manieren zijn om local storage aan te passen)... zelfde geld voor headers btw...

Authenticatie geen optie (als in, mensen die willen liken hebben een account nodig)?

[Russel88]

DXaroth schreef op vrijdag 16 mei 2014 @ 10:46:
[...]


Altijd vertrouwen op regel 1 van webapps programmeren:

Never trust user input.

Zodra je zooi in hun local storage gaat zetten, is het niet jouw input, maar hun, dus is het niet te vertrouwen (Overigens zullen er vast genoeg manieren zijn om local storage aan te passen)... zelfde geld voor headers btw...

Authenticatie geen optie (als in, mensen die willen liken hebben een account nodig)?

Volgens mij is regel 1 van een ontwikkelaar toch echt de requirements van de klant te lezen:

Een van de dagen dien ik een Like systeem op te zetten voor niet geregistreerde gebruikers en dacht dit als volgt te doen:

Als je met geregistreerde gebruikers werkt heb je ip en cookie meuk helemaal niet nodig en was deze topic zinloos geweest.

[FotW]

DXaroth schreef op vrijdag 16 mei 2014 @ 10:46:
[...]


Altijd vertrouwen op regel 1 van webapps programmeren:

Never trust user input.

Zodra je zooi in hun local storage gaat zetten, is het niet jouw input, maar hun, dus is het niet te vertrouwen (Overigens zullen er vast genoeg manieren zijn om local storage aan te passen)... zelfde geld voor headers btw...

Authenticatie geen optie (als in, mensen die willen liken hebben een account nodig)?

Wat Russel88 al zegt, volgens mij heb je de TS niet gelezen want authenticatie is geen optie en dus moet je wel op user input "vertrouwen".

[RayNbow]

DXaroth schreef op vrijdag 16 mei 2014 @ 10:46:
[...]


Altijd vertrouwen op regel 1 van webapps programmeren:

Never trust user input.

Zodra je zooi in hun local storage gaat zetten, is het niet jouw input, maar hun, dus is het niet te vertrouwen [...]

Maar je kunt wel data die je in een cookie/local storage/whatever propt wel voorzien van een signature, zodat het niet zo snel aan te passen is.

_Moe_ schreef op donderdag 15 mei 2014 @ 09:16:
Een van de dagen dien ik een Like systeem op te zetten voor niet geregistreerde gebruikers en dacht dit als volgt te doen:
- record toevoegen in de database waarin ik het ip en het tijdstip opsla (gekoppeld met desbetreffende artikel)
- cookie zetten waarin ik het artikel id zet

Van zodra er op like geklikt wordt, doe ik controle of het id voorkomt desbetreffende cookie en indien dit niet het geval is, ga ik na of desbetreffend ip de afgelopen x minuten nog op de like button gedrukt heeft.

Volstaat dit?

Wat zijn de eisen om een bepaald artikel te mogen liken? Moet de gebruiker misschien het artikel bekeken/gekeken/bezocht hebben voordat hij op like mag klikken?

Ik stel in ieder geval voor dat je o.a. alleen likes telt als er minstens, pak 'm beet, 5 seconden tussen het laden van de pagina en het liken van die pagina zit. Houd ook bij of hoe vaak een gebruiker een pagina liket. Stel bijv. een bovengrens in van x likes per minuut (op basis van een tracking cookie en/of IP).

[cannibal]

Ik zou denken om idd met behulp van Javascript de browser/client te fingerprinten en elke like tegen een hash o.i.d. van deze gegevens op te slaan.

Cookie zou je nog kunnen gebruiken om bij het opnieuw opvragen van de pagina de like optie op readonly te gooien. Mocht deze cookie verdwijnen kun je alsnog bij het opnieuw liken de hash van de fingerprint checken en de like discarden.

[DJMaze]

OpenID gebruiken?
Ze maken geen account aan, maar loggen wel in via hun gmail bijvoorbeeld.

[EricBruggema]

Ik zou gaan voor een combinatie van browser informatie (finger print) + ip. En mocht je meerdere stemmen van 1 ip adres willen ondersteunen, minimaal een tijds limiet instellen, sowieso ook tussen de verschillende artikelen. Cookies zijn leuk hoor, maar idd, kwaadwillenden kunnen er goed misbruik van maken! *)

[DXaroth]

FotW schreef op vrijdag 16 mei 2014 @ 11:47:
[...]


Wat Russel88 al zegt, volgens mij heb je de TS niet gelezen want authenticatie is geen optie en dus moet je wel op user input "vertrouwen".

Ik heb zeer zeker wel gelezen, maar authenticatie en registratie zijn 2 compleet verschillende dingen, die vaak samen gebruikt worden, maar niet samen gebruikt -hoeven- worden.

Daarnaast, voor Russel88, het feit dat een klant iets wilt, wil niet zeggen dat iets haalbaar is, dan krijg je dit soort besprekingen: YouTube: The Expert (Short Comedy Sketch)

[Ramon]

_Moe_ schreef op donderdag 15 mei 2014 @ 09:16:
Een van de dagen dien ik een Like systeem op te zetten voor niet geregistreerde gebruikers en dacht dit als volgt te doen:
- record toevoegen in de database waarin ik het ip en het tijdstip opsla (gekoppeld met desbetreffende artikel)
- cookie zetten waarin ik het artikel id zet

Van zodra er op like geklikt wordt, doe ik controle of het id voorkomt desbetreffende cookie en indien dit niet het geval is, ga ik na of desbetreffend ip de afgelopen x minuten nog op de like button gedrukt heeft.

Volstaat dit?

Je kan wel allerlei security gaan verzinnen en uren en dagen besteden aan het bouwen van fingerprinting gedoe maar wat we eerst moeten weten is: a) Wat zijn de requirements van de klant b) hoeveel uur heb je ervoor/wil je eraan besteden c) wat is de doelgroep van de site d) Hoe belangrijk zijn de likes voor werking van je site?

Het volgende is wat ik zou doen:
De like als record in de database zetten die gekoppeld is aan de sessie van de gebruiker (sessie is een soort "serverside cookie" waarvan de de gebruiker de inhoud niet kan uitlezen). Bij de record sla je dan de useragent op en het IP. Hier zou ik het bij houden! Verdergaande maatregelen zoals fingerprinting zou ik pas doen als je door krijgt dat er misbruik van wordt gemaakt.

[eM.]

Beetje onhandig, maar had hem nog niet voorbij zien komen: bij het liken e-mailadres eenmalig opgeven en cookie plaatsen. Via e-mailadres like bevestigen. Like dus aan e-mailadres koppelen.

[ Voor 20% gewijzigd door eM. op 18-05-2014 08:29 ]

[kwaakvaak_v2]

afhankelijk van de schaalgrote kun je natuurlijk ook gewoon alles opslaan wat je kunt opslaan. IP's etc, en achteraf via een los process analyse op de like's doen en dan zien of er frauduleuze patronen inzitten. Als een artikel ineens 500% meer likes heeft dan alle andere, is het of een heeeel erg populair artikel of meer aan de hand. Ondanks dat iets een webapp is, wil dat nog niet zeggen dat je alles 100% realtime in de user request hoeft te af te vangen en iets mee te doen.

[xzaz]

Wat kwaakvaak zegt is eigenlijk het beste; je kan uren en dagen in een systeem stoppen wat alleen maar obstructie geeft maar nooit echt een oplossing. Schrijf een java app die op een server draait die gewoon alles netjes voor je bijhoudt en gaat schreeuwen wanneer er gekke dingen aan de hand zijn. Zet een threshold dat bijvoorbeeld elk uur wordt berekend hoeveel likes er worden gegeven. Is het uberhaupt wel een probleem het eerste x jaar vanwege de bezoekers? enz enz.

[kwaakvaak_v2]

Precies xzaz.. Alleen. waarom zou die app in Java moeten? Dat kan in principe in elke taal die de TS wil gebruiken imho ;-)

[CH4OS]

Russel88 schreef op vrijdag 16 mei 2014 @ 11:34:
Als je met geregistreerde gebruikers werkt heb je ip en cookie meuk helemaal niet nodig en was deze topic zinloos geweest.

En geregistreerde gebruikers vertrouw jij wel?

eM. schreef op zondag 18 mei 2014 @ 08:26:
Beetje onhandig, maar had hem nog niet voorbij zien komen: bij het liken e-mailadres eenmalig opgeven en cookie plaatsen. Via e-mailadres like bevestigen. Like dus aan e-mailadres koppelen.

Is eigenlijk hetzelfde als captcha's, werpt alleen maar obstructies op, waardoor het systeem niet of nauwelijks gebruikt gaat worden.

[ Voor 43% gewijzigd door CH4OS op 19-05-2014 12:39 ]

[xzaz]

kwaakvaak_v2 schreef op maandag 19 mei 2014 @ 11:48:
Precies xzaz.. Alleen. waarom zou die app in Java moeten? Dat kan in principe in elke taal die de TS wil gebruiken imho ;-)

Oh natuurlijk. Kies de taal die het dichts bij je ligt. Ik zal overigens PHP, javascript nooit gebruiken voor applicaties die in de achtergrond draaien maar dat is een persoonlijke mening

[Martijn.C.V]

IP alleen is een flutbeveiliging.
Telefoon in 3G = 1 IP adres. Wifi aan, wifi uit -> Weer in 3G met ipadres 2. Repeat zolang je geduld hebt.
De combo met cookies kan, met een sessie erbij, misschien html5's local storage erbij. Zonder unieke, niet te vervalsen gegevens gat dit nooit 100% worden.

(los van proxies. Maar dat acht ik redelijk klein.)

[ Voor 8% gewijzigd door Martijn.C.V op 19-05-2014 14:42 ]

[_Moe_]

Het maakt eigenlijk niet zo heel veel uit dat iemand meerdere likes doet, het enige dat ik wil vermijden is dat een eindgebruiker bijvoorbeeld in 1 minuut 100+ likes kan doen.

Uiteindelijk kan je het toch niet tegenhouden, zolang er niet moet worden ingelogd.

[RayNbow]

_Moe_ schreef op maandag 19 mei 2014 @ 15:41:
het enige dat ik wil vermijden is dat een eindgebruiker bijvoorbeeld in 1 minuut 100+ likes kan doen.

Dat kan toch? Je moet het liken van een artikel koppelen aan het ophalen/lezen van het artikel. Je houdt bij wanneer de gebruiker het artikel ophaalde en wanneer het artikel een like gaf. Vervolgens kun je een analyse doen en gooi je alle likes weg die bijv. binnen 1 seconde na het ophalen van het artikel zijn uitgevoerd.

[alwinuzz]

_Moe_ schreef op maandag 19 mei 2014 @ 15:41:
Het maakt eigenlijk niet zo heel veel uit dat iemand meerdere likes doet, het enige dat ik wil vermijden is dat een eindgebruiker bijvoorbeeld in 1 minuut 100+ likes kan doen.

Uiteindelijk kan je het toch niet tegenhouden, zolang er niet moet worden ingelogd.

Anders doe je een compromis? een max van 50 likes per ip, op hetzelfde artikel. Youtube heeft bijvoorbeeld een max van een paar 100 views per IP of iig computer, op hetzelfde filmpje. gwn een extra if en dan verkom je iig het worst case scenario

[ Voor 3% gewijzigd door alwinuzz op 20-05-2014 02:16 ]