[PHP/JS] Opvragen van user zijn datum ivm cookies in php

[Verwijderd]

Hoi,

Een tijd geleden had ik bij toeval ontdekt dat als een gebruiker zijn lokale tijd/datum aanpast, dit ook van invloed heeft dat als je bvb een cookie wilt zetten van uur, deze cookie een uur geldig is op basis van de gebruiker zijn tijd / datum.

Dus als ik mijn datum van pc bvb zet op 21 mei 2006 en ik kom op een website die een cookie voor een dag plaatst, dan is deze cookie bij mij een jaar geldig.

Om nu even concreet te zijn, om bepaalde leden van onze website te bannen gebruik ik een ban systeem op basis van cookies (IP bans is te simpel te omzeilen, dit ook maar veel minder voor de hand liggend voor noobs). Dit heeft als gevolg dat wanneer ik bvb iemand wil bannen voor 2 dagen, ik een cookie plaats die voor 2 dagen geldig is op de gebruiker zijn PC (op basis van onze server tijd). Echter als een lid zijn klok heeft verkeerd staan, bvb een jaar achter en de cookie wordt geplaatst door de functie time()+172800 dan is het lid voor een jaar + 2 dagen gebanned is.

Wat ik dus zou willen maken is een systeem waarbij ik de gebruiker zijn lokale tijd opvraag en controleer op een afwijking met onze server tijd. Het liefst volledig in php omdat ik client-side code zoveel mogelijk probeer te vermijden.

[krvabo]

PHP lukt je sowieso niet aangezien dit serverside is (wordt op de server uitgevoerd)
Voor het zetten van de cookie kun je dan beter JS gebruiken ipv PHP. Als je dat niet wil doen heb je: http://www.w3schools.com/js/js_obj_date.asp voor referentie over hoe je met JS de datum kunt opvragen

[BoomSmurf]

Data die doorgegeven worden middels headers (cookies, last-modified, etc) zijn toch gewoon relatief aan de door de server meegeleverde date header?

edit:

Bij een goede client (browser dus) zou dan als de datum terug gezet wordt de cookie nog steeds actief zijn alleen bij vooruit niet meer.

Zowiezo vind ik het een beetje rare manier van bannen... bannen met cookies? Als op IP bannen al te makkelijk te omzeilen is voor je users, dan schat ik de 'clear cache' optie nog veel sneller gevonden is

[ Voor 55% gewijzigd door BoomSmurf op 21-05-2007 04:05 ]

[iH8]

waarom bij een ban uberhaupt rekening houden met de clienttime? je kaart notabene zelf de problemen met clienttime al aan.

[Voutloos]

BoomSmurf schreef op maandag 21 mei 2007 @ 03:57:
Data die doorgegeven worden middels headers (cookies, last-modified, etc) zijn toch gewoon relatief aan de door de server meegeleverde date header?

Nee, en bij cookies is het duidelijk gespcificeerd als zijnde een timestamp (absoluut aantal seconden sinds de Unix epoch).

Het hele idee om cookies hiervoor te gebruiken is inherent fout. Op zich nog typisch dat de TS de minder erge fout aanhaalt in de startpost. Dat iemand met een klok welke voorloopt eerder unbanned is is imo erg dan dat een stoute user te lang gebanned is.

Verwijderd schreef op maandag 21 mei 2007 @ 03:02:
Om nu even concreet te zijn, om bepaalde leden van onze website te bannen gebruik ik een ban systeem op basis van cookies

Leden? Dan is er neem ik aan een db met user gegevens? Simpel, een kolom toevoegen met de timestamp dat user unbanned moet worden en klaar ben je.

(IP bans is te simpel te omzeilen, dit ook maar veel minder voor de hand liggend voor noobs).

Serverside IP-ban is voor noobs moeilijker te omzeilen dan cookies. Maar zoals gezegd zijn beide systemen niet goed genoeg.

Het liefst volledig in php omdat ik client-side code zoveel mogelijk probeer te vermijden.

Cookies zijn client-side dus voldoen niet aan je eigen requirement.

[BikkelZ]

