Clientside / Serverside authenticatie check

[Verwijderd]

Ik ben een simpele mobiele app aan het ontwikkelen welke gebruik maakt van jquery aan de client-side.

Nu is het zo dat er ingelogd wordt door middel van een jquery request naar een PHP script wat iets terug parst en de client dus "ingelogd" is. Het nadeel hiervan is dat als je de pagina verlaat, ondanks dat deze niet in een browser draait maar een browser schil, je de login kwijt bent.

Om dit op te lossen heb ik bedacht een variabele (key) in de localStorage op te slaan, geen cookie want dat werkt minder lekker in het framework. Deze variabele wil ik opslaan in een tabel met een timestamp in dezelfde tabel en de userID.

Het probleem dat zich voordoet als je pagina's gaat bezoeken zal je iedere keer een query naar de DB moeten doen om te kijken of de lokaal opgeslagen key aan de hand van de timestamp nog steeds valid is, of dat hij uberhaubt wel bestaat en de user de pagina kan bezoeken.

Uiteraard wil ik die queries niet omdat dit een vreselijke performance bunch gaat geven als mensen lekker gaan browsen. Sessies zijn geen optie in Phonegap dus moet ik een ander iets bedenken om aan de clientside, zonder heel veel data en queries te pompen, te checken of deze user de scripts wel aan mag roepen.

Heeft iemand een idee gezien ik de hele middag al aan het bomen ben over dit probleem en ook geen oplossing kan vinden.

[CodeCaster]

Wat is er mis met een query extra per pagina? Zo traag zal die lokale storage niet zijn, toch?

[Gomez12]

Wanneer wordt die query dan precies een probleem? Als je online werkt dan is het gewoon 1 extra query naast de x die er sowieso al plaatsvinden, dus dat zal geen performance probleem zijn.
Als je offline werkt dan krijg je sowieso geen antwoord van de DB dus dan is er ook geen probleem.

Ik zie het probleem niet echt.

Maar wat sowieso te overwegen valt is om naast je key ook gewoon een laatste checkdatum op te slaan, dan hoef je je key niet bij elke request te checken, maar bijv 1x per uur of per dag en dan bij een request denied vanuit je app gelijk online te gaan checken of er niet al iets bijgekocht is.
Dan heb je de vermeende traagheid bij het checken (die ik dus niet zie) maar 1x per uur/dag.

Let er wel op dat local storage / cookies etc gewoon lokaal uit te lezen zijn en dus te veranderen.

[Verwijderd]

Gomez12 schreef op zaterdag 27 augustus 2011 @ 17:10:
Wanneer wordt die query dan precies een probleem? Als je online werkt dan is het gewoon 1 extra query naast de x die er sowieso al plaatsvinden, dus dat zal geen performance probleem zijn.
Als je offline werkt dan krijg je sowieso geen antwoord van de DB dus dan is er ook geen probleem.

Klopt, de app is alleen volledig online. Offline zijn alleen de HTML/jquery files beschikbaar.

Ik zie het probleem niet echt.

Maar wat sowieso te overwegen valt is om naast je key ook gewoon een laatste checkdatum op te slaan, dan hoef je je key niet bij elke request te checken, maar bijv 1x per uur of per dag en dan bij een request denied vanuit je app gelijk online te gaan checken of er niet al iets bijgekocht is.
Dan heb je de vermeende traagheid bij het checken (die ik dus niet zie) maar 1x per uur/dag.

Ik zou een functie kunnen schrijven welke een keer per uur checkt. Stel een user mag niet meer inloggen dan heb je dus wel een probleem als je zijn "sessie" uit de DB haalt en die check dus niet werkt... dat is mijn main issue.

Opzich is die ene query niet het probleem, hij wordt alleen wel per pagina gedraait, iets wat met php met een if sessie_var toch wat minder resources bevat. Hoewel.... wil je een user kunnen blokkeren zal je toch sessie in een DB op moeten slaan wil je het kunnen manipuleren.

Daar heb je een punt!

Let er wel op dat local storage / cookies etc gewoon lokaal uit te lezen zijn en dus te veranderen.

Klopt, daarom wil ik reatime checken... maarja de performance is mijn main gedachte altijd.

Opzich is mijn check die ik realtime wil doen dus toch de beste manier krijg ik het idee ?

[CodeCaster]

Hoe wil je het anders doen? Als je bij één request per uur controleert of die user nog op jouw systeem mag, wat gebeurt er dan bij alle overige requests? Kijk je naar het IP, wat kan veranderen? Sta je alle requests overal vandaan toe?

Je moet gewoon per request valideren.

[Kanarie]

Als je je echt zorgen maakt om een enkele query per request zou ik eerst eens gaan meten bij hoeveel queries dat een probleem gaat worden.
Het lijkt me buitengewoon onwaarschijnlijk dat deze authenticatie-check je bottleneck zal zijn.

[ Voor 26% gewijzigd door Kanarie op 27-08-2011 17:46 ]

[Gomez12]

Verwijderd schreef op zaterdag 27 augustus 2011 @ 17:29:
[...]
Ik zou een functie kunnen schrijven welke een keer per uur checkt. Stel een user mag niet meer inloggen dan heb je dus wel een probleem als je zijn "sessie" uit de DB haalt en die check dus niet werkt... dat is mijn main issue.

Dat moet je zelf bepalen, ik ken genoeg diensten die enkel per dag/uur betaald worden dus dan is het geen issue. Is het bij jou wel een issue dan gewoon real-time checken.

Opzich is die ene query niet het probleem, hij wordt alleen wel per pagina gedraait, iets wat met php met een if sessie_var toch wat minder resources bevat. Hoewel.... wil je een user kunnen blokkeren zal je toch sessie in een DB op moeten slaan wil je het kunnen manipuleren.

Zet eens schematisch voor jezelf neer wat je totaal allemaal doet per pagina...
Ik gok zomaar dat je tig dingen doet die allemaal langer duren als een simpele :

SQL:

select ...
from sessions
where key=...

Het is een query van niets en als je key ook nog eens een unique-key is dan kost het helemaal niets meer.

Ik zou zo onderhand zeggen : zoek eens op premature optimalisation.
Want zo ongeveer elke andere methode voor dit soort dingen gaat je meer performance kosten dan een simpele query (mits je uiteraard al een db-connectie hebt opgezet).

Een query per pagina is geen ramp (waarschijnlijk vinden er nu al meerdere per pagina plaats).
Oftewel bedenk goed waar je mee bezig bent.

[Verwijderd]

Duidelijk dan bouw ik gewoon een functie die de key even checkt

Thanks!