Bagaimana cara membedakan sesi di tab browser?


136

Dalam aplikasi web yang diimplementasikan di java menggunakan JSP dan Servlets; jika saya menyimpan informasi di sesi pengguna, informasi ini dibagikan dari semua tab dari browser yang sama. Bagaimana cara membedakan sesi di tab browser? Dalam contoh ini:

<%@page language="java"%>
<%
String user = request.getParameter("user");
user = (user == null ? (String)session.getAttribute("SESSIONS_USER") : user);
session.setAttribute("SESSIONS_USER",user);
%>
<html><head></head><body>
<%=user %>
<form method="post">
User:<input name="user" value="">
<input type="submit" value="send">
</form>
</body></html>

Salin kode ini di halaman jsp ( testpage.jsp), terapkan file ini dalam konteks aplikasi web yang ada di server (saya menggunakan Apache Tomcat), lalu buka browser (FF, IE7 atau Opera) menggunakan URL yang benar ( localhost/context1/testpage.jsp), ketik nama Anda di input dan kirimkan formulir. Kemudian buka tab baru di browser yang sama, lalu Anda dapat melihat nama Anda (dapatkan dari sesi) di tab baru. Hati-hati dengan cache-browser, kadang-kadang sepertinya itu tidak terjadi, tetapi ada di cache, segarkan tab kedua.

Terima kasih.



1
Ini adalah hal yang harus dilakukan pengguna: Buka IE, klik "File-> Sesi Baru"
Stefan Steiger

3
@Quandary, solusi Anda bukanlah solusi umum (di browser lain tidak berfungsi) dan, yang paling penting, tidak ramah pengguna (pengguna tidak tahu tentang sesi).
Oriol Terradas

2
Beberapa orang sepertinya tidak dapat membayangkan apa tujuan dari ini semua. Domain masalahnya adalah hampir semua situasi di mana Anda ingin mengizinkan "tampilan" yang berbeda dari situs web Anda. Setelah pengguna dapat memiliki lebih dari satu tampilan situs web Anda, mereka pasti lama (atau tidak sengaja mencoba) untuk mengakses dua tampilan berbeda pada saat yang bersamaan. Contohnya meliputi: pembuatan versi sementara (beralih ke melihat situs web seperti yang pernah ada di masa lalu); sandboxing (membuat perubahan pada situs web yang belum bisa dilihat orang lain); tampilan berbasis peran (lihat tampilan situs web bagi pengguna yang kurang memiliki hak istimewa); dll.
Ron Burk

Jawaban:


92

Anda dapat menggunakan HTML5 SessionStorage (window.sessionStorage). Anda akan membuat id acak dan menyimpannya di Penyimpanan sesi per Tab Browser. Kemudian setiap tab browser memiliki ID-nya sendiri.

Data yang disimpan menggunakan sessionStorage tidak bertahan di semua tab browser, meskipun dua tab berisi halaman web dari asal domain yang sama. Dengan kata lain, data di dalam sessionStorage tidak hanya terbatas pada domain dan direktori halaman pemanggilan, tetapi tab browser tempat halaman itu berada. Bandingkan dengan cookie sesi, yang menyimpan data dari tab ke tab.


7
Dari dokumen: "Data yang disimpan menggunakan sessionStorage tidak bertahan di seluruh tab browser, meskipun dua tab berisi halaman web dari asal domain yang sama. Dengan kata lain, data di dalam sessionStorage tidak hanya terbatas pada domain dan direktori halaman pemanggilan, tetapi tab browser tempat halaman berada. Bandingkan dengan cookie sesi, yang menyimpan data dari tab ke tab. " Pengujian sederhana mengonfirmasi perilaku ini di Chrome dan FF.
jswanson

21
Perhatikan, ID akan diduplikasi saat menggunakan fitur "Tab Duplikat" Chrome. Ini umumnya bukan masalah, tetapi harus dipikirkan dengan matang.
JosiahDaniels