Waarschijnlijk wil je ook niet dat een geband lid meteen een nieuwe username regt, vandaar de IP + cookie ban. Maar je schrijft in die cookie simpelweg jouw tijd van bannen, en als je die cookie tegen komt met een tijd die bij jou verlopen is, dan verwijder je die cookie.

En dan kun je die cookie wel voor een jaar zetten, ongeacht of je hem nou voor een dag of een half jaar bant, het gaat om de tijd die jij IN die cookie gezet hebt, en dat is dan altijd JOUW tijd.

[Voutloos]

BikkelZ schreef op maandag 21 mei 2007 @ 10:47:
En dan kun je die cookie wel voor een jaar zetten, ongeacht of je hem nou voor een dag of een half jaar bant, het gaat om de tijd die jij IN die cookie gezet hebt, en dat is dan altijd JOUW tijd.

Dan is dat cookie alsnog snel weg als user zijn klokje een jaar vooruit loopt.

[Verwijderd]

Je kan het natuurlijk wel doen zoals Bikkelz zegt, je gebruikt dan een cookie om inderdaad een start timestamp te zetten, in een database hou je de duur van de ban bij. Indien je vergelijkt en de duur is verlopen, haal je de cookie weg. Indien je cookie weg is (dus de gebruiker heeft ermee gerommeld) gaat de ban opnieuw in door de huidige timestamp te zetten. Uiteraard laat je de cookie gedurende onbeperkte tijd "leven". Het enige probleem is echter, hoe weet je dat een cookie had moeten staan voor een gebruiker als je geen ip-check doet en hoe zorg je ervoor dat de gebruiker niet handmatig de cookie gaat aanpassen (je zou natuurlijk een timestamp_id kunne gebruiken met een database tabel met de bantimestamps)

Al met al een hoop moeite voor deze functionaliteit, ik denk toch dat de ip-ban de meest werkbare is ondanks z'n nadelen.

[GlowMouse]

krvabo schreef op maandag 21 mei 2007 @ 03:30:
PHP lukt je sowieso niet aangezien dit serverside is (wordt op de server uitgevoerd)
Voor het zetten van de cookie kun je dan beter JS gebruiken ipv PHP. Als je dat niet wil doen heb je: http://www.w3schools.com/js/js_obj_date.asp voor referentie over hoe je met JS de datum kunt opvragen

JavaScript is inderdaad de enige oplossing. Hier staat zelfs een complete functie om cookies te plaatsen.

[Verwijderd]

Verwijderd schreef op maandag 21 mei 2007 @ 12:09:
Je kan het natuurlijk wel doen zoals Bikkelz zegt, je gebruikt dan een cookie om inderdaad een start timestamp te zetten, in een database hou je de duur van de ban bij. Indien je vergelijkt en de duur is verlopen, haal je de cookie weg. Indien je cookie weg is (dus de gebruiker heeft ermee gerommeld) gaat de ban opnieuw in door de huidige timestamp te zetten. Uiteraard laat je de cookie gedurende onbeperkte tijd "leven". Het enige probleem is echter, hoe weet je dat een cookie had moeten staan voor een gebruiker als je geen ip-check doet en hoe zorg je ervoor dat de gebruiker niet handmatig de cookie gaat aanpassen (je zou natuurlijk een timestamp_id kunne gebruiken met een database tabel met de bantimestamps)

Al met al een hoop moeite voor deze functionaliteit, ik denk toch dat de ip-ban de meest werkbare is ondanks z'n nadelen.

dit zou je dan beter compleet zonder cookies kunnen oplossen. Je slaat in de database de tijd op van wanneer de user weer mag inloggen. Als de user probeert in te loggen kijk je naar de system date (die van de server dus) en vergelijk die met de datum in de database. zo heb je geen cookies meer nodig, en is het probleem van verschillende tijds instellingen ook opgevangen.

[Verwijderd]

Verwijderd schreef op maandag 21 mei 2007 @ 13:21:
[...]


