Tellen hoeveel dezelfde accounts actief zijn (andere PC, andere browser)

Er zijn per account maar 2 cookies. Een vaste waarde en een variabele.
Maar die variabele waarde verandert bij het inloggen. (Veiligheid)
En wordt opgeslagen in cookie en bewaart in database.
In het openbare gedeelte worden de cookies opgeroepen en vergeleken met de waardes in de database.
Dus als er wordt ingelogd vanaf verschillende plekken verandert telkens de waarde in cookie en in database.
Dan klopt de test alleen bij de laatst ingelogde! En anderen kunnen geen reactie meer geven.
Maar denk probleem te omzeilen door voor leden ook in het openbare gedeelte met sessie te werken.
Maar gelet op de hoeveelheid aan info en youtubes heb ik geen idee hoe lang leden vertoeven in het openbare gedeelte.
En in de verschillende categorieen.
Kun je een session ook ongezien verlengen als de tijd er bijna op zit?

Als ik mij niet vergis vervalt een sessie standaard na ongeveer 30 inactieve minuten, dus er zit geen harde TTL aan vast.

Ik heb altijd met inloggen maar 1 pagina open. (header verandering).
Ook de pagina's waar je kunt invoeren of wijzigen.
Ik had eerder wat ingebouwd om na sluiten van pagina (dus niet ALLE tabs) automatisch via onbeforeunload
uit te loggen. en de session te beeindigen.
De linkjes om door te verwijzen stopten de werking zodat er tijdens het unloaden geen uitloggen volgde.
Maar moest ik ook weer maatregelen nemen om reloads en 'vorige pagina' voor uitloggen te behoeden.

Denk dat een gewone session start wel genoeg moet zijn.
En dat een lid moet inloggen als hij reactie wil geven.
Maar vind zonder inloggen wel gebruiksvriendelijker.
Ik kan toch bij bijv. wijziging van de pagina weer een nieuwe session starten.
Die loopt dan in principe ook weer 30 minuten.



[size=xsmall]Toevoeging op 20/01/2018 01:19:52:[/size]

Hier nog een scriptje van Stackoverflow die kijkt naar timeout.

On login:

session_start();
$_SESSION['last_action'] = time();

An ajax call every few (eg 20) seconds:

windows.setInterval(keepAliveCall, 20000);

Server side keepalive.php:

session_start();
$_SESSION['last_action'] = time();

On every other action:

session_start();
if ($_SESSION['last_action'] < time() - 30 /* be a little tolerant here */) {
  // destroy the session and quit
}

Hans De Ridder op 19/01/2018 17:33:32

Er worden 2 cookies opgeslagen.

Die worden vergeleken met de opgeslagen waardes op de server.

Zit daar niet het probleem?
1) Kunnen verschillende browsers gebruik maken van dezelfde cookie?
Ik heb het nog niet meegemaakt dat als ik met Chrome ergens inlog, ik ook gelijktijdig met FF dan ben ingelogd.

2) De cookies zijn lokaal opgeslagen. Dat betekent volgens mij dat als iemand thuis is ingelogd en later ergens anders naar de website gaat (zonder thuis te hebben uitgelogd), niet beschikt over de cookies die thuis gezet zijn.
Dan kun je vergelijken met wat er op de server staat, maar dat gaat niet lukken.

Als ik het zo lees, is wat jij wilt niet mogelijk. Andere locatie / browser betekent dat je geen toegang hebt tot de cookies die (met een andere browser / op andere locatie) je eerst had.

Hans De Ridder op 19/01/2018 22:38:04

En nog even denken of ik wel accounts dubbel geactiveerd wil hebben....

Beter lijkt me om dat te voorkomen. Iemand kan maar op 1 plaats zijn.
Wat als iemand de browser afsluit en niet netjes uitlogt. Die zou dan eeuwig ingelogd kunnen blijven?

Dat laatste is eenvoudig te ondervangen met Ajax Ping (vanuit browser). Na whatever seconden geen bericht = uitloggen op server.

