Sesi yang lenyap tampak seperti masalah masuk padahal hampir tak pernah begitu. Masuknya berhasil; buktinyalah yang hilang di antara satu permintaan dan permintaan berikutnya.

1. Ada sesuatu yang membersihkan berkas sesinya

Di Debian dan Ubuntu, sebuah pengatur waktu menyapu berkas sesi PHP menurut jadwalnya sendiri, memakai pengertian DISTRIBUSINYA tentang masa hidup - bukan yang disetel halaman Anda dengan ini_set. Halaman yang menaikkan gc_maxlifetime saat berjalan tidak mengubah apa pun soal sapuan itu.

systemctl list-timers | grep phpsessionclean
php -i | grep -E "session.save_path|session.gc_maxlifetime"

Perbaikannya adalah direktori sesi milik Anda sendiri yang tak disentuh si penyapu, dengan masa hidup yang disetel di konfigurasi kolamnya, bukan saat berjalan.

php_admin_value[session.save_path] = /var/lib/php/sessions-mysite
php_admin_value[session.gc_maxlifetime] = 86400

2. Kukinya tidak kembali

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
cookie_secure di situs yang juga terjangkau lewat http polos berarti kukinya tak pernah dikirim balik, dan penggunanya seketika terlempar keluar tanpa galat di mana pun. Ia benar di situs yang murni https dan mematikan di situs yang campuran.

3. Dua server, satu sesi

Di belakang penyeimbang beban, permintaan pertama mendarat di server A dan menulis berkas sesi di sana; permintaan kedua mendarat di B, yang tak punya berkas itu. Penggunanya terlempar keluar secara acak, dan inilah versi yang paling sulit dihadirkan ulang.

  • Sesi di Redis atau di basis data, dipakai bersama oleh keduanya.
  • Atau sesi lengket di penyeimbangnya: itu berhasil, dan tidak selamat kalau sebuah server diganti.

Saksikan ia terjadi

ls -la /var/lib/php/sessions/ | head
# log in, then look again: your file should be there and should stay
Kalau berkasnya ada dan penggunanya tetap terlempar keluar, penyebabnya kuki. Kalau berkasnya lenyap, penyebabnya si penyapu. Satu pengamatan itu saja membelah masalahnya jadi dua.