Met session ID zoeken of combinatie gebruikersnaam, email, enz.

Een sessiewaarde bestaat uitsluitend op de server. Die kan dus nooit gestolen worden, tenzij je zelf de sessiewaarde prijsgeeft aan de client met een echo $_SESSION['…'].

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.

Eens met Ben en Ward. Graag wil ik nogmaals bekrachtigen dat SSL of te wel een https verbinding een absolute vereiste is ook voor de veiligheid van jouw klanten/gebruikers. Voor de kosten hoef je het ook niet te laten want er zijn zelfs gratis certificaten te verkrijgen bij Comodo en Let’s Encrypt

Alles lijkt nu te werken op de oude manier.
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:

session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../ses/");
session_start();
session_regenerate_id();
$_SESSION['lidnr']  = $lid_nr;

op de verschillende pagina's:

session_start();
session_regenerate_id();

Per pagina check:

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);
		}
	}

Log_out functie:

function log_out($username, $header) {
session_start();
session_unset();
session_destroy();

		if(!isset($header)) {

			header('Location: ../index.php');
		} 
else 
{
			return true;
}
		}

Deel log_in functie:

$this->set_session($lid_nr);	

if(!$page) { $page = Script_Path."include/main.php"; }
			
		if ($page == 'false') {
				return true;
		} else {
				header("Location: http://".$_SERVER['HTTP_HOST'].$page); 
		}

session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../ses/"); zul je ook bij iedere pagina moeten aanroepen. Nu doe je dat alleen in de log_in functie.

Je zou dus je eigen session_start() functie kunnen maken welke je vanaf iedere pagina aanroept:

<?php
function startSession()
{
session_save_path(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../ses/");
session_start();
session_regenerate_id();
}
?>

Bedankt voor je reactie Frank.
Volgens mij had ik dat ook in eerste instantie gedaan.
Ik zal het morgen nog eens nalopen.
Die directory loopt ook al snel vol...

>> Die directory loopt ook al snel vol...

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:


[line]
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.:

<?php
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!
[line]

Heb nu de hele riedel die ik gevonden heb aangegeven.
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.

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();

Enkele kanttekeningen.

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

<?php
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.

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.

Bedankt allemaal...
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?