Ik heb even gekeken wat er met inloggen allemaal wordt opgeslagen.
Daar zag ik wellicht wel de oplossing.
Ik gebruik 'Last_login'.
Als ik dat aanhoud en tel daarbij op de sessieduur, dan is de laatste met dezelfde account uitgelogd.
Die sessionduur moet dan wel de tijd zijn die bij inloggen is gegeven.
Dan wordt er uitgelogd en de sessie gestopt.
Er mag dus niet een nieuwe tijd worden ingesteld met een start session tussendoor.
Dat kan ik wel regelen waarschijnlijk met een cookie.
Maar weet (nog) niet of dit met php ook mogelijk is.
Even struinen op google.
Dan zorg ik er voor dat bij meerdere inlogs van een account geen nieuwe variabele cookie wordt geset.
Maar de cookie de inhoud krijgt van de al opgeslagen waarde uit de database.
Dan veranderen de cookies niet, zolang de laatste van dezelfde account nog ingelogd is.
Dat laatste had ik al getest en werkt prima.
Kreeg alleen de omschakeling niet voor elkaar.
Voor de slimmerikken die roepen: "maar als de laatste eerder uitlogt dan?".
De absolute tijd is niet zo relevant.
Dan is alleen de tijd dat de cookies niet veranderen wat (onnodig) langer.
En daardoor de veiligheid wat minder.
Maar is geen verband met wachtwoorden of usernames.

Heb de bovenstaande thread nogmaals gelezen en ik denk dat ik nu een beter beeld heb van wat er aan de hand is.

Mijn voorstel is als volgt: stap af van het gebruik van cookies, tenzij dit niet anders kan of een speciale reden heeft.

Ga gebruik maken van sessies. Als je functionaliteit wilt hebben die gebruikers ingelogd houdt / automatisch herinlogt: houd dit dan bij in een database. Maar houd het in eerste instantie simpel. Hiervoor zul je dan wel een cookie met een beperkte levensduur bij moeten houden waarin je bijvoorbeeld een hash opslaat. Deze hash + het IP van de gebruiker + een beperkte levensduur voor dit record tezamen zorgen ervoor dat iemand heringelogd wordt als aan de volgende condities is voldaan:
- de gebruiker is niet ingelogd
- er bestaat een niet-verlopen record met dezelfde hash als in het cookie en hetzelfde IP

Je hebt hiervoor een cookie nodig omdat dit de levensduur van een sessie (die om wat voor reden dan ook tekort is) moet overspannen. Volgens mij was hier al eens een keer een andere thread over geweest. De strekking (van mijn standpunt) daarin was ongeveer het volgende: probeer niet krampachtig een sessie in leven te houden, want deze timeout toch op den duur (om uiteenlopende redenen) maar zorg gewoon -als dit gewenst is- dat je een systeem hebt die je onderwater naadloos opnieuw inlogt, bijvoorbeeld op de hierboven beschreven wijze. Dit lijkt mij gewoon een veel simpelere constructie, waarbij de sessie dus een soort van automatische doorstart maakt.

Voor handelingen waar je geen speciale "rechten" voor nodig hebt: hiervoor zou je ook niets hoeven te doen. Wel zul je formulieren moeten beveiligen tegen spam, bijvoorbeeld met een token (misschien was dat het nut van het continu veranderende cookie?) die wordt meegestuurd en na afloop via een andere wijze wordt gecontroleerd. Doe je dit echter via cookies, dan zou je elke keer dezelfde cookiewaarde+formulierwaarde kunnen doorsturen wat het hele systeem een beetje om zeep helpt omdat de controle toegankelijk (en manipuleerbaar) is door de client zijde. Daarom gebruik je sessies - dit noem ik altijd "serverside cookies" - de controle bij sessies ligt aan de serverkant en niet bij de gebruiker. En dat is natuurlijk altijd een beter plan dan de controle bij de gebruiker te leggen want deze zou je eigenlijk nooit moeten vertrouwen.

