Met session ID zoeken of combinatie gebruikersnaam, email, enz.
Pagina: « vorige 1 2 3 volgende »
Of de vraag verkeerd gesteld...
Ik sla nu twee sessionwaardes op.
1 vast met ongecodeerde vaste waarde.
En 1 met variabele waarde.
En die check ik bij elke aan te roepen functie of bewerking met de session waardes.
Als dat beide klopt kan ik ook de benodigde gegevens ophalen.
Want de vaste sessionwaarde is de verwijzing waar de gegevens staan.
De vaste waarde had ik in eerste instantie gehasht.
Dus moest ik via omweg de gegevens ophalen.
Maar de set_session()... voer je die ook vaker uit?
Ik zie in het script staan dat die voorkomt aan het eind van een blok.
Bijv. na het bewerken van de persoonlijke gegevens.
De session_regenerate_id() was ik al eerder op gewezen.
Dus die heb ik al ingebakken.
Naar mijn weten bedoel je session_start();?
Die voer je maar een enkele keer uit. Bij voorkeur inderdaad op een index.php in 'single-point-of-entry'.
Maar in .htaccess kan natuurlijk ook:
Dan hoef je geen session_start() meer uit te voeren.
Ah, een custom functie dus :P
Maar is het gebruikelijk om dit meerdere keren aan te roepen?
Als je dit automatisch doet, of op je eerste pagina (of je config, hoewel het niet echt hoort), dan hoef je er niet meer op te letten.
Bedankt tot zover Arien.... nog beetje studeren op sessions...
Tijdens de authenticatiestap (inloggen) stel je -met een bepaalde zekerheid- vast dat iemand is die hij/zij zegt te zijn, en vervolgens sla je iets op in de sessie wat deze gebruiker identificeert, bijvoorbeeld een user id.
Dan haal je elke volgende page-access opnieuw de privileges die deze gebruiker heeft op en sla je deze op in een tijdelijke variabele of object, bijvoorbeeld $user.
Dit zodat er geen informatie "gefixeerd" raakt in de sessie, en die informatie hoef je dan ook niet elke keer te updaten wanneer deze verandert.
Dus als iemand ongein uithaalt met een account dan trek je privileges in, en die worden meteen effectief omdat je die elke page-access opnieuw ophaalt en niet tussendoor opslaat, waarin dus het gevaar zit dat je met verouderde informatie/credentials aan het werken bent.
Dat probleem heb je dus niet als je zo'n user variabele / object elke pagina-aanroep opnieuw opbouwt.
Het is ook een separation of concerns: het inloggen is voor het vaststellen wie iemand is, het opnieuw opbouwen van een tijdelijke variabele waarin privileges worden vermeld is voor het vastleggen wat iemand mag.
Het was ook een voorbeeld Thomas.
Die username die heb ik als vaste sessionwaarde.
En het password in de sessie is vervangen door een random waarde.
Misschien zeg ik nu iets doms. Maar had het idee dat wanneer
een sessiewaarde gestolen wordt, men toch ook de tweede nodig heeft
om wat te kunnen....
De code voorbeelden die je geeft laten zien dat beide waarden inderdaad in de sessie zitten. Vrij zinloos dus.
Gewijzigd op 14/11/2017 11:10:59 door Ben van Velzen
Wachtwoorden sla je helemaal nooit op, zelfs niet in een sessie. Het wachtwoord in de sessie vervangen door een random string is geen goed alternatief, maar toont vooral aan dat er iets scheef zit in je oplossing: er hoort helemaal geen wachtwoord in de sessie, dus ook geen plaatsvervanger.
Onder ideale omstandigheden weet uitsluitend de gebruiker zelf het eigen wachtwoord. De unieke combinatie van gebruikersnaam en wachtwoord gebruik je om een geldige sessie met bepaalde rechten te starten. Daarna heb je ze niet meer nodig — en wat je niet nodig hebt, sla je niet op.
Het enige dat client en server delen via internet, is de unieke sessie-ID. Daarom is het zéér aan te bevelen om SSL te gebruiken: dan wordt deze sessie-ID versleuteld verzonden. Gebruik je sessies voor het verwerken van persoonsgegevens, en dat doe je volgens je code, dan is dat zelfs verplicht.
Als ik echter de sessions zet in een aparte dir dan gaat er nog wat verkeerd.
De sessies worden in die directory geplaatst (Filezilla laat ze netjes zien).
Maar hoe moet ik die waardes weer oproepen?
Dit staat nu bij de set_session() functie:
Code (php)
1
2
3
4
2
3
4
session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../ses/");
session_start();
session_regenerate_id();
$_SESSION['lidnr'] = $lid_nr;
session_start();
session_regenerate_id();
$_SESSION['lidnr'] = $lid_nr;
op de verschillende pagina's:
Per pagina check:
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
function check_status($page) {
session_start();
session_regenerate_id();
if(!isset($_SESSION['lidnr']))
{
header("Location: http://".$_SERVER['HTTP_HOST'].Script_Path."index.php?page=".$page);
}
}
session_start();
session_regenerate_id();
if(!isset($_SESSION['lidnr']))
{
header("Location: http://".$_SERVER['HTTP_HOST'].Script_Path."index.php?page=".$page);
}
}
Log_out functie:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
function log_out($username, $header) {
session_start();
session_unset();
session_destroy();
if(!isset($header)) {
header('Location: ../index.php');
}
else
{
return true;
}
}
session_start();
session_unset();
session_destroy();
if(!isset($header)) {
header('Location: ../index.php');
}
else
{
return true;
}
}
Deel log_in functie:
Je zou dus je eigen session_start() functie kunnen maken welke je vanaf iedere pagina aanroept:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
<?php
function startSession()
{
session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../ses/");
session_start();
session_regenerate_id();
}
?>
function startSession()
{
session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../ses/");
session_start();
session_regenerate_id();
}
?>
Volgens mij had ik dat ook in eerste instantie gedaan.
Ik zal het morgen nog eens nalopen.
Die directory loopt ook al snel vol...
Gewijzigd op 19/11/2017 21:27:55 door Hans De Ridder
Hmmm dat is een goeie. De garbage collector moet wel de oude zooi opruimen anders gaat het op de lange duur niet goed. Op php.net las ik dit nog:
Debian does not use the default garbage collector for sessions. Instead, it sets session.gc_probability to zero and it runs a cron job to clean up old session data in the default directory.
As a result, if your site sets a custom location with session_save_path() you also need to set a value for session.gc_probability, e.g.:
Code (php)
1
2
3
4
2
3
4
<?php
session_save_path('/home/example.com/sessions');
ini_set('session.gc_probability', 1);
?>
session_save_path('/home/example.com/sessions');
ini_set('session.gc_probability', 1);
?>
Otherwise, old files in '/home/example.com/sessions' will never get removed!
Gewijzigd op 19/11/2017 21:33:45 door Frank Nietbelangrijk
Nu kan ik ook fatsoenlijk de lifetime zelf bepalen.
Het werkt nu.
Wel even afwachten of de garbage nu ook verwijderd wordt.
Anders eens per dag/uren een cronjob laten draaien.
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
ini_set("session.gc_maxlifetime", Session_Lifetime);
ini_set('session.cookie_lifetime', Session_Lifetime);
ini_set('session.gc_probability', 1);
ini_set('session.gc_diviser', 100);
session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "/ses/");
session_start();
session_regenerate_id();
ini_set('session.cookie_lifetime', Session_Lifetime);
ini_set('session.gc_probability', 1);
ini_set('session.gc_diviser', 100);
session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "/ses/");
session_start();
session_regenerate_id();
Het is zeer belangrijk dat je na header('Location: ...') altijd een exit zet, anders wordt mogelijk code na de header() aanroep nog steeds uitgevoerd alvorens je wordt geredirect. Dit is zelden tot nooit de bedoeling, dus in jouw code waarschijnlijk ook niet.
Frank Nietbelangrijk op 19/11/2017 21:08:14:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
<?php
function startSession()
{
session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../ses/");
session_start();
session_regenerate_id();
}
?>
function startSession()
{
session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../ses/");
session_start();
session_regenerate_id();
}
?>
Ik weet niet of het verstandig is om configuratie te regelen in een functie. Het lijkt mij beter om dit op één plaats te regelen? Of misschien is het een idee om dit onderdeel te maken van een klasse, en de configuratie te regelen in de initialisatie van een sessie-object? Dat dwingt dan in ieder geval een (wat) uniforme(re) aanpak af.
Ik weet ook niet of het nodig is om elke page-access het sessie-id te vernieuwen? Dit lijkt mij meer iets voor (op het moment van) state changes zoals bij het inloggen. Of wellicht wanneer je gehele authenticatie-systeem is gecentreerd rondom het snel veranderen van allerlei authenticatie-informatie zoals het sessie-id, maar dit lijkt mij zonder specifieke opgaaf van reden niet nodig.
EDIT: uhm, staat het sessie-pad nu in de publieke webdirectory? Voorheen stond deze een niveau hoger? Los daarvan, ik zou nooit ".." gebruiken, maar gewoon een absoluut pad. Sessie-bestanden mogen NOOIT in de publieke webdirectory staan.
Gewijzigd op 20/11/2017 14:19:02 door Thomas van den Heuvel
Eens met Thomas, het constant opnieuw genereren van het session id zorgt alleen voor problemen, en lost niets op. Wanneer je meer bezoekers krijgt zit je dan direct het bestandssysteem vol te plempen met zinloze bestanden, wat de hele zaak een stuk langzamer maakt. Afhankelijk van overige configuratie zoals inode limieten kan dit een website erg snel erg onbruikmaar maken.
Het sessie-pad had ik alleen zo aangegeven als voorbeeld.
Staat buiten de root hoor.
En dat 'exit' zal ik nog toevoegen.
Ik heb inderdaad een pagina met de diverse vaste instellingen.
Die worden via een include aan het process gekoppeld.
Daar staan in:
# Database Infomation.
# Location Infomation.
# System Infomation.
# Session and Cookie Infomation.
# System Settings.
Kan ik daar iets mee met het session blok?
En hoe kan ik dat dan het beste toevoegen?