dit zou je dan beter compleet zonder cookies kunnen oplossen. Je slaat in de database de tijd op van wanneer de user weer mag inloggen. Als de user probeert in te loggen kijk je naar de system date (die van de server dus) en vergelijk die met de datum in de database. zo heb je geen cookies meer nodig, en is het probleem van verschillende tijds instellingen ook opgevangen.

Dan voorkom je niet dat ze een andere account aanmaken. De cookie is vooral bedoeld dat ze geen andere account aanmaken, de ban zelf staat naast de cookie ook in de database opgeslagen, dus de account is zoiezo onbruikbaar.

Maar allesinds bedankt voor de reactie's en concepten, er zitten een aantal zaken tussen waar ik nog niet aan gedacht had zoals het idee van BikkelZ

[BtM909]

Verwijderd schreef op dinsdag 22 mei 2007 @ 14:07:
[...]


Dan voorkom je niet dat ze een andere account aanmaken. De cookie is vooral bedoeld dat ze geen andere account aanmaken, de ban zelf staat naast de cookie ook in de database opgeslagen, dus de account is zoiezo onbruikbaar.

Daar heb je dan wel weer het IP adres voor

[Verwijderd]

dan is het nut van dat hele cookie dus om te zorgen dat ze niet nog een account aanmaken, omdat je aangeeft dat die tijd al in de database staat (zoals ik voorstelde). Dan kun je net zo goed een cookie setten met de gebande username. Stel de gebruiker komt opnieuw op de website dan kijk je of de username ondertussen al weer toegang heeft en verwijder je de cookie (dmv de timer op 0 te zetten). In combinatie met een IP ban is nog mooier natuurlijk.

[_Sunnyboy_]

Nog wat ideeën:

1. Zorg dat de user bij het aanmaken een mail adres moet opgeven waar een mail heen wordt gestuurd om de account te activeren
2. Zorg dat voor dit mail adres de domeinen waar gratis onbeperkt mailaddressen voor gemaakt kunnen worden (hoail, yahoo, gmail, etc) niet toegestaan zijn
3. Als je een user bant, ban je ook zijn mail adres, zodat hij dat niet kan gebruiken om een nieuwe user te maken

Natuurlijk is ook bovenstaand niet waterdicht. Iemand met een eigen domeinnaam kan meestal onbeperkt mail adressen voor dat domein aanmaken, maar het is weer een extra hindernis, net als de ip ban en de cookie ban.

[ERIKvanPAASSEN]

BoomSmurf schreef op maandag 21 mei 2007 @ 03:57:
Zowiezo vind ik het een beetje rare manier van bannen... bannen met cookies? Als op IP bannen al te makkelijk te omzeilen is voor je users, dan schat ik de 'clear cache' optie nog veel sneller gevonden is

Tenzij je natuurlijk, zoals als ik hier, in een regio zit waar ruim 90% van de internetters is aangesloten op de lokale kabelboer met Dynamic IP's... Om de week (of vaker) een nieuw IP. En lang niet iedereen weet hoe hij zijn cookies delete, of überhaupt dat het bannen geschiedt via cookies.

[Marcks]

_Sunnyboy_ schreef op dinsdag 22 mei 2007 @ 19:26:
Nog wat ideeën:

1. Zorg dat de user bij het aanmaken een mail adres moet opgeven waar een mail heen wordt gestuurd om de account te activeren
2. Zorg dat voor dit mail adres de domeinen waar gratis onbeperkt mailaddressen voor gemaakt kunnen worden (hoail, yahoo, gmail, etc) niet toegestaan zijn
3. Als je een user bant, ban je ook zijn mail adres, zodat hij dat niet kan gebruiken om een nieuwe user te maken

Daar heb ik dus wel een ongelooflijke hekel aan. Een site die ik niet ken, wil ik nog wel opzadelen met een gratis mailadres (zoals gmail), maar als ik links en rechts mijn 'echte' e-mail zou gebruiken, dan zou dat een ongewenst effect hebben op mijn hoeveelheid spam. Bovendien zijn er nogal wat mensen wiens gratis inbox hun enige mailadres is. Goede zaak, al deze potentiele members afschrikken.

[roy-t]