Kecuali saat Anda "Menduplikasi" tab di Chrome atau Firefox. Dalam kasus ini, SessionStorage disalin.
Tiago Freitas Leal

@ Gonzalo Gallotti: Dan bagaimana hal itu membantu saya jika sesi berada di sisi server? )))
Stefan Steiger

@Tokopedia Kemudian Anda dapat mengirim id BrowserTab (disimpan di Penyimpanan Sesi) dengan Panggilan Ajax Anda. Di sisi server Anda akan membutuhkan logika khusus, karena Sesi Web sama. Tapi Anda bisa membuat HashMap dengan objek Sesi dengan tab.
Gonzalo Gallotti

24

Anda harus menyadari bahwa sesi sisi server adalah add-on buatan untuk HTTP. Karena HTTP tidak memiliki kewarganegaraan, server perlu mengenali bahwa suatu permintaan milik pengguna tertentu yang diketahuinya dan memiliki sesinya. Ada 2 cara untuk melakukan ini:

  • Kue. Metode yang lebih bersih dan lebih populer, tetapi itu berarti bahwa semua tab browser dan jendela oleh satu pengguna berbagi sesi - IMO ini sebenarnya diinginkan, dan saya akan sangat kesal pada situs yang membuat saya masuk untuk setiap tab baru, karena saya menggunakan tab dengan sangat intensif
  • Penulisan ulang URL. Setiap URL di situs memiliki ID sesi yang ditambahkan padanya. Ini lebih banyak pekerjaan (Anda harus melakukan sesuatu di mana pun Anda memiliki tautan internal situs), tetapi memungkinkan untuk memiliki sesi terpisah di tab yang berbeda, meskipun tab yang dibuka melalui tautan masih akan berbagi sesi. Ini juga berarti pengguna harus selalu masuk ketika dia datang ke situs Anda.

Apa yang kamu coba lakukan? Mengapa Anda ingin tab memiliki sesi terpisah? Mungkin ada cara untuk mencapai tujuan Anda tanpa menggunakan sesi sama sekali?

Edit: Untuk pengujian, solusi lain dapat ditemukan (seperti menjalankan beberapa instance browser pada VM terpisah). Jika satu pengguna perlu bertindak dalam peran yang berbeda pada waktu yang sama, maka konsep "peran" harus ditangani dalam aplikasi sehingga satu login dapat memiliki beberapa peran. Anda harus memutuskan apakah ini, menggunakan penulisan ulang URL, atau hanya hidup dengan situasi saat ini lebih dapat diterima, karena tidak mungkin untuk menangani tab browser secara terpisah dengan sesi berbasis cookie.


6
Ini untuk aplikasi besar yang menyimpan informasi pengguna dan lingkungan. Ketika seseorang masuk dengan pengguna yang berbeda di tab yang berbeda, untuk ujian atau untuk peran yang berbeda, maka dia melintasi informasi dari tab.
Oriol Terradas

Hanya pengaya yang sangat terlambat, tentang mengapa: karena saya perlu mengetahui ini untuk mengetahui halaman MANA di situs saya, misalnya, pengguna difokuskan, dan bukan hanya mereka berpindah dari halaman ke halaman ( sebagai gantinya mereka pergi dari tab ke tab).
Oliver Williams

16

Properti Javascript window.name, adalah satu-satunya hal yang akan tetap ada di seluruh aktivitas tab, tetapi bisa tetap independen (bukan URL guff).


3
window.sessionStorage juga melakukannya
felickz

3
hati-hati karena penyimpanan sesi disalin ke tab baru ketika pengguna memilih "buka di tab baru" ... berharap saya memiliki tautan untuk detailnya tetapi lihat: bugzilla.mozilla.org/show_bug.cgi?id=818389
felickz

2
Ketahuilah bahwa hal yang Anda simpan di jendela.name pengaturan akan tetap tersedia di domain lain, ketika pengguna beralih ke halaman lain di tab yang sama.
nakib

