tijdsynchronisatie testcase
Was het niet het idee dat je via PHP de timestamp van de webserver in Javascript propt? Op die manier zijn de tijden op de server en bij de client in eerste instantie gelijk.
De javascript timeout timer gaat ervan uit (althans, in Webkit) dat Javascript continu draait - wat dus tijdens 'sluimeren' niet het geval is. Hij haalt die tijd niet in, vandaar dat je klok niet meer gelijk loopt. Ga je uit van een delta-tijd, op basis van de computers klok (die geen problemen met sluimeren heeft) dan is je tijd wel weer aardig kloppend.
en @ jelmer het is ook niet de bedoeling dat je een hele dag die inlogpagina open hebt staan he.
ik denk dat ik in het uiteindelijke inlogscript rekening ga houden met een maximum tijdsverschil van 20 seconden.
indien meer dan 20 seconden, inlog gefaald en reload van de pagina ofzo om opnieuw te synchroniseren. bedankt om mede te delen robert ;)
Ik zou minstens voor een minuut tijd gaan, misschien 2. Deur open doen, telefoon opnemen, naar beneden schreeuwen dat je koffie wil - het kost allemaal meer dan 20 seconden.
Over timeouts gesproken, heb je al een oplossing voor latency? Ik heb bijvoorbeeld met de PHPhulp server wel eens wachttijden van 15 seconden voordat ik uberhaupt antwoord terug krijg. Of ik ben te zwaar aan het downloaden. Hoe ver moet de pagina geladen zijn voordat Javascript eindelijk uitgevoerd mag worden? Als dat nog van de 20 seconden af gaat, kan er een hele kleine tijdspan overblijven voor de client om z'n wachtwoord & gebruikersnaam in te voeren. Geen oplezen van een briefje (zoals bijv. de gebruikernaam van de Postbank, no way dat je die kan onthouden) dus een drang tot simpelere gebruikersnamen/wachtwoorden. Dit is dan wel het doem-scenario, maar wil je die trade-off echt maken; hoe ver wil je gaan in het afsnoepen van gebruiksvriendelijkheid om de beveiliging op te schroeven?
Althans, dit was toch voor de beveiliging? Wat is precies de rest van het idee? Kerberos implementeren met enkel Javascript is zo goed als onmogelijk lijkt mij. Daarnaast gebruikt Kerberos de tijden slechts als verloop-tijd voor de tickets als ik het goed heb begrepen. Wel goed oppassen met time-outs. Het laatste wat je wil is dat de bezoeker een paginalang bericht heeft getypt, vervolgens tot ontdekking komt dat z'n sessie verlopen is en hij moet inloggen, dus zijn wachtwoord gaat opzoeken, tot de ontdekking komt dat z'n tijd verlopen is, en z'n bericht kwijt is.
Ik zal niet met tickets e.d. gaan werken.
Ik neem enkel het idee over dat een wachtwoord niet naar internet verstuurd wordt maar wel bv een tijd die versleuteld is. en de key om te versleutelen is het wachtwoord dat je ingevoerd hebt.
die 20 sec is niet de tijd die ze hebben om op inloggen te klikken, maar zoals ik al meermaals zei en op die pagina ook, het is het tijdsverschil tussen de door java berekende tijd en de tijd op de server.
Op mijn testpagina zie je dat ie gemiddeld 3.4 seconden is. Er zijn 3 ip's die hun gemiddelde boven de 10 hebben en 2 ip's die gemiddeld meer dan 20 haalden, maar die hebben ook meetwaarden onder de 20, meestal komt het omdat men 1 hoge uitschieter heeft.
Hieruit leid ik af dat 20 best een ruime marge is..
Nu hoor ik jullie al denken als je 10 pagina's opent en 8 daarvan is je tijd meer dan 20 sec verschil is dit echt niet handig, maar het dient echter alleen om in te loggen. En ik denk ook niet dat jullie hier bv op phphulp elk uur opnieuw moeten inloggen ofzo. Jelmer, ik gebruik enkel het idee van inloggen van Kerberos.
ik werk nu met (new Date).getTime(); en bereken in het begin het tijdsverschil zoals Jelmer dat aangaf. Bij het submitten breng ik het tijdsverschil terug in rekening en stuur dan dus een tijd die ongeveer zou moeten gelijklopen met de tijd op de server.
Ook heb ik vorderingen gemaakt ivm het encrypteren en decrypteren.
Binnenkort zal ik de combinatie van de 2 scripts laten testen.
(hiervoor best een nieuw topic aanmaken?) Ondertussen nog eens uit de oude doos gehaald,
Access denied for user 'Hipska'@'localhost' (using password: YES) Werkt niet.
Nu doe ik het anders en laat wel weten wanneer ik een test beschikbaar stel. Nee idd dat voorbeeld is niet meer actief. Het is trouwens nog volgens die oude methode.
storeman schreef op 15.01.2008 15:20:
@Jelmer: Ik denk dat tussen de computertimer en de javascript timer een paar lagen zitten, maar om de JS timer onbetrouwbaar te noemen. Ik mag hopen dat hier geen miliseconden verschil in zit.
De javascript timeout timer gaat ervan uit (althans, in Webkit) dat Javascript continu draait - wat dus tijdens 'sluimeren' niet het geval is. Hij haalt die tijd niet in, vandaar dat je klok niet meer gelijk loopt. Ga je uit van een delta-tijd, op basis van de computers klok (die geen problemen met sluimeren heeft) dan is je tijd wel weer aardig kloppend.
Excuus, ik had dat inderdaad niet goed gelezen, maar dan klopt het allemaal prima ja..:) Ik wou je net nog wijzen op GMdate die alles (afhankelijk van je tijdzone) automatisch naar Greenwitch meantime omzet..:)
en @ jelmer het is ook niet de bedoeling dat je een hele dag die inlogpagina open hebt staan he.
ik denk dat ik in het uiteindelijke inlogscript rekening ga houden met een maximum tijdsverschil van 20 seconden.
indien meer dan 20 seconden, inlog gefaald en reload van de pagina ofzo om opnieuw te synchroniseren.
Ik zou minstens voor een minuut tijd gaan, misschien 2. Deur open doen, telefoon opnemen, naar beneden schreeuwen dat je koffie wil - het kost allemaal meer dan 20 seconden.
Over timeouts gesproken, heb je al een oplossing voor latency? Ik heb bijvoorbeeld met de PHPhulp server wel eens wachttijden van 15 seconden voordat ik uberhaupt antwoord terug krijg. Of ik ben te zwaar aan het downloaden. Hoe ver moet de pagina geladen zijn voordat Javascript eindelijk uitgevoerd mag worden? Als dat nog van de 20 seconden af gaat, kan er een hele kleine tijdspan overblijven voor de client om z'n wachtwoord & gebruikersnaam in te voeren. Geen oplezen van een briefje (zoals bijv. de gebruikernaam van de Postbank, no way dat je die kan onthouden) dus een drang tot simpelere gebruikersnamen/wachtwoorden. Dit is dan wel het doem-scenario, maar wil je die trade-off echt maken; hoe ver wil je gaan in het afsnoepen van gebruiksvriendelijkheid om de beveiliging op te schroeven?
Althans, dit was toch voor de beveiliging? Wat is precies de rest van het idee? Kerberos implementeren met enkel Javascript is zo goed als onmogelijk lijkt mij. Daarnaast gebruikt Kerberos de tijden slechts als verloop-tijd voor de tickets als ik het goed heb begrepen.
Ik zal niet met tickets e.d. gaan werken.
Ik neem enkel het idee over dat een wachtwoord niet naar internet verstuurd wordt maar wel bv een tijd die versleuteld is. en de key om te versleutelen is het wachtwoord dat je ingevoerd hebt.
die 20 sec is niet de tijd die ze hebben om op inloggen te klikken, maar zoals ik al meermaals zei en op die pagina ook, het is het tijdsverschil tussen de door java berekende tijd en de tijd op de server.
Op mijn testpagina zie je dat ie gemiddeld 3.4 seconden is. Er zijn 3 ip's die hun gemiddelde boven de 10 hebben en 2 ip's die gemiddeld meer dan 20 haalden, maar die hebben ook meetwaarden onder de 20, meestal komt het omdat men 1 hoge uitschieter heeft.
Hieruit leid ik af dat 20 best een ruime marge is..
Nu hoor ik jullie al denken als je 10 pagina's opent en 8 daarvan is je tijd meer dan 20 sec verschil is dit echt niet handig, maar het dient echter alleen om in te loggen. En ik denk ook niet dat jullie hier bv op phphulp elk uur opnieuw moeten inloggen ofzo.
Nee, okee, dan heb ik het verkeerd begrepen. Het lijkt wel een goeie manier. Het is hoe dan ook veiliger dan het wachtwoord letterlijk als tekst over de lijn heen sturen.
idd, niet voor niets gebruikt windows ook dit protocol bij aanmelden op servers in netwerken..
ik werk nu met (new Date).getTime(); en bereken in het begin het tijdsverschil zoals Jelmer dat aangaf. Bij het submitten breng ik het tijdsverschil terug in rekening en stuur dan dus een tijd die ongeveer zou moeten gelijklopen met de tijd op de server.
Ook heb ik vorderingen gemaakt ivm het encrypteren en decrypteren.
Binnenkort zal ik de combinatie van de 2 scripts laten testen.
(hiervoor best een nieuw topic aanmaken?)
Access denied for user 'Hipska'@'localhost' (using password: YES)
Nu doe ik het anders en laat wel weten wanneer ik een test beschikbaar stel.