Marcks schreef op dinsdag 22 mei 2007 @ 21:06:
[...]


Daar heb ik dus wel een ongelooflijke hekel aan. Een site die ik niet ken, wil ik nog wel opzadelen met een gratis mailadres (zoals gmail), maar als ik links en rechts mijn 'echte' e-mail zou gebruiken, dan zou dat een ongewenst effect hebben op mijn hoeveelheid spam. Bovendien zijn er nogal wat mensen wiens gratis inbox hun enige mailadres is. Goede zaak, al deze potentiele members afschrikken.

Inderdaad ik woon nu nog thuis, maar ook op kamers heb je vaak geen eigen email maar gewoon je hot of g mailtje, ik heb me aangemeld op GoT met mijn moeders e-mail adres en laatst kreeg ik met dat vrijwillige moderator gebeuren daar een e-mail op, mijn moeder checked het 1x per week en dus was mijn modstatus al ingetrokken (voor vreemde redenen, na uitleg bleek het vooral een verschil van humor en wat te strak optreden tegen standaard rants, maargoed dit word wel oft nu)

[Verwijderd]

Wat betreft hotmail / gmail toelaten ga ik niet aan beginnen ;-) onze doelgroep is jeugd 12-21 en 95% heeft een msn / hotmail adres. Bannen op IP heeft ook weinig zin, in belgië hebben bijna alle ADSL gebruikers een dynamisch IP. Waarom ik geen bans op IP doe heeft te maken dat de meenste jeugd de truuk van chatboxen wel kent "modem uittrekken, terug connecten en voila ik zit er terug op ..." wat betreft cookies, daar hebben ze echt geen verstand van. Vroeger hadden we IP bans en sinds we met cookies werken hebben we op 100 bans misschien maar 1 slimmeling die snapt dat hij zijn cookies moet verwijderen om zo een nieuwe account aan te maken. Wat betreft account-activatie, we hebben er al vaak aan gedacht maar door problematiek met hotmail dat mails vaak niet aankomen doen we dat toch niet (jawel, we hebben SPF records etc en na herhaaldelijk contacten met microsoft zelf kunnen ze ook niets anders antwoorden dan "sorry, u neemt best contact op met microsoft in de states blablabla"

[BtM909]

misschien maar 1 slimmeling die snapt dat hij zijn cookies moet verwijderen om zo een nieuwe account aan te maken.

En die ene slimmeling die het vervolgens verspreidt

[SchizoDuckie]

wat zou het toch mooi zijn als het mac adres van de originator te achterhalen was buiten een local lan om. Maar dat is helaas voor jou niet hoe het werkt, dus je kan op z'n hoogst telkens blijven ip bannen. Bannen met cookies stelt idd zoals de meesten hier zeggen helemaal niets voor, en zelfs al zou je een vast ip adres hebben dan zijn er nog altijd nog browsers als Torpark, dus helaas blijft telkens users bannen je enige optie

[IEF]

SchizoDuckie schreef op donderdag 24 mei 2007 @ 01:07:
wat zou het toch mooi zijn als het mac adres van de originator te achterhalen was buiten een local lan om. Maar dat is helaas voor jou niet hoe het werkt, dus je kan op z'n hoogst telkens blijven ip bannen. Bannen met cookies stelt idd zoals de meesten hier zeggen helemaal niets voor, en zelfs al zou je een vast ip adres hebben dan zijn er nog altijd nog browsers als Torpark, dus helaas blijft telkens users bannen je enige optie

zodat het mac adres gespoofed kan woorden?

Dit soort problematiek geeft extra aan dat er een behoefte is aan een 'unieke' identifier voor een user op internet, anders dan IP/MAC.

[BikkelZ]

IEFtm schreef op donderdag 24 mei 2007 @ 01:15:
[...]


zodat het mac adres gespoofed kan woorden?

Dit soort problematiek geeft extra aan dat er een behoefte is aan een 'unieke' identifier voor een user op internet, anders dan IP/MAC.

Eigenlijk zou iNtel gewoon een uniek nummer in hun chips moeten stoppen.

Oh wacht.....