15

Seharusnya tidak. Jika Anda ingin melakukan hal seperti itu, Anda perlu memaksa pengguna untuk menggunakan satu contoh aplikasi Anda dengan menulis URL dengan cepat, gunakan sessionID yang sama (bukan sessionid itu tidak akan berfungsi) id dan meneruskannya di setiap URL.

Saya tidak tahu mengapa Anda membutuhkannya tetapi kecuali Anda perlu membuat aplikasi yang benar-benar tidak dapat digunakan, jangan lakukan itu.


9
Ini untuk aplikasi besar yang menyimpan informasi pengguna dan lingkungan. Ketika seseorang masuk dengan pengguna yang berbeda di tab yang berbeda, untuk ujian atau untuk peran yang berbeda, maka dia melintasi informasi dari tab.
Oriol Terradas

39
jawaban lama Saya tahu, tetapi email google memungkinkan Anda memiliki akun yang berbeda pada setiap tab dan ini bukan "aplikasi yang sama sekali tidak dapat digunakan"
George

2
@George, Jawabannya masih benar, dan sebagai contoh Anda akan melihat di nomor url mewakili indeks akun yang disimpan di cookie, email google hanya menyimpan semua cookie dan pilih satu sesuai dengan url.
Mhmd

6
Belum yakin jawabannya masih benar, Anda jelas bisa melakukannya. Gmail melakukannya. Adapun cara melakukannya, mungkin tidak elegan tetapi berhasil dan itulah yang penting
George

2
Jawaban lama tetapi saya dapat menambahkan bahwa Whatsapp dan Telegram tidak mengizinkan Anda membuka dua tab pada saat yang bersamaan. Ini tidak membuat mereka tidak dapat digunakan
Charlie

13

Saya datang dengan solusi baru, yang memiliki sedikit overhead, tetapi tampaknya berfungsi sejauh prototipe. Asumsinya adalah bahwa Anda berada dalam lingkungan sistem terhormat untuk masuk, meskipun ini dapat diadaptasi dengan meminta ulang kata sandi setiap kali Anda berpindah tab.

Gunakan penyimpanan lokal (atau yang setara) dan peristiwa penyimpanan HTML5 untuk mendeteksi ketika tab browser baru telah mengalihkan pengguna mana yang aktif. Ketika itu terjadi, buat ghost overlay dengan pesan yang mengatakan Anda tidak dapat menggunakan jendela saat ini (atau nonaktifkan jendela untuk sementara waktu, Anda mungkin tidak ingin jendela menjadi begitu mencolok.) Saat jendela kembali fokus, kirim log permintaan AJAX pengguna kembali.

Satu peringatan untuk pendekatan ini: Anda tidak dapat memiliki panggilan AJAX normal (yaitu, panggilan yang bergantung pada sesi Anda) terjadi di jendela yang tidak memiliki fokus (misalnya jika Anda memiliki panggilan terjadi setelah penundaan), kecuali Anda secara manual membuat panggilan login ulang AJAX sebelum itu. Jadi sebenarnya yang perlu Anda lakukan adalah memeriksa fungsi AJAX Anda terlebih dahulu untuk memastikan localStorage.currently_logged_in_user_id === window.yourAppNameSpace.user_id, dan jika tidak, login terlebih dahulu melalui AJAX.

Kondisi lainnya adalah balapan: jika Anda dapat beralih jendela cukup cepat untuk membingungkannya, Anda mungkin akan berakhir dengan urutan relogin1-> relogin2-> ajax1-> ajax2, dengan ajax1 dibuat di bawah sesi yang salah. Mengatasi ini dengan mendorong permintaan login AJAX ke dalam array, dan kemudian menyimpan dan sebelum mengeluarkan permintaan login baru, batalkan semua permintaan saat ini.

