Sleep
Door Jordy nvt, 18 jaar geleden, 12.332x bekeken
Sleep funtie bij login.
Ga naar volgende pagina voor de tutorial.
Voeg aub commentaar toe wat je van deze tutorial vind.
Gesponsorde koppelingen
Inhoudsopgave
Er zijn 50 reacties op 'Sleep'
Maar wat is het nu t bij inlogsystemen er dan van?
Dan duurt de craker het allemaal wat langer,, en dan..?
Dan duurt de craker het allemaal wat langer,, en dan..?
Dan heb je misschien een 1000 keer langer nodig per poging, wat er voor zorgt dat er minder kans is op het raden van het goede wachtwoord...
Je zou dit ook kunnen gebruiken wanneer je meerdere e-mails gaat sturen maar geen blacklist wilt hebben van je provider wegens het versturen van spam. Zo kun je een maximum per uur bepalen, door de mails op te delen.
Edit: vertraging alleen IN de lus als er als is GEPOST. Anders haken bezoekers spontaan af. Na het verzenden van een formulier is één seconde meer wachten geen probleem, maar ervoor wel...
Je zou dit ook kunnen gebruiken wanneer je meerdere e-mails gaat sturen maar geen blacklist wilt hebben van je provider wegens het versturen van spam. Zo kun je een maximum per uur bepalen, door de mails op te delen.
Edit: vertraging alleen IN de lus als er als is GEPOST. Anders haken bezoekers spontaan af. Na het verzenden van een formulier is één seconde meer wachten geen probleem, maar ervoor wel...
@steen, bedankt voor de tip. Ik heb het aangepast.
@Joris, als het de cracker langer duurt is dat voordelig. Als je 10 keer probeert in te loggen is het natuurlijk niks, want dan scheelt het 10 seconden. Maar als je 10.000 keer probeert in te loggen.... Het is gewoon verplicht vanuit de veiligheid.
@Joris, als het de cracker langer duurt is dat voordelig. Als je 10 keer probeert in te loggen is het natuurlijk niks, want dan scheelt het 10 seconden. Maar als je 10.000 keer probeert in te loggen.... Het is gewoon verplicht vanuit de veiligheid.
Verplicht? Het is misschien aan te raden. Natuurlijk zijn er ook andere oplossingen zoals een limiet op het aantal aanmeldpogingen. Deze vind ik persoonlijker net iets vriendelijker dan zo'n vertraging.
Even voor de volledigheid: wanneer je korter dan een seconde je script wilt laten slapen kan je usleep gebruiken.
Ok, je weet dat zolang je PHP laat slapen het process in het geheugen blijf draaien en alles wat je in PHP hebt geladen dus ook in het gehugen blijft. Voor een simpele site is dit dus geen probleem maar een beetje site met een beetje bezoekers gebruik je dit niet. En dan nog wat, een fatsoenlijke site met fatsoenlijke code zal te veel request van één ip niet accepteren of iig er uitfilteren. Wat ik denk is dat jij gewoon dacht van dit zal wel leuk zijn in mijn login maar dit is gewoon bullshit die je server capaciteit vraagt. Dit is zo ontzettend onnodig en dom! Log in bij Google, log in bij weet ik welke site, moet je ooit een seconde wachten? Serieus, ga nog meer dingen propageren. Nu gaan n00bs die dit zien dit misschien gebruiken. Je bent gewoon langs deze functie gekomen op php.net en dacht, waarvoor kan ik deze functie gebruiken. Als je een fatsoenlijke site maakt zal je deze functie niet gebruiken tenzij in een demonstratievorm waarbij je wilt weten wat er gebeurt als een request te lang duurt.
Door ob_implicitit_flush(true) te combineren met sleep, kun je het gebruiken om tussentijden te creëren om bijv. output te laten zien.
Een klein voorbeeldje:
Een klein voorbeeldje:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<?php
ob_implicit_flush(true);
echo "<html><head><title>Test</title></head><body style='color:white; background-color:black;'>";
echo "Starting up....<br />Please wait";
sleep(2);
echo ".";
sleep(1);
echo ".";
sleep(1);
echo ".";
sleep(1);
echo "<br /><br />Starting up system...<br />";
echo "<br /> Loading system information...<br />";
sleep(2);
echo "Establishing connections...<br />";
sleep(3);
echo "Starting service's...<br />";
sleep(2);
echo "<br />System loaded, OK<br />";
sleep(1);
echo "<br />starting <b>windows</b>";
sleep(1);
echo ".";
sleep(1);
echo ".";
sleep(2);
echo ".";
sleep(1);
echo ".";
sleep(1);
echo "<br /><br /><font color='yellow'>Error (468), Keyboard not found.<br />Press F5 to continue.</font></body></html>";
?>
ob_implicit_flush(true);
echo "<html><head><title>Test</title></head><body style='color:white; background-color:black;'>";
echo "Starting up....<br />Please wait";
sleep(2);
echo ".";
sleep(1);
echo ".";
sleep(1);
echo ".";
sleep(1);
echo "<br /><br />Starting up system...<br />";
echo "<br /> Loading system information...<br />";
sleep(2);
echo "Establishing connections...<br />";
sleep(3);
echo "Starting service's...<br />";
sleep(2);
echo "<br />System loaded, OK<br />";
sleep(1);
echo "<br />starting <b>windows</b>";
sleep(1);
echo ".";
sleep(1);
echo ".";
sleep(2);
echo ".";
sleep(1);
echo ".";
sleep(1);
echo "<br /><br /><font color='yellow'>Error (468), Keyboard not found.<br />Press F5 to continue.</font></body></html>";
?>
Natuurlijk wacht een slimme brute forcer niet op het antwoord om een nieuw request aan te maken, oftewel alleen maar nadelen voor beide kanten:
server:
- meer resources, apache neemt redelijk wat werkgeheugen in om 1 request af te handelen
- als er gebruteforced wordt doen ze dit met 100+ request tegelijk waarbij al deze requests 1 seconden in het geheugen niks aan het doen terwijl de volgende 100+ requests al weer gemaakt zijn. Hierdoor krijg je gebruikt de server dubbel zoveel resources gebruikt dus gaat de server eerder op zen bek.
bruteforcer:
- deze moet 1 seconden wachten dus moet 1 seconden langer de socket openhouden, dit is in principe geen probleem zolang de bruteforcer multithread.
De nadelen voor de server wegen niet op tegen de nadelen van de bruteforcer oftwel kan je dit beter niet doen.
server:
- meer resources, apache neemt redelijk wat werkgeheugen in om 1 request af te handelen
- als er gebruteforced wordt doen ze dit met 100+ request tegelijk waarbij al deze requests 1 seconden in het geheugen niks aan het doen terwijl de volgende 100+ requests al weer gemaakt zijn. Hierdoor krijg je gebruikt de server dubbel zoveel resources gebruikt dus gaat de server eerder op zen bek.
bruteforcer:
- deze moet 1 seconden wachten dus moet 1 seconden langer de socket openhouden, dit is in principe geen probleem zolang de bruteforcer multithread.
De nadelen voor de server wegen niet op tegen de nadelen van de bruteforcer oftwel kan je dit beter niet doen.
Het is dus nutteloos te gebruiken bij loginscripts, want diegene kan gewoon meerdere requests tegelijk gebruiken.
Eigenlijk kan ik geen enkele nuttige toepassing van sleep bedenken...
Eigenlijk kan ik geen enkele nuttige toepassing van sleep bedenken...
0 
-0 
-0
Grappig, dit stukje
"Bij een login poging het script ALTIJD met minimaal 1 seconde vertragen. Ongeacht of het een foutieve of correcte login is. Wanneer je alleen bij foutieve login pogingen het script een seconde vertraagt, dan kan de cracker de pauze herkennen en sneller doorgaan naar de volgende poging." (2e deel: Waarom sleep)
Als je die tekst paste in google kom je, heel toevallig, een artikel van phpfreakz tegen. (http://www.phpfreakz.nl/artikelen/106/Webprogrammer%5C%27s-Hacking-Guide?page=11)
Zie kopje oplossing onderaan, misschien netjes om de tekst te veranderen of een bronvermelding te maken? :)
"Bij een login poging het script ALTIJD met minimaal 1 seconde vertragen. Ongeacht of het een foutieve of correcte login is. Wanneer je alleen bij foutieve login pogingen het script een seconde vertraagt, dan kan de cracker de pauze herkennen en sneller doorgaan naar de volgende poging." (2e deel: Waarom sleep)
Als je die tekst paste in google kom je, heel toevallig, een artikel van phpfreakz tegen. (http://www.phpfreakz.nl/artikelen/106/Webprogrammer%5C%27s-Hacking-Guide?page=11)
Zie kopje oplossing onderaan, misschien netjes om de tekst te veranderen of een bronvermelding te maken? :)
Dit script maakt het wel makkelijker om je site plat te leggen. Elke request duurt nu 1 seconde+de tijd voor het opzetten van je pagina (wat niet zo veel zal zijn) De resources blijven gereserveerd. Database verbinding blijft open etc. etc. etc.
Beter is om foute logins te loggen (zowel ip als username) en dan na * aantal foute gewoon tijdelijk blokeren (geen enkele invoer voor de username of ip accepteren)
Verder is de gebruiksvriendelijkheid niet echt goed als je bij het inloggen perse een minuut moet wachten.
Beter is om foute logins te loggen (zowel ip als username) en dan na * aantal foute gewoon tijdelijk blokeren (geen enkele invoer voor de username of ip accepteren)
Verder is de gebruiksvriendelijkheid niet echt goed als je bij het inloggen perse een minuut moet wachten.
0 -0
-0
@Frank Inderdaad is dat stukje tekst van iets anders. Is dat erg? Ik heb zijn tekst gebruikt en er zelf een Tutorial omheen geschreven.
@Tommy, zelfs beveilingsexperts raden dit aan.
@Tommy (weer:D), Dan heb je denk ik nog niet goed gekeken. HEEL VEEL gamingsites gebruiken dit, en wat dacht je van Hotmail?
@Tommy, zelfs beveilingsexperts raden dit aan.
@Tommy (weer:D), Dan heb je denk ik nog niet goed gekeken. HEEL VEEL gamingsites gebruiken dit, en wat dacht je van Hotmail?
0 -0
-0
@Jordy: heb je verdomme m'n bericht gelezen? PHP blijft draaien in je geheugen en dat wil je niet! Dit is zo dom. TJVB vult mijn standpunt aan. En hoezo zou hotmail dit gebruiken? Hotmail maakt gebruik van een mail protocol en jij hebt daar nog niet het minste verstand van hoe een login daarvan werkt. En gamingsites? Welke? Want dan ga ik die eens plat leggen, dat is nog geen 5 minuten werk, gewoon even iets schrijven dat een request blijft loopen en niet op output wacht!
0 -0
-0
@Tommy, probeer maar eens: www.tribalwars.nl.
@de rest, waarom schrijven veel beveiligingsexperts dit dan?
@de rest, waarom schrijven veel beveiligingsexperts dit dan?
@Jordy:
Doe niet alsof je veel weet wanneer je dat niet weet. Jouw methode is prut, pointless en slecht. Je methode wordt niet beter als deze gebruikt wordt op andere sites, wat waarschijnlijk niet zo is.
Doe eens niet zo achterlijk en doe niet alsof je alles weet terwijl men hier met goede argumenten uitlegt waarom deze manier niet goed is. Jouw enige tegenargument is dat andere sites dit gebruiken (wat gewoon compleet gelul is). Je weet zelf niet eens waarom dit een goede methode is: je doet het gewoon omdat je denkt dat dit een goede methode is, en dat is het dus niet. Het wordt hier netjes uitgelegd waarom, en je accepteert de met feiten ondersteunde uitleg niet.
Je zet jezelf echt ongelovelijk keihard voor lul met je uitspraken. Stop ermee, want ik krijg bijna last van plaats vervangende schaamte.
Ow, en noem mij eens een paar van die "beveiligingsexperts" die deze methode gebruiken? Laat eens wat codes van grote projecten zien waarbij deze methode gebruikt wordt? Open SMF, phpBB, wordpress etc eens en laat ons eens zien wat de ervaren scripters voor methode hebben gebruikt.
Doe niet alsof je veel weet wanneer je dat niet weet. Jouw methode is prut, pointless en slecht. Je methode wordt niet beter als deze gebruikt wordt op andere sites, wat waarschijnlijk niet zo is.
Doe eens niet zo achterlijk en doe niet alsof je alles weet terwijl men hier met goede argumenten uitlegt waarom deze manier niet goed is. Jouw enige tegenargument is dat andere sites dit gebruiken (wat gewoon compleet gelul is). Je weet zelf niet eens waarom dit een goede methode is: je doet het gewoon omdat je denkt dat dit een goede methode is, en dat is het dus niet. Het wordt hier netjes uitgelegd waarom, en je accepteert de met feiten ondersteunde uitleg niet.
Je zet jezelf echt ongelovelijk keihard voor lul met je uitspraken. Stop ermee, want ik krijg bijna last van plaats vervangende schaamte.
Ow, en noem mij eens een paar van die "beveiligingsexperts" die deze methode gebruiken? Laat eens wat codes van grote projecten zien waarbij deze methode gebruikt wordt? Open SMF, phpBB, wordpress etc eens en laat ons eens zien wat de ervaren scripters voor methode hebben gebruikt.
0 -0
-0
Ik zei hiervoor dat de sleep() functie nooit echt nodig hoeft te zijn: er is altijd een beter alternatief. Ik kan me tenminste geen situatie voorstellen waarbij sleep() noodzakelijk is.
Natuurlijk ben ik geen PHP pro en is er een redelijke kans dat anderen wel een nuttige implementatie van de sleep() functie kunnen bedenken, maar ik zou zelf niet weten wat.
In mijn ogen is PHP een simpele taal voor het geven van een reactie op een verzoek van een browser.
PHP kent geen async functies, dus de sleep-methode is nutteloos in mijn ogen.
Natuurlijk ben ik geen PHP pro en is er een redelijke kans dat anderen wel een nuttige implementatie van de sleep() functie kunnen bedenken, maar ik zou zelf niet weten wat.
In mijn ogen is PHP een simpele taal voor het geven van een reactie op een verzoek van een browser.
PHP kent geen async functies, dus de sleep-methode is nutteloos in mijn ogen.
0 -0
-0
Ik wil juist dat mijn scripts zo snel mogelijk kunnen draaien. Dus ik ga ze niet vertragen.
Zoals het hier gebruikt wordt zou ik zeker niet doen.
Zoals het hier gebruikt wordt zou ik zeker niet doen.
0 -0
-0
LOL dat zijn dus 2 hele minuten, van mijn waardevolle leven, die ik nooit meer terug krijg, omdat ik jou bullshit heb gelezen. mja.. sleep kan handig zijn *zoals steen al zei* als je meerdere mails stuurt. alleen dit zou ik dan anders doen, gezien de browser hier op raar gaat doen na een aantal uren mailen *ja ik heb dat voorgehad :P*
0 -0
-0
@wesly: dat laat je dus ook niet door een browser doen, maar een cron is hier bijvoorbeeld dan WEL weer handig voor.
0 -0
-0
@Toby hinloopen
Sleep kan nuttig zijn als je php script 100% cpu gebruikt, dit is meestal niet wenselijk, met sleep kan dit opgelost worden door je script tijdelijk te laten slapen waardoor andere processen de cpu kunnen gebruiken, een nadeel aan dit gebruik is natuurlijk dat je snelheid inlevert.
Sleep kan nuttig zijn als je php script 100% cpu gebruikt, dit is meestal niet wenselijk, met sleep kan dit opgelost worden door je script tijdelijk te laten slapen waardoor andere processen de cpu kunnen gebruiken, een nadeel aan dit gebruik is natuurlijk dat je snelheid inlevert.
0 -0
-0
Slechte gids; wat veel mensen hier melden is juist: sleep helpt niet om brute-force crackers te stoppen.
Domme 'noobhacker' van het niveau 'beginner': tikt alles netjes in het formulier en drukt op verzenden.
Iemand met beetje verstand: meerdere, simultane requests uitvoeren door een script. Waarom moeilijk doen met zelf tikken als het ook makkelijk kan in een klik?
Even een nuttige toepassing bedenken van sleep.
...
Progress bar, wanneer je elke seconde een stukje code uitvoert die de voortgang meet. (zonder js / meta refresh)
Verder zie ik niet echt iets nuttigs in deze functie.
Domme 'noobhacker' van het niveau 'beginner': tikt alles netjes in het formulier en drukt op verzenden.
Iemand met beetje verstand: meerdere, simultane requests uitvoeren door een script. Waarom moeilijk doen met zelf tikken als het ook makkelijk kan in een klik?
Even een nuttige toepassing bedenken van sleep.
...
Progress bar, wanneer je elke seconde een stukje code uitvoert die de voortgang meet. (zonder js / meta refresh)
Verder zie ik niet echt iets nuttigs in deze functie.
*zucht*
Een hoop nutteloze reacties die ook nog eens nergens op slaan. Sleep is een bijzonder handige functies als je bepaalde complexe loopstructuren werkt. Ik heb bijvoorbeeld een service draaien (in PHP, ja!) die met forking childprocessen spawnt op het moment dat bepaalde acties uitgevoerd moeten worden. Op deze manier blijft de master schoon, en de children mogen het vuile werk doen en weten precies wat er moet gebeuren omdat dit lokale variabelen van de parent zijn. Maar omdat het extreem zwaar zou zijn voor de service om iedere milliseconde te kijken of zo'n actie moet worden uitgevoerd gebruik je dan sleep(10) om om de 10 seconden te checken of er een actiepunt is.
En verder: jullie weten blijkbaar niet veel van de structuur van PHP + Apache. Zo'n proces maakt handig gebruik van shared memory (op eenzelfde manier als Google Chrome) waardoor ieder apart proces maar een fractie aan geheugen gebruikt. Omdat tijdens een sleep het CPU-gebruik 0 is, zal dit enkel een aanslag op je geheugen hebben (van ongeveer 5 mb, hangt er van af hoe je dit proces opzet). Daar hoef je het niet voor te laten, want dit geheugen wordt gewoon hergebruikt. Als je dan ook nog eens een module als APC gebruikt heb je ook nog eens geen overhead van het compilen, dan wordt het pas een dolle boel.
En het heeft *zeker* wel nut om sleep in dit geval te gebruiken: het kost een cracker simpelweg meer tijd om een respons te krijgen van een gegeven request. Omdat je server het iets zwaarder krijgt zal het nog langer duren en als je gewoon een maximum aantal simultane request per IP op een redelijk getal houdt (15 is normaal) zal de cracker niet meer dan zoveel request tegelijk kunnen sturen zonder tegengehouden te worden.
Just my 2 cents.
Een hoop nutteloze reacties die ook nog eens nergens op slaan. Sleep is een bijzonder handige functies als je bepaalde complexe loopstructuren werkt. Ik heb bijvoorbeeld een service draaien (in PHP, ja!) die met forking childprocessen spawnt op het moment dat bepaalde acties uitgevoerd moeten worden. Op deze manier blijft de master schoon, en de children mogen het vuile werk doen en weten precies wat er moet gebeuren omdat dit lokale variabelen van de parent zijn. Maar omdat het extreem zwaar zou zijn voor de service om iedere milliseconde te kijken of zo'n actie moet worden uitgevoerd gebruik je dan sleep(10) om om de 10 seconden te checken of er een actiepunt is.
En verder: jullie weten blijkbaar niet veel van de structuur van PHP + Apache. Zo'n proces maakt handig gebruik van shared memory (op eenzelfde manier als Google Chrome) waardoor ieder apart proces maar een fractie aan geheugen gebruikt. Omdat tijdens een sleep het CPU-gebruik 0 is, zal dit enkel een aanslag op je geheugen hebben (van ongeveer 5 mb, hangt er van af hoe je dit proces opzet). Daar hoef je het niet voor te laten, want dit geheugen wordt gewoon hergebruikt. Als je dan ook nog eens een module als APC gebruikt heb je ook nog eens geen overhead van het compilen, dan wordt het pas een dolle boel.
En het heeft *zeker* wel nut om sleep in dit geval te gebruiken: het kost een cracker simpelweg meer tijd om een respons te krijgen van een gegeven request. Omdat je server het iets zwaarder krijgt zal het nog langer duren en als je gewoon een maximum aantal simultane request per IP op een redelijk getal houdt (15 is normaal) zal de cracker niet meer dan zoveel request tegelijk kunnen sturen zonder tegengehouden te worden.
Just my 2 cents.
0 -0
-0
@Richard: complimenten voor de heldere uitleg.
Je schrijft dat het zeker nut heeft om sleep() op deze manier te gebruiken. Maar zou jij het vanuit het oogpunt van de gebruiker (zo snel mogelijk in willen loggen en dus niet 1 seconde moeten wachten) toepassen in je loginscripts? Zeker ook omdat er andere - wellicht betere - alternatieven zijn om het bruteforcen van je loginscript te voorkomen?
Je schrijft dat het zeker nut heeft om sleep() op deze manier te gebruiken. Maar zou jij het vanuit het oogpunt van de gebruiker (zo snel mogelijk in willen loggen en dus niet 1 seconde moeten wachten) toepassen in je loginscripts? Zeker ook omdat er andere - wellicht betere - alternatieven zijn om het bruteforcen van je loginscript te voorkomen?
0 -0
-0
@Blanche: nee, dit zou ik zelf niet doen. :]
Ik zou hetzelfde doen als wat Google in feite doet: als je daar via een bepaald IP heel snel requests doet krijg je een CAPTCHA voor je neus die je mag invullen. Dit zou ik zelf ook toepassen, bij bijvoorbeeld 10 verkeerde aanvragen voor een gegeven IP. Zo hou je rekening met grote (school/bedrijfs/etc.)-netwerken en hou je crackers alsnog buiten de deur.
Ja, helaas, iedere methode om dit soort praktijken te kunnen voorkomen heeft z'n nadelen. Sleep is een van de minst mooie, het kost tenslotte geheugen, en geheugen is heel wat duurder dan opslagruimte, maar wel ongeveer even duur als processorkracht. Het punt is dus: wil je een fractie aan geheugen gebruiken om een request iets langer te laten duren: of wil je een structuur aanleggen waarin je foutieve aanlogpogingen bijhoudt en ernaar reageert? Het laatste kost CPU *en* opslag *en* geheugen. Maar op de lange duurt is de laatste optie toch veel mooier, omdat mensen daar veel minder last van hebben. Want echt: een seconde is lang. Dat zou je niet denken, maar in die tijd verstuurt een zekere server in mijn beheer een paar honderd responses. Moet je nagaan :-)
Ik zou hetzelfde doen als wat Google in feite doet: als je daar via een bepaald IP heel snel requests doet krijg je een CAPTCHA voor je neus die je mag invullen. Dit zou ik zelf ook toepassen, bij bijvoorbeeld 10 verkeerde aanvragen voor een gegeven IP. Zo hou je rekening met grote (school/bedrijfs/etc.)-netwerken en hou je crackers alsnog buiten de deur.
Ja, helaas, iedere methode om dit soort praktijken te kunnen voorkomen heeft z'n nadelen. Sleep is een van de minst mooie, het kost tenslotte geheugen, en geheugen is heel wat duurder dan opslagruimte, maar wel ongeveer even duur als processorkracht. Het punt is dus: wil je een fractie aan geheugen gebruiken om een request iets langer te laten duren: of wil je een structuur aanleggen waarin je foutieve aanlogpogingen bijhoudt en ernaar reageert? Het laatste kost CPU *en* opslag *en* geheugen. Maar op de lange duurt is de laatste optie toch veel mooier, omdat mensen daar veel minder last van hebben. Want echt: een seconde is lang. Dat zou je niet denken, maar in die tijd verstuurt een zekere server in mijn beheer een paar honderd responses. Moet je nagaan :-)
0 -0
-0
@Richard: precies hoe ik erover denk dus. De (onnodige) vertraging van 1 seconde is veel te lang en zorgt zeker voor irritatie bij gebruikers die een snelle afhandeling van hun request willen.
@Jordy: een positieve reactie over het gebruik van sleep() ja, maar als je goed leest zie je dat ook Richard niet aanraadt om dit in je login scripts te gebruiken. Jouw stelling dat je verplicht bent om elk loginscript hiervan te voorzien, wordt dus nog steeds niet bevestigd...
@Peter: in tegenstelling, 1 seconde merk je juist wel. Als je nagaat dat webpagina's veelal geladen worden binnen de orde van grootte van 0.1-0.5 seconde, is het tienvoudige daarvan wel erg veel! Zeker aangezien dat nog maar een deelte van de website betreft en de rest dus nog niet eens geladen is...
@Jordy: een positieve reactie over het gebruik van sleep() ja, maar als je goed leest zie je dat ook Richard niet aanraadt om dit in je login scripts te gebruiken. Jouw stelling dat je verplicht bent om elk loginscript hiervan te voorzien, wordt dus nog steeds niet bevestigd...
@Peter: in tegenstelling, 1 seconde merk je juist wel. Als je nagaat dat webpagina's veelal geladen worden binnen de orde van grootte van 0.1-0.5 seconde, is het tienvoudige daarvan wel erg veel! Zeker aangezien dat nog maar een deelte van de website betreft en de rest dus nog niet eens geladen is...
0 -0
-0
sleep kan zeker handig zijn. ik gebruik de functie bv in mijn unix voor scripten die processen afsluiten en op die manier het proces de kans geven om de laatste dingen te unmounten. maar verder vraag ik mij idd af wat deze functie in php doet, waarschijnlijk overgewaait uit bash.
0 -0
-0
@yorick17: misschien moet je de rest van de reacties eens lezen...
0 -0
-0
Dat je dat blijkbaar niet goed hebt gedaan, ik heb haarfijn uitgelegd waarom het een prima functie is.
0 -0
-0
Ik baal er verschrikkelijk van dat hij dezelfde naam heeft als ik.
-gelijk verandert-
-gelijk verandert-
0 -0
-0
het KLINKT handig, een brute-forcer die extra moet wachten bij honderden / duizenden requests, vandaar dat er nogal wat mensen zijn die zoiets als dit aanbevelen, (dit is niet de eerste keer dat ik sleep() bij een inlog systeem zie)
maar zoals al uitgelegd is, het klopt niet, net zoals 1 seconde wachttijd, het KLINKT weinig,
er zijn inderdaad sites die dit gebruiken, (ik meen mij een gamingsite te herinneren) die gemaakt zijn door een stel amateurs,
het is in theorie helemaal niet zo slecht, maar in praktijk zijn er, simpelweg, betere alternatieven om redenen die nu al paar keer genoemd zijn dat ik ze niet zal herhalen.
over sleep,
zelf gebruik ik het niet nee, de beschreven situaties waarbij ze handig zouden zijn ben ik nog niet tegengekomen, dus voor mij persoonlijk lijkt het overbodig, maar als je erg intensief met php omgaat zal het vast wel helpen om de cpu wat meer tijd te geven lijjkt me
maar zoals al uitgelegd is, het klopt niet, net zoals 1 seconde wachttijd, het KLINKT weinig,
er zijn inderdaad sites die dit gebruiken, (ik meen mij een gamingsite te herinneren) die gemaakt zijn door een stel amateurs,
het is in theorie helemaal niet zo slecht, maar in praktijk zijn er, simpelweg, betere alternatieven om redenen die nu al paar keer genoemd zijn dat ik ze niet zal herhalen.
over sleep,
zelf gebruik ik het niet nee, de beschreven situaties waarbij ze handig zouden zijn ben ik nog niet tegengekomen, dus voor mij persoonlijk lijkt het overbodig, maar als je erg intensief met php omgaat zal het vast wel helpen om de cpu wat meer tijd te geven lijjkt me
0 -0
-0
Ok, maar wat vinden jullie nou echt een nadeel? Zo to horen:
1. Spelers moeten 1 seconde langer wachten
2. Het kost geheugen.
Zijn er nog andere nadelen?
1. Spelers moeten 1 seconde langer wachten
2. Het kost geheugen.
Zijn er nog andere nadelen?
0 -0
-0
Heeft phphulp dit ook in gebruik?
Ik moet veel te lang wachten na het plaatsen van een bericht -_-
Ik moet veel te lang wachten na het plaatsen van een bericht -_-
0 -0
-0
@Jordy: zijn er ook voordelen dan?
Je noemt 2 nadelen, maar je vergeet te noemen dat er geen enkel voordeel is.
Je noemt 2 nadelen, maar je vergeet te noemen dat er geen enkel voordeel is.
0 -0
-0
voordeel van sleep in een inlog script:
noobs worden makkelijker herkent
noobs worden makkelijker herkent
0 -0
-0
Waarom zegt hij het dan:
http://www.phpfreakz.nl/downloadz/webprogrammers_hacking_huide.pdf
http://www.phpfreakz.nl/downloadz/webprogrammers_hacking_huide.pdf
0 -0
-0
Jordy schreef op 29.01.2010 15:47
Waarom zegt hij het dan:
http://www.phpfreakz.nl/downloadz/webprogrammers_hacking_huide.pdf
Interessant(A)
Het is allemaal logisch maar aan een paar dingen dacht ik helemaal niet.
Waarom zegt hij het dan:
http://www.phpfreakz.nl/downloadz/webprogrammers_hacking_huide.pdf
Interessant(A)
Het is allemaal logisch maar aan een paar dingen dacht ik helemaal niet.
0 -0
-0
Quote:
Webprogrammer's Hacking Guide door Sijmen Ruwhof 15-07-04 22:32
Beetje achterhaald nietwaar?
0 -0
-0
@Gamer: in 6 jaar veranderd er nou ook weer niet zo extreem veel. Het meeste is nog prima van toepassing.
0 -0
-0
@toby hinloopen, aan de PHP kant niet zo veel nee, maar aan de spamkant wel. Men wordt slimmer.
0 -0
-0
hmz jah.. tis een oplossing.. ik ben meer voorstander van :
X aantal foutieve inlog pogingen..
Account op slot. eventueel requests van ip (+headers) droppen.
Eventueel nog email versturen naar account dat account gelocked is en dat ie kan unlocken
X aantal foutieve inlog pogingen..
Account op slot. eventueel requests van ip (+headers) droppen.
Eventueel nog email versturen naar account dat account gelocked is en dat ie kan unlocken
Ik vind het captcha idee erg goed dat ik hier in de commentaren lees. Ik merk dat er heel veel negatieve respons is op Jordy, ik vraag me dan ook af waarom hij niet eerst een forum post heeft gemaakt.
Ik zie dit soort discussies vaker onder een tutorail, misschien is het een goed idee is om een specifiek 'ik-wil-een-script-maken'-forumonderdeel te maken zodat mensen eerst kunnen discussiëren om zo een zo goed mogelijke tutorial neer te zetten.
Ik zie dit soort discussies vaker onder een tutorail, misschien is het een goed idee is om een specifiek 'ik-wil-een-script-maken'-forumonderdeel te maken zodat mensen eerst kunnen discussiëren om zo een zo goed mogelijke tutorial neer te zetten.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu