Saya tahu ini memiliki peluang besar untuk ditandai sebagai duplikat, tetapi tidak dapat menemukan apa yang saya cari

Ini adalah masalah umum dan saya yakin itu memiliki beberapa solusi praktik terbaik yang terdefinisi dengan baik

Latar Belakang

1. Aplikasi SaaS satu halaman, memiliki banyak drag and drop, pengguna dapat berinteraksi dengannya tanpa banyak komunikasi server untuk jangka waktu tertentu

2. Sesi server hanya menampung objek pengguna, menggunakan cookie sesi yang tidak persisten

3. Sesi berakhir pada server setelah X jam

4. Beberapa hal hanya dimuat saat masuk

Masalah

1. Pengguna bekerja di aplikasi, saat selesai, pengguna tidak logout, biarkan browser tetap terbuka
2. Pengguna kembali setelah lebih dari X jam (sesi tidak valid di server)
3. Pengguna berinteraksi dengan aplikasi tanpa memerlukan koneksi server (menyeret dan menjatuhkan hal-hal, pengeditan teks ...)
4. Hanya pada interaksi server berikutnya (misalkan tidak ada penyimpanan otomatis) pengguna dilemparkan ke halaman login dan kehilangan sebagian dari pekerjaan mereka

Solusi yang memungkinkan

Berikut adalah beberapa solusi yang ada dalam pikiran saya, ingin mendengar jika ada yang lain, dan jika ada yang salah secara fundamental dengan salah satu dari mereka.

1. Jangan pernah logout pengguna

• Bagaimana? baik menyimpan sesi yang panjang, menyimpan cookie tetap, atau ping javaScript "tetap hidup"
• Pro : pengguna tidak perlu khawatir tentang apa pun, memperbaiki masalah bagi mereka
• Cons : tidak sesuai PCI, tidak aman, dan perlu perubahan pengembangan, misalnya hal-hal yang dimuat ke sesi hanya pada login pengguna harus pindah ke salah satu sub model pub (mendengarkan perubahan acara) atau memiliki batas waktu cache.

2. Penyimpanan Lokal

• Bagaimana? gunakan penyimpanan lokal baru untuk menyimpan sementara kondisi jika keluar, redirect ke halaman login, tetap ada sekali login
• Pro : Juga menjadi dasar untuk dukungan "bekerja offline", tidak hanya menangani batas waktu sesi
• Kontra : lebih sulit untuk diterapkan, perlu melakukan penggabungan status pohon data, tidak semua browser mendukung

3. Simpan otomatis

Setiap tindakan pengguna yang mengubah model, harus bertahan segera (atau melalui semacam antrian sisi klien), misalnya jika mereka mencentang kotak centang, mengubah bidang teks, atau menarik dan melepaskan sesuatu, setelah selesai, tahan perubahan tersebut.

• Bagaimana? Gunakan kerangka kerja MV ** (Backbone.js / Knockout.js / Ember.js / Angular.js dll) untuk mengikat model, dan bertahan pada perubahan.
• Kelebihan : Sepertinya solusi bersih, sesi aktif selama pengguna aktif, tidak ada pekerjaan sisi klien yang dilakukan tanpa bertahan.
• Cons : Pengguna tindakan terakhir lakukan setelah batas waktu sesi hilang.

4. Logout pengguna setelah sesi berakhir

ini dapat memiliki beberapa pendekatan

1. Tanyakan pada server "apakah sesi sudah kadaluwarsa" - ini adalah masalah kecil 22 / kucing Schrodinger, karena hanya pertanyaan ke server yang memperpanjang sesi (memulai ulang waktu habis),

   • Bagaimana? Entah memiliki server yang mendukung pertanyaan seperti itu (saya tidak tahu, tapi saya datang dari tanah Jawa) atau, orang hanya dapat menyimpan tabel ID sesi, dan waktu akses terakhir secara manual, dan meminta server dengan melewati sesi ID sebagai parameter alih-alih cookie, saya tidak yakin apakah ini bahkan mungkin, tapi kedengarannya berbahaya, tidak aman, dan desain yang buruk sama sekali. Halaman login, tetap ada setelah login
   • Pro : Jika ada dukungan asli seperti itu di server, terdengar seperti pertanyaan yang bersih dan sah (menanyakan apakah pengguna X masih memiliki sesi atau tidak tanpa memperbaruinya jika mereka melakukannya)
   • Cons : Jika server tidak mendukungnya (dan lagi, saya tidak tahu apakah ada server atau kerangka kerja yang memiliki fungsi ini) maka solusinya memiliki risiko keamanan yang sangat besar.

2. Satu solusi yang saya dengar adalah memiliki sesi pendek di sisi server, dan ping sisi klien yang tetap hidup, yang memiliki jumlah ping maksimum

   • Bagaimana? Sesi singkat di server, klien ping setiap sessionTimeOut / 2, memiliki coba ulang maksimum Y.
   • Pro : Jenis perbaikan masalah, cepat dan kotor
   • Cons : Terasa seperti peretasan, menangani pembaharuan sesi sendiri alih-alih membiarkan server melakukannya

3. Penghitung waktu sisi klien

   • Bagaimana? Memiliki penghitung waktu di sisi klien dan menyinkronkannya dengan server satu dengan memulai kembali pada setiap permintaan agar sama dengan batas waktu sesi server maks dikurangi beberapa lapisan, setelah pengguna tidak mengirim permintaan apa pun ke server, UI menunjukkan "sesi adalah akan kehabisan waktu, apakah Anda ingin melanjutkan? " (seperti yang Anda miliki di perbankan online)

   • Pro : Memperbaiki masalah

   • Kekurangan : Tidak dapat memikirkan apa pun kecuali kebutuhan untuk memastikan sinkronisasi berfungsi

Pertanyaan

Saya mungkin kehilangan sesuatu dalam analisis di atas, mungkin memiliki beberapa kesalahan konyol, dan saya ingin bantuan Anda untuk memperbaikinya. Solusi apa lagi yang bisa saya miliki untuk ini?

Saya pikir solusi sederhana yang paling umum adalah di mana Anda mengatur timer di ujung klien yang menunjukkan pesan setelah bagian tertentu dari jendela batas waktu normal telah berlalu kemudian secara paksa log mereka keluar sebelum sesi akan berakhir pula jika mereka tidak mengambil tindakan.

Penyimpanan lokal dan penyimpanan otomatis memperkenalkan beberapa masalah dengan transaksi dan apa yang sebenarnya disimpan berarti. Saya telah mengerjakan beberapa proyek di mana ini ternyata lebih banyak masalah daripada nilainya ketika basis pengguna tidak memahami mekanisme di baliknya.

Tidak pernah logout dapat dilakukan di mana peraturan mengizinkan, tetapi itu membawa Anda ke kesalahan di mana Anda tidak benar menangani apa yang terjadi jika seseorang keluar secara tak terduga, dan semua bisnis negara menjadi sedikit intensif untuk dipertahankan jika ada banyak yang harus dilacak. pengguna "aktif".

Satu solusi yang saya dengar adalah memiliki sesi pendek di sisi server, dan ping sisi klien yang tetap, yang memiliki jumlah maksimum

Bagaimana? Sesi singkat di server, klien ping setiap sessionTime / 2, memiliki max> retries dari Y. Pro: Jenis perbaikan masalah, cepat dan kotor Kontra: Terasa seperti peretasan, menangani pembaharuan sesi sendiri, bukan> membiarkan server melakukannya

Ini menurut saya solusi terbaik. Mengapa Anda menganggapnya "hack kotor"?

Itu membuat apa yang harus dilakukan. Sementara pengguna bekerja dengan program, sesi akan tetap dibuka.

Setelah pengguna berhenti untuk bekerja dengan program ini, sesi akan ditutup.

Cukup sederhana untuk diimplementasikan.

Persis apa yang dibutuhkan, jika saya mengerti pertanyaannya dengan benar.

Saya sebenarnya membuat aplikasi yang berhubungan dengan ini.

Saya mulai dengan membuat layanan tenang menggunakan Django, Guradian dan Tastypie. Ini mengautentikasi menggunakan APIKEY saja, otorisasi ke objek ditangani oleh Guardian.

Aplikasi Django hanya memiliki satu urlconf tampilan template yang memuat base.html yang ...

Di sisi klien saya membuat aplikasi menggunakan Angular.

Sejauh otentikasi berjalan, ada http-auth-interceptor yang mendengarkan tanggapan 401.

Ketika 401 diterima, ia akan mendukung permintaan keluar dan menjalankan suatu acara "wajib masuk". Ini mungkin terjadi beberapa kali.

Saya memiliki sembulan modal yang berisi formulir masuk yang disajikan ketika acara "wajib masuk" didengar, dan ia melakukan masuk yang mengembalikan sumber daya Pengguna (bundel JSON) yang juga akan berisi APIKEY.

Semua permintaan buffered yang sebelumnya menghasilkan respons 401 diulang dengan APIKEY yang sekarang termasuk dalam header http Otorisasi.

Saya menggunakan layanan sudut lain / pabrik untuk mengelola data json penyimpanan lokal, dan di situlah saya menyimpan nama pengguna dan apikey.

Satu-satunya bagian dari teka-teki yang tersisa untuk dipecahkan adalah bagaimana mengamankan informasi itu, dan bagaimana menegakkan batas waktu pada informasi itu.

Mungkin menggunakan pemeriksaan stempel waktu dari permintaan http terakhir yang valid.

Dalam kasus saya, saya menggunakan sesuatu yang mirip dengan 4.1. Setelah pengguna log dalam permintaan json AJAX didorong sudut sangat ringan terjadi ke REST API pada interval yang ditetapkan terhadap server. Karena persyaratan keamanan, UI eksklusif mengantisipasi server akan mempertahankan sesi untuk pengguna yang menyimpan beberapa informasi yang dilindungi, templat, data, dll di sisi server. Ini masih metode pilihan saya dari perspektif keamanan. Ketika berurusan dengan data sensitif (bukan hanya kata sandi hash dan semacamnya), IMO menyimpannya sisi klien di Penyimpanan Lokal, dll menimbulkan risiko lebih besar dari sisi server (saya yakin seseorang akan berdebat dengan saya). Pihak ketiga menggunakan API yang sama saat berkomunikasi dengan sistem, tetapi harus mengirim kredensial otentikasi pada setiap permintaan.

Sesi di server memang memiliki masa pakai maksimal idle diterapkan, dan mesin penyimpanan sesi memcached (yang juga memiliki masa pakai maksimum yang diterapkan pada saat sesi memori akan ditandai berakhir). Seumur hidup hanya perlu lebih besar dari sesi apa pun seumur hidup Anda abstrak dalam aplikasi Anda (dan tidak harus banyak saya). EG Sesi ini mungkin tidak kedaluwarsa hingga idle selama 48 jam sejauh menyangkut server, tetapi kode Anda mengontrol masa pakai yang sebenarnya. Ini dapat menyebabkan masalah sumber daya jika masa hidup itu terlalu besar, dan Anda melakukan pekerjaan yang buruk dalam mengelola sesi.

Dalam kasus saya, pengguna yang berbeda dapat memiliki batas waktu idle sesi yang berbeda berdasarkan peran mereka dalam organisasi. Server menempatkan batas maksimum pada masa sesi tetapi selama batas yang ditentukan pengguna kurang dari itu, ia berfungsi dengan baik. Setelah server kedaluwarsa sesi, ini adalah masalah yang bisa diperdebatkan karena proses kedaluwarsa sesi sudah ditangani oleh aplikasi dengan anggun. Ini adalah persyaratan dari jenis aplikasi bisnis yang saya bangun.

Setelah sesi pengguna menganggur dan berada dalam ambang batas yang ditentukan aplikasi, API akan menginstruksikan UI untuk menampilkan dialog hitung mundur (seperti yang dilakukan bank), dan setelah berada dalam margin jarak tertentu dalam waktu dari kedaluwarsa dengan anggun. log keluar pengguna. Fungsionalitas ini tetap ada di seluruh jendela browser (karena server berada dalam kontrol), dan acara idle pada jendela apa pun akan memulai timer yang anggun dan proses logout otomatis (dan tetap sinkronkan).

Jika kebetulan sesi berakhir dengan cara tidak berterima (sesi dibuang pada memcached), permintaan berikutnya yang berdampak pada server akan memberi tahu pengguna dan memindahkannya kembali ke titik awal (jarang terjadi, tetapi bisa).