Gotcha terakhir yang harus diperhatikan adalah penyegaran jendela. Jika seseorang menyegarkan jendela saat Anda memiliki permintaan masuk AJAX aktif tetapi belum selesai, itu akan disegarkan atas nama orang yang salah. Dalam kasus ini, Anda dapat menggunakan acara beforeunload yang tidak standar untuk memperingatkan pengguna tentang potensi kekacauan dan meminta mereka untuk mengklik Batal, sementara itu menerbitkan kembali permintaan login AJAX. Maka satu-satunya cara mereka dapat merusaknya adalah dengan mengklik OK sebelum permintaan selesai (atau dengan tidak sengaja menekan enter / spacebar, karena OK - sayangnya untuk kasus ini - default.) Ada cara lain untuk menangani kasus ini, seperti mendeteksi penekanan F5 dan Ctrl + R / Alt + R, yang akan berfungsi dalam banyak kasus, tetapi dapat digagalkan oleh konfigurasi ulang pintasan keyboard pengguna atau penggunaan OS alternatif. Namun, ini adalah kasus yang sedikit rumit pada kenyataannya, dan skenario terburuk tidak pernah seburuk itu: dalam konfigurasi sistem kehormatan, Anda akan masuk sebagai orang yang salah (tetapi Anda dapat memperjelas bahwa hal ini terjadi dengan mempersonalisasi halaman dengan warna, gaya, nama yang ditampilkan secara mencolok, dll.); dalam konfigurasi kata sandi, tanggung jawab ada pada orang terakhir yang memasukkan kata sandi untuk keluar atau membagikan sesi mereka, atau jika orang ini sebenarnya adalah pengguna saat ini, maka tidak ada pelanggaran.

Tetapi pada akhirnya Anda memiliki aplikasi satu-pengguna-per-tab yang (mudah-mudahan) berfungsi sebagaimana mestinya, tanpa harus menyiapkan profil, menggunakan IE, atau menulis ulang URL. Pastikan Anda membuatnya jelas di setiap tab yang masuk ke tab tertentu itu, meskipun ...


6
+1 karena Anda meluangkan waktu untuk benar-benar memikirkannya! :-) Melihat semua peringatan yang Anda tahu itu ide yang buruk. Pelajaran saya dari hal ini adalah untuk benar-benar memahami data apa yang harus masuk ke sesi dan data mana yang tidak boleh.
Peter

10

Kami memiliki masalah ini dan kami menyelesaikannya dengan sangat mudah. Maksud saya mudah karena tidak ada pemrograman yang terlibat. Apa yang kami ingin lakukan adalah membiarkan pengguna masuk ke banyak akun dalam jendela browser yang sama tanpa bentrok sesi.

Jadi solusinya adalah subdomain acak.

23423.abc.com
242234.abc.com
235643.abc.com

Jadi kami meminta admin sistem kami untuk mengkonfigurasi sertifikat SSL untuk * .abc.com bukan abc.com. Kemudian dengan sedikit perubahan kode, setiap kali pengguna mencoba masuk, dia masuk ke tab dengan nomor subdomain acak. sehingga setiap tab dapat memiliki sesinya sendiri-sendiri. Juga untuk menghindari konflik, kami mengembangkan nomor acak menggunakan hash atau md5 id pengguna.


3
Ini sepertinya alternatif cerdas untuk penulisan ulang URL. Anda berakhir dengan variabel yang diinginkan (ID sesi) di tempat yang sesuai dengan HTTP yang terlihat tetapi tidak mengganggu. Nits yang muncul dalam pikiran: 1) memerlukan karakter pengganti di DNS, jelas, 2) seluruh situs web Anda harus menghindari URL absolut yang akan mengarahkan pengguna kembali ke (misalnya) subdomain "www", 3) mungkin ingin mencegah perayap web , tapi ini mungkin situasi web pribadi sehingga mungkin sudah dilakukan. Terima kasih telah membagikan ini!
Ron Burk