Vraag ik mij nog steeds af wat het nut is van het continu veranderende cookie? Dit zou een soort van constructie met een nonce kunnen zijn, maar ik denk niet dat het allemaal zo geavanceerd is? Los daarvan, als dit als zodanig gebruikt wordt dan lijkt mij een sessie veel veiliger voor dit soort spul dan een cookie. Cookies zijn clientside en dus, zoals gezegd, manipuleerbaar.

De waarde van de variabele cookie verandert, als een extra stukje veiligheid.
Mocht iemand eens aan vriend op vreemde PC de werking laten zien,
dan heeft die persoon de 2 cookies ook.
Maar hij kan er niet zoveel mee.
Er zal dan gevraagd worden om in te loggen.

Ik heb het nu (voorlopig) opgelost, zonder extra cookie.

Zolang er geen inlog is, is er niks aan de hand.
Lid kan zonder inlog alle openbare pagina's bezoeken en ook reageren als lid.
Op andere pc's of pc's kan dat ook.
Cookies wijzigen uitsluitend bij inloggen.

Zodra er ingelogd is verandert de waarde van de variabele cookie nog 1 keer.
Vervolgens worden er geen wijzigingen meer aangebracht in de variabele cookie.
Tot het moment dat de laatst ingelogde uit wordt gelogd.
Daarna wordt alles weer hersteld naar de oude situatie.

Bij het lid (zelfde account) die wil reageren op openbare pagina's betekent dit
dat men hooguit 1 keer dan moet inloggen om te kunnen reageren via die andere browser of PC.
Dit is mijn code (IPTC).

$cookie_code=$_COOKIE['code'];
$cookie_user=$_COOKIE['user'];

if (isset($cookie_user, $cookie_code)) 
 {
$file=realpath($_SERVER['DOCUMENT_ROOT'])."foto/".$cookie_user.'.jpg';
$i=new iptc($file);
$r=$i->get(LAST_LOGIN); 

$end_session=$r+3600;
$real_time=time();

if($real_time>$end_session)
{
echo $i->set(ACCOUNT_ACTIVE,'0');
$i->write();
}
else
{
echo $i->set(ACCOUNT_ACTIVE,'1');
$i->write();
}
}

Bij inlogscript:

if ($account_active==0)
{
setcookie($cookie_name, $cookie_code, time() + (90 * 86400), "/"); // = 90 day
}
else
{
$i = new iptc($file);
$r = $i->get(LID_HASH); 
$s = $i->get(COOKIE_CODE);
$cookie_code=$s;
setcookie($cookie_name, $s, time() + (90 * 86400), "/"); // = 90 day
}

Hoe ingewikkelder je het (voor jezelf) maakt, hoe belangrijker het in ieder geval is om code te annoteren (te voorzien van commentaar). Als ik dit over een week, maand of jaar nog eens bekijk, dan zou ik bij god niet weten wat deze code precies zou moeten doen.

Leg altijd in commentaar uit en vast wat de strekking / het effect van code is (of zou moeten zijn). Als je dat dan op een gegeven moment terugleest dan denk je misschien ook op een gegeven moment "waar was ik mee bezig" of "waarom heb ik ooit voor deze aanpak gekozen".

Maar ook voor debugging. Dit kan dan -in het gunstigste geval- heel snel duidelijk maken dat de code het voorgestelde plan mogelijk niet juist implementeert.

Wat ik begrijp:

Bij een account heb je 2 cookie-gegevens in je database staan, die ook bij de browser bekend zijn en waarmee je dus weet dat iemand ingelogd is (op die browser).

En dat geeft een probleem als iemand met een 2e client inlogt.

Wat nu als je het omdraait? Als je bij de 2 cookie gegevens noteert welk account daarbij hoort.

dus browser 1 heeft een cookie A en een cookie B en daarmee is de user Hans ingelogd (met Firefox voor mijn part).
Er is ook een record in je database met cookies X en Y en eveneens user Hans, maar nu op IE op een andere PC...