Kenapa Laravel Bisa Tiba-Tiba Logout Sendiri?

Kasus paling sering terjadi seperti ini: di lokal aplikasi normal, user bisa login dan bertahan lama. Setelah deploy ke production, pindah domain, atau memecah aplikasi ke subdomain seperti app.example.com dan admin.example.com, user mulai mengalami logout sendiri. Kadang baru pindah halaman sudah kembali ke form login, kadang hanya terjadi di browser tertentu, dan kadang hanya muncul saat memakai HTTPS di production.

Secara teknis, masalah ini hampir selalu berhubungan dengan session cookie yang tidak tersimpan, tidak terkirim, atau menunjuk ke sesi yang tidak valid. Laravel menyimpan identitas login melalui session. Jika cookie session tidak cocok dengan domain, protokol, atribut keamanan, atau backend session-nya bermasalah, maka request berikutnya dianggap sebagai user baru. Hasilnya terlihat seperti logout mendadak.

Artikel ini fokus pada problem solving: apa penyebab utamanya, bagian mana yang perlu dicek, dan bagaimana memastikan perbaikannya benar-benar bekerja.

Studi Kasus: Logout Setelah Pindah Subdomain atau Deploy ke Production

Misalnya Anda punya aplikasi yang awalnya berjalan di localhost. Setelah deploy, URL berubah menjadi https://app.example.com. Di saat yang sama, ada halaman login atau layanan lain yang berada di subdomain berbeda, misalnya https://auth.example.com atau https://admin.example.com. User berhasil login, tetapi setelah redirect ke halaman berikutnya, status autentikasi hilang.

Kasus lain: aplikasi sebelumnya memakai HTTP di staging, lalu production memakai HTTPS di belakang reverse proxy atau load balancer. Di browser terlihat login sukses, tetapi cookie session tidak pernah terkirim kembali karena atribut secure, SameSite, atau domain tidak sesuai.

Gejalanya bisa berupa:

  • Login berhasil, lalu langsung kembali ke halaman login.
  • User logout saat berpindah dari satu subdomain ke subdomain lain.
  • Logout hanya terjadi di production, tidak di lokal.
  • Logout terjadi acak setelah deploy baru.
  • CSRF token mismatch yang muncul bersamaan dengan session yang tidak stabil.

Pola ini penting, karena sering menandakan masalah konfigurasi, bukan bug pada form login itu sendiri.

Penyebab Teknis yang Paling Sering

1. SESSION_DOMAIN salah atau tidak cocok

Jika aplikasi harus berbagi login antar-subdomain, cookie session harus di-set ke domain induk yang benar. Salah konfigurasi umum adalah mengisi domain terlalu spesifik atau menambahkan skema seperti https:// ke nilai domain, padahal cookie hanya menerima hostname.

Contoh yang sering dipakai di file .env:

SESSION_DOMAIN=.example.com

Dengan nilai tersebut, cookie dapat dipakai oleh app.example.com, admin.example.com, dan subdomain lain di bawah example.com. Jika Anda mengisi SESSION_DOMAIN=app.example.com, maka cookie hanya berlaku untuk subdomain itu saja. Jika aplikasi memang hanya berjalan di satu host, itu bisa benar. Tetapi untuk skenario pindah subdomain atau login lintas subdomain, itu akan menyebabkan sesi tidak terbaca di host lain.

Kesalahan umum: mengisi SESSION_DOMAIN=https://example.com. Ini salah karena cookie domain tidak boleh berisi protokol.

2. APP_URL tidak sesuai lingkungan nyata

APP_URL bukan satu-satunya penentu session, tetapi nilai yang salah sering memicu efek samping: URL generator salah, redirect antar-domain keliru, atau package tertentu menghasilkan URL yang tidak sesuai host aktual. Jika user login di satu host lalu diarahkan ke host lain yang tidak menerima cookie yang sama, sesi terlihat hilang.

APP_URL=https://app.example.com

Pastikan nilai ini sesuai dengan domain utama aplikasi pada environment tersebut. Jangan biarkan production masih memakai http://localhost atau domain staging lama.

3. Mixed HTTP/HTTPS dan secure cookie