@ user3534653: Saya suka pendekatannya. Tapi Anda mengatakan "tidak ada pemrograman". Kemudian Anda melanjutkan dengan mengatakan "dengan sedikit perubahan kode". Jadi sungguh, sedikit perubahan kode bukanlah pemrograman? ;) Selain itu, pendekatan ini mungkin tidak berfungsi jika Anda memiliki beberapa aplikasi dengan tautan kanonis dengan domain yang di-hardcode / dikonfigurasi (secara kanonik).
Stefan Steiger

5

Saya akan jujur ​​di sini. . . semua di atas mungkin atau mungkin tidak benar, tetapi semuanya tampak JAUH terlalu rumit, atau tidak membahas mengetahui tab apa yang sedang digunakan sisi server.

Terkadang kita perlu menggunakan pisau cukur Occam.

Inilah pendekatan Occam: (tidak, saya bukan Occam, dia meninggal pada 1347)

1) tetapkan ID unik browser ke halaman Anda saat dimuat. . . jika dan hanya jika jendela belum memiliki id (jadi gunakan awalan dan deteksi)

2) di setiap halaman yang Anda miliki (gunakan file global atau sesuatu) cukup letakkan kode di tempat untuk mendeteksi acara fokus dan / atau acara gerakan mouse. (Saya akan menggunakan jquery untuk bagian ini, untuk kemudahan penulisan kode)

3) dalam fungsi fokus (dan / atau gerakan mouse), tetapkan cookie dengan window.name di dalamnya

4) membaca nilai cookie dari sisi server Anda ketika Anda perlu membaca / menulis data khusus tab.

Sisi klien:

//Events 
$(window).ready(function() {generateWindowID()});
$(window).focus(function() {setAppId()});
$(window).mouseover(function() {setAppId()});


function generateWindowID()
{
    //first see if the name is already set, if not, set it.
    if (se_appframe().name.indexOf("SEAppId") == -1){
            "window.name = 'SEAppId' + (new Date()).getTime()
    }
    setAppId()
}

function setAppId()
{
    //generate the cookie
    strCookie = 'seAppId=' + se_appframe().name + ';';
    strCookie += ' path=/';

    if (window.location.protocol.toLowerCase() == 'https:'){
        strCookie += ' secure;';
    }

    document.cookie = strCookie;
}

