[PHP] Tijd tussen actie controleren met time or microtime

[Verwijderd]

Ik wil tegen het ongewenst submitten van ingelogde users een timedelay instellen van een 180 seconden.

Nu ben ik gaan zoeken met google, php.net en natuurlijk hier wat men zoal gebruikt, ik ben namelijk bang voor een performance hit wanneer dit veel en vaak zou gebeuren of iemand maar op die submit button blijft rammen.

Zou een timestamp zetten gewoon probleemloos moeten werken met een volgend stukje code als de volgende (ongeveer):

PHP:

$wait = time() - $tijduittabel;

if($wait > 180) {

echo "Submit jij maar lekker hoor" ;

} else {

echo "ja probeer je de server plat te leggen ofzo ? wacht jij nog maar even $wait seconden";

}

Als ik er overna denk lijkt het me niet zo'n probleem, maar toch... berekeningen kunnen je killen.

[disjfa]

sleep ?

[ Voor 69% gewijzigd door disjfa op 19-09-2007 01:46 ]

[Verwijderd]

disjfa schreef op woensdag 19 september 2007 @ 01:45:
sleep ?

Ik wilde eigenlijk nog even doorgaan, tja eigenlijk bedtijd ja

Vast iets om naar te kijken, jij zou dus geen timestampcheck doen ? Ik vraag me overigens af hoe die fora dat doen.

Ik ben denk ik trouwens onduidelijk geweest, ik bedoel dat je bijvoorbeeld 180 seconde niet mag posten.

Dus je maakt per user een time-regel aan in de tijd-kolom.

[ Voor 21% gewijzigd door Verwijderd op 19-09-2007 01:49 ]

[Gomez12]

Wat probeer je te voorkomen??? Dubbelposts of het fipo gedrag of simpelweg spammen???

Want 180 seconden vind ik best wel lang om dan pas een reactie te kunnen plaatsen. Helemaal als ik gewoon kijk dat ik zo af en toe eerst iets lees, dan doorklik naar een andere site / google voor verdere info. Daarna kom ik weer op de 1e page terug en plaats ik direct een reactie, want de tekst heb ik in 1e instantie al gelezen...

Voor dubbelposts zou ik een combinatie van tijd vorige reactie en sametext protocol gebruiken. Dus als het 100% dezelfde tekst is dan mag deze de 1e minuten niet meer gepost worden door dezelfde user, 50% dezelfde tekst mag alleen niet in dezelfde minuut gepost worden etc etc.
Voor fipo reacties kan je dit gebruiken om de 1e reactie te stoppen, maar dan alsnog kortere tijd.
En voor spam heb je helemaal andere manieren...

Maar als je dit toch wilt blijven houden zou ik de tijd korter maken, en vergeet niet om als de tijd nog niet verstreken is de gebruiker wel een makkelijke mogelijkheid te bieden om het opnieuw te posten ( vb. vooringevulde textbox met daaronder een knop verstuur ) zodat een gebruiker niet al zijn tekst kwijt is als de tijd nog niet verstreken is.

En btw je methode lijkt wel goed, maar als je bang bent dat de server platgaat waarom dan een $tijduittabel gebruiken ( ik neem tenminste aan dat dit een query oplevert naar de sql-server ) ipv een simpele post-waarde ( makkelijk te omzeilen, maar je voorkomt wel dat de gewone gebruiker dit overkomt )

En wat veroorzaakt precies de performance hit waar je zo bang van lijkt??? het inserten van 1 bericht in mysql...

gewoon uberhaupt 180sec niet meer kunnen posten lijkt me ongewenst. Kijk dan eens naar een same-text script wat gewoon zegt dat iemand niet binnen 180 sec eenzelfde bericht ( 50% overkomst ) mag posten en tegelijkertijd dat iemand niet binnen 180sec een bericht mag posten wat korter is dan 10 tekens ( de fipo reacties / slowchat dingen etc. )

[ Voor 9% gewijzigd door Gomez12 op 19-09-2007 02:08 ]

[Verwijderd]

Veel fora lossen dit op door gewoon aan de database te vragen hoeveel posts de gebruiker gemaakt heeft bijvoorbeeld in de laatste 5 minuten. Dan check je dat even met een limiet (bijvoorbeeld 5 posts in 5 min of 10 posts in 5 min, wat je zelf wil en dan beetje afhankelijk van je forum), zit je daar overheen dan zeg je tegen de gebruiker dat ie even moet wachten.

