System logowania a session_id

Witam, mam pytanie otóż zrobiłem system który posiada:

• Zapisywanie (session_id) do bazy danych po zalogowaniu.
• Sprawdzanie każdorazowo przy działaniach na stronie czy aktualne session_id zgadza się z tym w bazie.
• Po zalogowaniu session_id jest zmieniane na nowe, czyli poprzednia sesja zostaje unieważniona.

I teraz mam pytanie, czy jest to bezpieczne oraz czy powinienem coś jeszcze dodać?

Nie wiem czy jest bezpieczne za to wiem, że na 100% jest bez sensu.
Po co zapisujesz cokolwiek do bazy? Po to jest sesja w PHP żeby nie kombinować z bazą.
Jak natomiast chcesz tworzyć własne sesje niezależne od PHP to napisz w jakim celu.

W jakim celu? W takim żeby ktoś nie mógł zalogować się na 1 konto na 2 przeglądarkach jednocześnie.

Piotr Wiśniewski napisał(a):

W jakim celu? W takim żeby ktoś nie mógł zalogować się na 1 konto na 2 przeglądarkach jednocześnie.

Przy próbie wykonania akcji używając nieaktualnej sesji usuń tylko ją jakimś session_destroy() i powinno być git.

@katakrowa: wrzucanie sesji do bazy jest dość częste i ma swoje uzasadnienie, jeśli dobrze pamiętam to i 4p trzyma sesje w bazie, dzięki czemu masz listę swoich sesji w panelu i możesz je skasować. Tego na sesja plikowych czy w jakimś redisie nie zrobisz.

ehhhhh napisał(a):

@katakrowa: wrzucanie sesji do bazy jest dość częste i ma swoje uzasadnienie, jeśli dobrze pamiętam to i 4p trzyma sesje w bazie, dzięki czemu masz listę swoich sesji w panelu i możesz je skasować. Tego na sesja plikowych czy w jakimś redisie nie zrobisz.

To, że się często robi nie znaczy, że zawsze będzie dobrze.
Być może sprawdzi się w "statystycznej większości przypadków" ale wystarczy, że będziesz miał serwis za loadbalancerem na kilku maszynach i już będzie problem.
Dlatego pytałem po co to trzyma w bazie danych bo zapisywanie wprost session_id do DB to przeciętny pomysł (a rozumiem, że to jest to session_id https://www.php.net/manual/en/function.session-id.php).
Ja bym jednak dopisał jakiś niezależny manager sesji (własnych).

katakrowa napisał(a):

Dlatego pytałem po co to trzyma w bazie danych bo zapisywanie wprost session_id do DB to przeciętny pomysł (a rozumiem, że to jest to session_id https://www.php.net/manual/en/function.session-id.php).

Dlaczego? Do ciasteczka wrzucasz identyfikator sesji, a samą sesję masz po stronie tradycyjnej bazy, jakiegoś key-value store czy tam redisa.
Raczej większość dużych apek ma właśnie możliwość podejrzenia aktywych sesji i ich zakończenia jak wspominał @ehhhhh.

Napisanie własnego handlera to moment. Takie coś napisałem jakieś 11 lat temu.

https://www.php.net/manual/en/function.session-set-save-handler.php

<?php

function open ($save_path, $session_name) {return true;}
function close() {return true;}

function read ($id) {
	if ($data = db_query("SELECT data FROM ".config('session_table')." WHERE id='$id' LIMIT 1")->fetch_assoc())
		return $data['data'];
	else
		return '';
}

function write ($id, $sess_data) {
	return db_query("INSERT INTO ".config('session_table')." (id, user, time, data) VALUES ('$id', '".get_from_session('id')."', '".time()."', '$sess_data') ON DUPLICATE KEY UPDATE data='$sess_data' , user='".get_from_session('id')."', time='".time()."'");
}

function destroy ($id) {
	return db_query("DELETE FROM ".config('session_table')." WHERE id='$id'");
}

function gc ($maxlifetime) {
  return db_query("DELETE FROM ".config('session_table')." WHERE (time < ".time()." - $maxlifetime ) OR (time < ".time()." - 86400 AND user='0')");
}

session_set_save_handler ("open", "close", "read", "write", "destroy", "gc");

?>