sisi server (C # - untuk tujuan contoh)

//variable name 
string varname = "";
HttpCookie aCookie = Request.Cookies["seAppId"];
if(aCookie != null) {
     varname  = Request.Cookies["seAppId"].Value + "_";
}
varname += "_mySessionVariable";

//write session data 
Session[varname] = "ABC123";

//readsession data 
String myVariable = Session[varname];

Selesai.


1
Saya sangat menyukai jawaban Anda yang disederhanakan dan referensi pisau cukur Occam. Hanya ingin memeriksa ulang apakah solusi ini masih berfungsi untuk Anda.
Jeff Marino

1
Perlu diperhatikan bahwa jika menyegarkan halaman harus mempertahankan sesinya, pendekatan ini tidak akan berfungsi. Pendekatan lain yang disarankan dalam jawaban lain menggunakan window.sessionStorage tampaknya lebih masuk akal bagi saya.
Rosenfeld

@quijibo Masih berfungsi dengan sempurna di aplikasi saya, ya. Adapun menyegarkan halaman, mungkin benar untuk beberapa browser, menggunakan window.sessionStorage dapat menyelesaikan masalah, belum mencobanya
Mike A.

3
Apa fungsi "se_appframe ()"?
AndreMiranda

Apa itu se_appframe ?
Kiquenet

2

Anda dapat menggunakan penulisan ulang tautan untuk menambahkan pengenal unik ke semua URL Anda saat memulai di satu halaman (misalnya index.html / jsp / apa saja). Browser akan menggunakan cookie yang sama untuk semua tab Anda sehingga semua yang Anda masukkan ke dalam cookie tidak akan unik.


2
Saya pikir menulis ulang tautan untuk menyandikan sesi itu membosankan dan rawan kesalahan. Saya memiliki aplikasi besar, dengan banyak tautan, saya membutuhkan solusi transparan atau mudah diterapkan.
Oriol Terradas

2

Saya pikir apa yang mungkin Anda inginkan adalah mempertahankan status navigasi di seluruh tab dan tidak secara khusus membuat satu sesi per tab. Inilah yang dicapai kerangka kerja Seam dengan lingkup / konteks Percakapan mereka. Penerapannya bergantung pada fakta bahwa id percakapan disebarkan dengan setiap permintaan dan menciptakan gagasan percakapan di sisi server, yang merupakan sesuatu yang terletak di antara sesi dan permintaan. Ini memungkinkan untuk kontrol aliran navigasi dan manajemen negara.

Meskipun itu terutama ditujukan untuk JSF, lihat dan periksa apakah itu adalah sesuatu di mana Anda dapat mengambil beberapa ide dari: http://docs.jboss.org/seam/latest/reference/en-US/html_single/#d0e3620



1

Pendekatan lain yang berhasil adalah membuat id jendela unik dan menyimpan nilai ini bersama dengan id sesi dalam tabel database. Id jendela yang sering saya gunakan adalah integer (sekarang). Nilai ini dibuat saat jendela dibuka dan dialihkan ke jendela yang sama jika jendela di-refresh, dimuat ulang, atau dikirim ke jendela itu sendiri. Nilai jendela (input) disimpan di tabel lokal menggunakan tautan. Ketika sebuah nilai diperlukan, itu diperoleh dari tabel database berdasarkan tautan id jendela / id sesi. Meskipun pendekatan ini membutuhkan database lokal, ini hampir sangat mudah. Penggunaan tabel database mudah bagi saya, tetapi saya tidak melihat alasan mengapa array lokal tidak berfungsi dengan baik.




1

Catatan: Solusi di sini perlu dilakukan pada tahap desain aplikasi. Akan sulit untuk merekayasa ini nanti.

Gunakan bidang tersembunyi untuk menyebarkan pengenal sesi .

Agar ini berfungsi, setiap halaman harus menyertakan formulir:

<form method="post" action="/handler">

  <input type="hidden" name="sessionId" value="123456890123456890ABCDEF01" />
  <input type="hidden" name="action" value="" />

</form>

Setiap tindakan di sisi Anda, termasuk navigasi, POST formulir kembali (pengaturan yang actionsesuai). Untuk permintaan "tidak aman" , Anda dapat menyertakan parameter lain, misalnya berisi nilai JSON dari data yang akan dikirim:

<input type="hidden" name="action" value="completeCheckout" />
<input type="hidden" name="data" value='{ "cardNumber" : "4111111111111111", ... ' />

Karena tidak ada cookie, setiap tab akan independen dan tidak memiliki pengetahuan tentang sesi lain di browser yang sama.

Banyak keuntungan, terutama jika menyangkut keamanan:

  • Tidak bergantung pada JavaScript atau HTML5.
  • Melindungi secara inheren terhadap CSRF .
  • Tidak bergantung pada cookie, jadi lindungi dari POODLE .
  • Tidak rentan terhadap fiksasi sesi .
  • Dapat mencegah penggunaan tombol kembali, yang diinginkan saat Anda ingin pengguna mengikuti jalur yang ditetapkan melalui situs Anda (yang berarti bug logika yang terkadang dapat diserang oleh permintaan yang tidak sesuai pesanan, dapat dicegah).

Beberapa kelemahan:

  • Fungsionalitas tombol kembali mungkin diinginkan.
  • Tidak terlalu efektif dengan caching karena setiap tindakan adalah POST.

Informasi lebih lanjut disini .


1

Saya menyelesaikan ini dengan cara berikut:

  • Saya telah menetapkan nama ke jendela, nama ini sama dengan sumber daya koneksi.
  • ditambah 1 untuk menghapus disimpan dalam cookie untuk melampirkan koneksi.
  • Saya telah membuat fungsi untuk menangkap semua respon xmloutput dan menetapkan sid dan menyingkirkan cookie dalam format json. Saya melakukan ini untuk setiap window.name.

disini kodenya:

var deferred = $q.defer(),
        self = this,
        onConnect = function(status){
          if (status === Strophe.Status.CONNECTING) {
            deferred.notify({status: 'connecting'});
          } else if (status === Strophe.Status.CONNFAIL) {
            self.connected = false;
            deferred.notify({status: 'fail'});
          } else if (status === Strophe.Status.DISCONNECTING) {
            deferred.notify({status: 'disconnecting'});
          } else if (status === Strophe.Status.DISCONNECTED) {
            self.connected = false;
            deferred.notify({status: 'disconnected'});
          } else if (status === Strophe.Status.CONNECTED) {
            self.connection.send($pres().tree());
            self.connected = true;
            deferred.resolve({status: 'connected'});
          } else if (status === Strophe.Status.ATTACHED) {
            deferred.resolve({status: 'attached'});
            self.connected = true;
          }
        },
        output = function(data){
          if (self.connected){
            var rid = $(data).attr('rid'),
                sid = $(data).attr('sid'),
                storage = {};

            if (localStorageService.cookie.get('day_bind')){
              storage = localStorageService.cookie.get('day_bind');
            }else{
              storage = {};
            }
            storage[$window.name] = sid + '-' + rid;
            localStorageService.cookie.set('day_bind', angular.toJson(storage));
          }
        };
    if ($window.name){
      var storage = localStorageService.cookie.get('day_bind'),
          value = storage[$window.name].split('-')
          sid = value[0],
          rid = value[1];
      self.connection = new Strophe.Connection(BoshService);
      self.connection.xmlOutput = output;
      self.connection.attach('bosh@' + BoshDomain + '/' + $window.name, sid, parseInt(rid, 10) + 1, onConnect);
    }else{
      $window.name = 'web_' + (new Date()).getTime();
      self.connection = new Strophe.Connection(BoshService);
      self.connection.xmlOutput = output;
      self.connection.connect('bosh@' + BoshDomain + '/' + $window.name, '123456', onConnect);
    }

Saya harap membantu Anda


0

Saya telah membaca posting ini karena saya pikir saya ingin melakukan hal yang sama. Saya memiliki situasi serupa untuk aplikasi yang sedang saya kerjakan. Dan sebenarnya ini masalah pengujian lebih dari kepraktisan.

Setelah membaca jawaban ini, terutama yang diberikan oleh Michael Borgwardt, saya menyadari alur kerja yang perlu ada:

  1. Jika pengguna menavigasi ke layar login, periksa sesi yang ada. Jika ada, lewati layar login dan kirimkan ke layar selamat datang.
  2. Jika pengguna (dalam kasus saya) menavigasi ke layar pendaftaran, periksa sesi yang ada. Jika ada, beri tahu pengguna Anda akan logout dari sesi itu. Jika mereka setuju, keluar, dan mulai pendaftaran.

Ini akan memecahkan masalah pengguna melihat data "pengguna lain" di sesi mereka. Mereka tidak benar-benar melihat data "pengguna lain" di sesi mereka, mereka benar-benar melihat data dari satu-satunya sesi yang mereka buka. Jelas ini menyebabkan beberapa data menarik karena beberapa operasi menimpa beberapa data sesi dan bukan yang lain sehingga Anda memiliki kombinasi data dalam satu sesi tersebut.

Sekarang, untuk mengatasi masalah pengujian. Satu-satunya pendekatan yang layak adalah memanfaatkan Petunjuk Preprocessor untuk menentukan apakah sesi tanpa cookie harus digunakan. Lihat, dengan membangun konfigurasi khusus untuk lingkungan tertentu, saya dapat membuat beberapa asumsi tentang lingkungan dan untuk apa lingkungan itu digunakan. Ini akan memungkinkan saya untuk secara teknis memiliki dua pengguna yang masuk pada saat yang sama dan penguji dapat menguji beberapa skenario dari sesi browser yang sama tanpa pernah keluar dari salah satu sesi server tersebut.

Namun, pendekatan ini memiliki beberapa peringatan serius. Paling tidak adalah fakta bahwa apa yang diuji oleh penguji bukanlah apa yang akan berjalan dalam produksi.

Jadi saya pikir saya harus mengatakan, ini pada akhirnya adalah ide yang buruk.


0

Menyimpan timeStamp di window.sessionStorage jika belum disetel. Ini akan memberikan nilai unik untuk setiap tab (meskipun URL-nya sama)

http://www.javascriptkit.com/javatutors/domstorage.shtml

https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage

Semoga ini membantu.


1
Ini mungkin baik-baik saja, tetapi secara teoritis tidak aman. Beberapa sistem operasi (misalnya Windows) memiliki perincian stempel waktu yang sangat kasar yang berarti Anda mungkin mencari stempel waktu beberapa kali dan mendapatkan nilai yang sama. Selain itu, jika Anda membuka kembali browser setelah crash dan membuka kembali semua tab sekaligus, mereka mungkin mendapatkan stempel waktu yang sama.
Gili

0
How to differ sessions in browser-tabs?

Cara paling mudah untuk membedakan sesi di tab browser adalah dengan melarang domain tertentu Anda menyetel cookie. Dengan begitu, Anda dapat memiliki sesi terpisah dari tab terpisah. Misalnya Anda melarang cookie dari domain ini: www.xyz.com. Anda membuka Tab 1, masuk dan mulai menjelajah. Kemudian Anda membuka Tab 2, dan Anda dapat masuk sebagai pengguna yang sama atau pengguna berbeda; bagaimanapun juga, Anda akan memiliki sesi yang terpisah dari Tab 1. Dan seterusnya.

Tetapi tentu saja hal ini dimungkinkan bila Anda memiliki kendali atas sisi klien. Jika tidak, solusi yang ditentukan oleh orang-orang di sini harus diterapkan.


0

Anda perlu melakukannya

1- Simpan cookie untuk daftar akun

2- opsional menyimpan cookie sebagai default

3- simpan untuk setiap akun dengan indeksnya seperti acc1, acc2

4- taruh di url sesuatu yang mewakili indeks akun dan jika tidak Anda akan memilih yang default seperti google mail domain.com/0/some-url >> 0 di sini mewakili indeks akun juga Anda mungkin perlu tahu caranya gunakan urlwrite

5- ketika memilih cookie, pilih sesuai dengan urlpath Anda mewakili indeks akun

Salam


0

Saya melihat banyak implementasi yang memiliki perubahan sisi klien untuk memanipulasi cookie id sesi. Tetapi dalam sesi umum cookie id harus HttpOnly sehingga java-script tidak dapat mengakses jika tidak maka dapat menyebabkan Session Hijack melalui XSS


0

Jika itu karena setiap tab akan menjalankan aliran yang berbeda dalam aplikasi Anda, dan mencampurkan kedua aliran menyebabkan masalah, maka lebih baik untuk "Regionalisasi" objek sesi Anda, sehingga setiap aliran akan menggunakan wilayah sesi yang berbeda

Wilayah ini dapat diimplementasikan sesederhana memiliki prefiks yang berbeda untuk setiap aliran, atau objek sesi akan menyimpan beberapa peta (satu untuk setiap aliran), dan Anda menggunakan peta tersebut sebagai ganti atribut sesi, yang terbaik adalah memperluas kelas sesi Anda dan gunakan saja.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.