Natuurlijk kun je de limieten (zowel tijd als hoeveelheid) zelf bepalen om zo spamgedrag te beperken.

Het opvragen van het aantal posts voor een gebruiker in een korte tijdspanne (zeer recent) kost je amper performance.

[Verwijderd]

Het gaat er mijn geval om dat ik een proces wil starten, en de functie ook voor meerdere doeleinden kan gebruiken in een later stadium... latere scripts dus... kennisvergaring

180 seconden is niet zo lang voor een proces, je zou een server echt helemaal gek kunnen maken namelijk iedere 60 seconde een service te starten welke een redelijke tijd 100% staat te starten.

[Verwijderd]

Dan nog, iedere keer als iemand iets moet doen hou je daar gewoon een entry voor bij in een tabel, als ie maar 1 iets mag doen in 180 sec vraag je de database hoeveel entries dat ie heeft voor die gebruiker in de laatste 180 sec, is dat hoger als het limiet dan laat je de gebruiker wachten, anders mag ie door en maak je dus een nieuwe entry.

Oude entries (als je die niet verder gebruikt) kun je direct weggooien, of als dat teveel load geeft om de zoveel tijd even weggooien (1x per dag, 1x per uur, wat je wil). Je kunt de entries ook voor het weggooien gebruiken om statistieken uit te genereren, handig dus.

[FragFrog]

Verwijderd schreef op woensdag 19 september 2007 @ 02:09:

180 seconden is niet zo lang voor een proces, je zou een server echt helemaal gek kunnen maken namelijk iedere 60 seconde een service te starten welke een redelijke tijd 100% staat te starten.

win32_query_service_status() dan niet iets voor jou? Gok dat er ook wel een linux variant op is; simpelweg voor je een service start controleren of'ie niet al draait lijkt me handiger dan voorkomen dat'ie te snel achter elkaar opgestart wordt

[Verwijderd]

Je zou indien je de timestamp methode zou willen gaan gebruiken, gewoon een $_Session['last_post'] kunnen uitlezen, deze set je uiteraard weer met de nieuwe zodra de post is verwerkt. Maar voor gebruikersvriendelijkheid zou ik toch een aantal opties van eerdere reacties overwegen... vooral die post compare lijkt me een erg interessante!

[Verwijderd]

Ligt het nou aan mij of doen jullie nogal moeilijk? Je kan toch gewoon wanneer iemand iets submit de huidige timestamp in een sessievariabele stoppen en wanneer iemand weer wil submitten even naar die sessievariable kijken? Daar hoef je de database helemaal niet voor te raadplegen.

/edit Bo-oz was me net voor

[ Voor 5% gewijzigd door Verwijderd op 19-09-2007 10:53 ]

[Verwijderd]

En dan maakt de gebruiker een nieuwe sessie aan?

[Verwijderd]

Verwijderd schreef op woensdag 19 september 2007 @ 11:06:
En dan maakt de gebruiker een nieuwe sessie aan?

sessie in de DB zetten en met een simpele check kun je dan zien of het IP&username combo al een sessie heeft. Zoja, sessie kopieeren en daarmee verder gaan.

[Verwijderd]

Verwijderd schreef op woensdag 19 september 2007 @ 11:10:
[...]


sessie in de DB zetten en met een simpele check kun je dan zien of het IP&username combo al een sessie heeft. Zoja, sessie kopieeren en daarmee verder gaan.

Lijkt me omslachtig als je ook gewoon een query voor een timestamp zou kunnen doen voor 1 en dezelfde user.

IP is te variabel hiervoor.

[Verwijderd]

Ik denk toch dat een timestamp ga zetten en een simpele rekensom maak.

Dan maar een query iederee keer dat iemand op start drukt.. moet toch wat database-info opgehaald worden.

[Erik Jan]

Dit is typisch het soort gegevens dat alleen maar in je RAM hoeven te staan. Bij een reset maakt het echt niet uit dat je de last-submit tijden kwijt bent. Denk bijvoorbeeld aan een TYPE=HEAP tabelletje in MySQL, waar je alleen maar de fixed-length velden UserID en LastPostDate in hoeft bij te houden. Meer dan een paar kilobyte RAM zal het niet innemen, bovendien kan je dit limiteren. Daarnaast is het retesnel, misschien dat PHP hier zelfs nog snellere oplossingen voor heeft, zonder de hele SQL-laag.

[Verwijderd]

Maar als ik dan toch een query moet doen zodra die user op submit druk maakt het eigenlijk toch weinig uit ?