Jika cookie diberi atribut Secure, browser hanya akan mengirimkannya lewat HTTPS. Ini benar untuk production yang aman. Masalah muncul jika aplikasi merasa berjalan di HTTP karena reverse proxy tidak meneruskan header yang benar, sementara browser mengakses HTTPS. Akibatnya, Laravel bisa menghasilkan perilaku cookie yang tidak konsisten.

Di .env biasanya ada konfigurasi seperti:

SESSION_SECURE_COOKIE=true

Ini tepat untuk production HTTPS. Tetapi jika server atau proxy belum dikonfigurasi dengan benar, cookie bisa gagal dikirim atau aplikasi salah mendeteksi skema request. Pada deployment di belakang Nginx proxy, load balancer, atau CDN, pastikan trust proxy Laravel juga benar sehingga request dianggap HTTPS.

4. SameSite cookie tidak cocok

Atribut SameSite memengaruhi kapan browser mengirim cookie, terutama saat ada redirect antar-domain atau integrasi login eksternal. Nilai yang terlalu ketat dapat membuat cookie tidak ikut dalam alur tertentu.

Konfigurasi umum:

SESSION_SAME_SITE=lax

Lax biasanya aman untuk mayoritas aplikasi web biasa. Namun jika ada kebutuhan cross-site yang sah, misalnya integrasi login tertentu atau embed lintas origin, Anda mungkin perlu penyesuaian. Perlu diingat, jika memakai SameSite=None, browser modern mensyaratkan cookie juga Secure, artinya harus lewat HTTPS.

5. Driver session bermasalah

Session Laravel tidak hanya soal cookie; cookie biasanya hanya menyimpan ID sesi, sedangkan datanya disimpan oleh driver seperti file, database, redis, atau cookie. Jika backend session tidak stabil, sesi akan hilang walaupun cookie sudah benar.

Beberapa contoh masalah nyata:

  • file: path penyimpanan tidak writable, container ephemeral, atau file session hilang saat deploy.
  • database: tabel session belum dibuat, koneksi database bermasalah, atau cleanup terlalu agresif.
  • redis: koneksi putus, key expiry terlalu pendek, atau beberapa node tidak berbagi storage yang sama.
  • array: driver ini tidak persisten dan hanya cocok untuk testing, bukan production.

Untuk production, pilihan yang umum dan stabil adalah database atau redis, tergantung arsitektur aplikasi. Jika Anda menjalankan banyak instance aplikasi di beberapa server, jangan mengandalkan session file lokal kecuali ada shared storage yang benar-benar konsisten.

Checklist Pengecekan Konfigurasi

Cek file .env

Mulai dari nilai dasar berikut:

APP_URL=https://app.example.com
SESSION_DRIVER=redis
SESSION_DOMAIN=.example.com
SESSION_SECURE_COOKIE=true
SESSION_SAME_SITE=lax

Sesuaikan SESSION_DRIVER dengan infrastruktur Anda. Jika tidak butuh berbagi session antar-subdomain, SESSION_DOMAIN bisa dikosongkan atau diset spesifik ke host aplikasi. Tetapi jika ada perpindahan antar-subdomain, gunakan domain induk yang tepat.

Cek config/session.php

Pastikan file konfigurasi session memang membaca nilai dari environment. Bagian penting biasanya mencakup driver, lifetime, expire_on_close, domain, secure, dan same_site.

'driver' => env('SESSION_DRIVER', 'file'),
'domain' => env('SESSION_DOMAIN'),
'secure' => env('SESSION_SECURE_COOKIE', false),
'same_site' => env('SESSION_SAME_SITE', 'lax'),

Periksa juga apakah ada perubahan manual yang tidak sinkron dengan nilai .env. Kadang bug muncul karena developer mengubah file config langsung di satu server, sementara environment lain berbeda.

Jangan lupa cache config

Ini sumber masalah yang sangat sering terlewat. Anda sudah mengubah .env, tetapi aplikasi masih membaca konfigurasi lama karena config cache belum dibersihkan.

php artisan config:clear
php artisan cache:clear
php artisan config:cache

Jika deploy memakai pipeline otomatis, pastikan urutannya benar dan file environment yang dipakai memang yang terbaru. Banyak kasus “sudah diperbaiki tapi tetap logout” ternyata hanya karena aplikasi masih memakai config lama.

Verifikasi driver session

Jika memakai database, pastikan tabel session ada. Jika belum, buat migration yang sesuai dan jalankan migrasi.

php artisan session:table
php artisan migrate

Jika memakai Redis, uji koneksinya dan pastikan instance aplikasi membaca Redis yang sama. Pada arsitektur multi-server, sesi harus tersentralisasi. Jika tidak, request A bisa login di server 1 lalu request berikutnya masuk ke server 2 yang tidak punya data session.

Cara Uji di Browser DevTools

Browser DevTools adalah alat tercepat untuk memastikan apakah masalah ada di cookie atau backend session.

1. Cek apakah cookie session dibuat

Buka DevTools, masuk ke tab Application atau Storage, lalu lihat bagian Cookies. Setelah login, cari cookie session Laravel, biasanya bernama laravel_session. Perhatikan atribut berikut:

  • Domain: apakah sesuai host atau domain induk yang diinginkan.
  • Path: biasanya /.
  • Secure: aktif jika aplikasi berjalan di HTTPS.
  • SameSite: apakah nilainya sesuai kebutuhan.
  • Expiry/Max-Age: pastikan tidak langsung expired.

2. Cek apakah cookie ikut terkirim pada request berikutnya

Buka tab Network, klik request setelah login, lalu lihat header Request Headers. Pastikan cookie session benar-benar ikut terkirim. Jika cookie ada di storage tetapi tidak ikut ke request, biasanya masalahnya ada pada domain, protokol, atau atribut cookie.

3. Lihat response header Set-Cookie

Pada response login, lihat apakah server mengirim header Set-Cookie. Dari sini Anda bisa langsung memverifikasi domain, secure, dan sameSite yang dipakai server. Jika nilainya salah, kembali ke konfigurasi Laravel atau proxy.

4. Uji skenario perpindahan host

Jika masalah terjadi saat pindah dari auth.example.com ke app.example.com, ulangi alur itu sambil memonitor cookie di kedua host. Ini penting karena bug sering tidak terlihat saat hanya menguji satu halaman pada host yang sama.

Trade-off dan Kesalahan yang Sering Terjadi

  • Memaksa satu domain untuk semua environment: konfigurasi yang cocok di production belum tentu cocok di localhost.
  • Memakai SESSION_DRIVER=array di environment non-test: session tidak akan persisten.
  • Mengandalkan file session di deployment multi-instance: rawan logout acak jika load balancer membagi request ke server berbeda.
  • Salah mengira APP_URL adalah satu-satunya sumber masalah: APP_URL penting, tetapi cookie domain, sameSite, secure, dan storage session sering lebih menentukan.
  • Tidak membersihkan config cache: perubahan .env tidak terbaca.

Jika aplikasi Anda berada di belakang reverse proxy, jangan lupakan lapisan infrastruktur. Browser hanya peduli pada apa yang benar-benar diterima: domain, HTTPS, dan header cookie. Jadi walaupun kode Laravel benar, konfigurasi web server atau proxy yang salah tetap bisa membuat sesi tampak hilang.

Langkah Praktis yang Paling Aman

  1. Pastikan APP_URL sesuai domain production.
  2. Set SESSION_DOMAIN dengan benar, misalnya .example.com jika perlu berbagi antar-subdomain.
  3. Gunakan SESSION_SECURE_COOKIE=true untuk production HTTPS.
  4. Mulai dari SESSION_SAME_SITE=lax kecuali ada kebutuhan cross-site khusus.
  5. Pastikan SESSION_DRIVER memakai backend yang stabil untuk arsitektur Anda, idealnya database atau Redis di production.
  6. Bersihkan dan bangun ulang config cache setelah mengubah environment.
  7. Uji hasilnya di browser DevTools, bukan hanya berdasarkan asumsi.

Intinya, logout sendiri pada Laravel hampir selalu bisa dilacak secara sistematis. Fokuslah pada tiga lapisan: cookie di browser, konfigurasi Laravel, dan backend penyimpanan session. Jika ketiganya konsisten, masalah biasanya selesai tanpa perlu mengutak-atik logika login secara berlebihan.