Tarayıcı sekmelerinde oturumlar nasıl farklılık gösterir?

135

Java'da JSP ve Servlets kullanılarak uygulanan bir web uygulamasında; bilgileri kullanıcı oturumunda saklarsam, bu bilgiler aynı tarayıcıdaki tüm sekmelerden paylaşılır. Tarayıcı sekmelerinde oturumlar nasıl farklılık gösterir? Bu örnekte:

<%@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>

Bu kodu bir jsp sayfasına ( testpage.jsp) kopyalayın , bu dosyayı sunucudaki bir web uygulamasının varolan bir bağlamında dağıtın (Apache Tomcat kullanıyorum), ardından doğru URL'yi ( localhost/context1/testpage.jsp) kullanarak bir tarayıcı (FF, IE7 veya Opera ) açın, yazın isminizi girin ve formu gönderin. Ardından aynı tarayıcıda yeni bir sekme açın ve adınızı (oturumdan alın) yeni sekmede görebilirsiniz. Tarayıcı önbelleğine dikkat edin, bazen gerçekleşmez gibi görünüyor, ancak önbellekte, ikinci sekmeyi yenileyin.

Teşekkürler.

jsp  servlets  browser  web-applications  sessionid 
— Oriol Terradas
kaynak
— Bozho
1
Bu kullanıcının yapması gereken bir şey: IE'yi açın, "Dosya-> Yeni Oturum" u tıklayın
— Stefan Steiger
3
@Quandary, çözümünüz genel bir çözüm değildir (diğer tarayıcılarda çalışmaz) ve en önemlisi kullanıcı dostu değildir (kullanıcılar oturumları bilmez).
— Oriol Terradas
2
Bazı insanlar bunun amacının ne olduğunu hayal edemiyor gibi görünüyor. Sorunlu etki alanı, web sitenizin farklı "görünümlerine" izin vermek istediğiniz her durumdur. Kullanıcı web sitenizin birden fazla görünümüne sahip olduktan sonra, aynı anda iki farklı görünüme erişmek için kaçınılmaz olarak uzun (veya yanlışlıkla) dener. Örnekler arasında şunlar bulunmaktadır: geçici sürüm oluşturma (geçmişte belirli bir noktada olduğu gibi web sitesini görüntülemeye geçme); sanal alan (başkalarının göremediği web sitesinde değişiklik yapmak); rol tabanlı görünümler (web sitesinin daha az ayrıcalıklı kullanıcıya nasıl baktığını görün); vs
— Ron Burk

Yanıtlar:

92

HTML5 SessionStorage (window.sessionStorage) kullanabilirsiniz. Rastgele bir kimlik oluşturacak ve oturumda Tarayıcı Sekmesi başına Depolama sekmesine kaydedeceksiniz. Sonra her tarayıcı sekmesinin kendi kimliği vardır.

SessionStorage kullanılarak saklanan veriler, iki sekmenin her ikisi de aynı etki alanı kaynağından web sayfaları içeriyor olsa bile tarayıcı sekmelerinde kalmaz. Başka bir deyişle, sessionStorage içindeki veriler yalnızca çağrılan sayfanın etki alanı ve diziniyle değil, sayfanın içinde bulunduğu tarayıcı sekmesiyle de sınırlıdır. Sekmeden sekmeye veri kalan oturum çerezleriyle karşılaştırın.

— Gonzalo Gallotti
kaynak
7
Dokümanlar'dan: "sessionStorage kullanılarak depolanan veriler, iki sekmenin her ikisi de aynı etki alanı kaynağından web sayfaları içeriyor olsa bile tarayıcı sekmelerinde kalmaz. sayfanın bulunduğu tarayıcı sekmesi. Sekmeden sekmeye veri kalıcı olan çerezleri oturumla karşılaştırın. " Basit test, Chrome ve FF'de bu davranışı onaylar.
— jswanson
21
Chrome'un "Yinelenen Sekme" özelliği kullanıldığında kimlik çoğaltılacağını unutmayın. Bu genellikle bir sorun değildir, ancak düşünülmesi gerekir.
— JosiahDaniels
Chrome veya Firefox'ta bir sekmeyi "Çoğalttığınız" hariç. Bu durumda, SessionStorage kopyalanır.
— Tiago Freitas Leal
@Gonzalo Gallotti: Oturum sunucu tarafı ise bu bana nasıl yardımcı olacak? )))
— Stefan Steiger
@StefanSteiger. Ardından Ajax Call'unuzla BrowserTab kimliğini (Session Storage'a kaydedilmiş) gönderebilirsiniz. WebSession Aynı olduğu için sunucu tarafında özel mantığa ihtiyacınız olacaktır. Ancak Sekme yoluyla Oturum nesneleriyle bir HashMap oluşturabilirsiniz.
— Gonzalo Gallotti
23

Sunucu tarafı oturumlarının HTTP'ye yapay bir eklenti olduğunu anlamalısınız. HTTP vatansız olduğundan, sunucunun bir isteğin bildiği ve oturumu olduğu belirli bir kullanıcıya ait olduğunu bir şekilde tanıması gerekir. Bunu yapmanın 2 yolu vardır:

  • Kurabiye. Daha temiz ve daha popüler yöntem, ancak bir kullanıcının tüm tarayıcı sekmelerinin ve pencerelerinin oturumu paylaştığı anlamına gelir - IMO bu aslında istenir ve ben her yeni sekme için giriş yapmamı sağlayan bir sitede çok rahatsız olurum. sekmeleri çok yoğun kullan
  • URL yeniden yazma. Sitedeki herhangi bir URL'nin kendisine eklenmiş bir oturum kimliği vardır. Bu daha fazla iştir (site dahili bağlantınız olan her yerde bir şeyler yapmanız gerekir), ancak bağlantı yoluyla açılan sekmeler yine de oturumu paylaşacak olsa da, farklı sekmelerde ayrı oturumlar yapılmasını mümkün kılar. Ayrıca, kullanıcının sitenize geldiğinde her zaman oturum açması gerektiği anlamına gelir.

Zaten ne yapmaya çalışıyorsun? Sekmelerin neden ayrı oturumlar olmasını istesiniz? Belki hiç seans kullanmadan hedefinize ulaşmanın bir yolu var mı?

Düzenleme: Sınama için başka çözümler bulunabilir (ayrı VM'lerde birkaç tarayıcı örneği çalıştırmak gibi). Bir kullanıcının aynı anda farklı rollerde hareket etmesi gerekiyorsa, bir oturumun birkaç rolü olabilmesi için uygulamada "rol" kavramı ele alınmalıdır. URL yeniden yazma özelliğini kullanarak mı yoksa yalnızca mevcut durumla mı yaşayacağınıza karar vermeniz gerekir, çünkü tarayıcı sekmelerini çerez tabanlı oturumlarla ayrı ayrı işlemek mümkün değildir.

— Michael Borgwardt
kaynak
6
Kullanıcı bilgilerini ve çevreyi koruyan büyük bir uygulama içindir. Birisi farklı sekmelerde farklı kullanıcılarla, test için veya farklı roller için giriş yaptığında, sekmelerden bilgileri geçer.
— Oriol Terradas
Nedenine göre sadece çok geç bir eklenti: çünkü sitemdeki WHICH sayfasını bilmek için bunu bilmem gerekiyor, örneğin, bir kullanıcı sadece sayfadan sayfaya gittiklerine değil, bunun yerine sekmeden sekmeye geçtiler).
— Oliver Williams
16

Window.name Javascript özelliği, sekme etkinliği boyunca devam edecek ancak bağımsız kalabilecek tek şeydir (URL guff yerine).

— Dave Bish
kaynak
3
window.sessionStorage da iyi
— felickz
3
Kullanıcı "yeni sekmede aç" ı seçtiğinde oturum depolama alanı yeni bir sekmeye kopyalanırken dikkatli olun ... ayrıntılar için bağlantıya sahip
— olmamı
2
Window.name ayarına kaydettiğiniz şeyin, kullanıcı aynı sekmedeki diğer sayfalara geçtiğinde diğer alanlarda da kullanılabilir olacağını unutmayın.
— nakib
15

Yapmamalısın.Böyle bir şey yapmak isterseniz, kullanıcıyı anında URL'ler yazarak uygulamanızın tek bir örneğini kullanmaya zorlamanız gerekir, aynı şekilde bir oturum kimliği kullanın (sessionid değil işe yaramaz) kimliği ve her URL'ye iletin.

Neden ihtiyacınız olduğunu bilmiyorum ama tamamen kullanışsız bir uygulama yapmanız gerekmedikçe yapmayın.

— dr. kötülük
kaynak
9
Kullanıcı bilgilerini ve çevreyi koruyan büyük bir uygulama içindir. Birisi farklı sekmelerde farklı kullanıcılarla, test için veya farklı roller için giriş yaptığında, sekmelerden bilgileri geçer.
— Oriol Terradas
38
eski cevap biliyorum, ancak google posta sekme başına farklı hesaplara sahip olmanızı sağlar ve "tamamen kullanılamaz bir uygulama" değildir
— George
2
@George, Cevap hala doğru ve url numaranızda göreceğiniz örnek için çerezlerde saklanan hesapların dizinini temsil ediyor, google posta sadece tüm çerezleri saklıyor ve url'ye göre birini seçiyor.
— Mhmd
5
Cevabın hala doğru olduğundan emin değilsiniz, açıkça yapabilirsiniz. Gmail bunu yapar. Nasıl yaptıklarına gelince, zarif olmayabilir ama işe yarıyor ve önemli olan bu
— George
2
Eski yanıt, ancak Whatsapp ve Telegram'ın aynı anda iki sekme açmanıza izin vermediğini ekleyebilirim. Bu onları kullanılamaz yapmaz
— Charlie
13

Küçük bir ek yükü olan, ancak bir prototip olarak çalışıyor gibi görünen yeni bir çözüm buldum. Varsayımlardan biri, oturum açmak için bir onur sistemi ortamında olduğunuzdur, ancak sekmeler arasında geçiş yaptığınızda bir parola yeniden talep ederek uyarlanabilir.

Yeni bir tarayıcı sekmesinin hangi kullanıcının etkin olduğunu değiştirdiğini tespit etmek için localStorage (veya eşdeğeri) ve HTML5 depolama olayını kullanın. Bu durumda, geçerli pencereyi kullanamayacağınızı (veya pencereyi geçici olarak devre dışı bırakamadığınızı belirten bir mesajla birlikte bir hayalet yer paylaşımı oluşturun.) Pencere yeniden odaklandığında, bir AJAX istek günlüğü gönderin kullanıcı geri.

Bu yaklaşıma bir uyarı: normal AJAX çağrılarınız olamaz (yani, oturumunuza bağlı olanlar), odağı olmayan bir pencerede gerçekleşir (örneğin, bir gecikmeden sonra bir çağrı olduysanız) bundan önce manuel olarak bir AJAX yeniden giriş çağrısı yaparsınız. Gerçekten yapmanız gereken tek şey, AJAX işlevinizin önce localStorage.currently_oked_in_user_id === window.yourAppNameSpace.user_id adresinden emin olmak ve ilk önce AJAX üzerinden giriş yapmaktır.

Bir diğeri yarış koşulları: eğer pencereleri karıştırmak için yeterince hızlı değiştirebilirseniz, alox1 yanlış oturum altında yapılmış bir relogin1-> relogin2-> ajax1-> ajax2 dizisiyle karşılaşabilirsiniz. Oturum açma AJAX isteklerini bir diziye aktararak ve ardından yeni bir oturum açma isteği göndermeden önce mevcut tüm istekleri iptal edin.

Dikkat edilmesi gereken son şey, pencere yenilemeleri. Etkin bir AJAX giriş isteğiniz varken biri pencereyi yeniler, ancak tamamlanmamışsa, yanlış kişi adına yenilenir. Bu durumda, kullanıcıyı potansiyel karışıklık konusunda uyarmak ve standart dışı bir ön yükleme olayını kullanarak bir AJAX oturum açma isteğini yeniden göndererek İptal'i tıklatmasını isteyebilirsiniz. Daha sonra, bunu tamamlayabilmelerinin tek yolu, istek tamamlanmadan önce Tamam'ı tıklamaktır (veya yanlışlıkla enter / boşluk çubuğuna vurmaktır, çünkü Tamam - maalesef bu durumda - varsayılan.) Bu durumu ele almanın başka yolları da var, çoğu durumda çalışacak ancak kullanıcı klavye kısayolunun yeniden yapılandırılması veya alternatif işletim sistemi kullanımı ile engellenebilecek F5 ve Ctrl + R / Alt + R tuşlarının algılanması. Ancak, bu gerçekte biraz önemli bir durumdur, ve en kötü durum senaryoları asla o kadar kötü değildir: bir onur sistemi yapılandırmasında yanlış kişi olarak giriş yapmış olursunuz (ancak sayfaları renkler, stiller, belirgin şekilde görüntülenen adlarla kişiselleştirerek durumun bu olduğunu açıkça belirtebilirsiniz, vb.); bir şifre yapılandırmasında, oturumu kapatmış veya oturumlarını paylaşmış olmak için şifrelerini girmiş olan son kişi üzerindedir veya bu kişi gerçekte geçerli kullanıcıysa, ihlal yoktur.

Ancak sonunda, profiller kurmak zorunda kalmadan IE kullanmak veya URL'leri yeniden yazmak zorunda kalmadan (umarız) olması gerektiği gibi davranan sekme başına bir kullanıcı uygulamanız vardır. Yine de, söz konusu sekmede oturum açmış olan her sekmede açıkça belirttiğinizden emin olun ...

— Kev
kaynak
6
+1 çünkü bunu gerçekten düşünmek için zaman ayırdınız! :-) Sadece kötü bir fikir olduğunu bildiğiniz tüm uyarılara bakmak. Bu şeylerden çıkarılan derslerim, hangi verilerin oturumlara girmesi gerektiğini ve hangi verilerin olmaması gerektiğini gerçekten anlamaktır.
— Peter
10

Bu sorunu yaşadık ve çok kolay çözdük. Kolay demek istiyorum çünkü hiçbir programlama söz konusu değil. Yapmak istediğimiz, bir kullanıcının oturumlarla çakışmadan aynı tarayıcı penceresinde birden fazla hesaba giriş yapmasına izin vermekti.

Böylece çözüm rastgele alt alanlardı.

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

Bu yüzden sistem yöneticimizden * .abc.com yerine abc.com için SSL sertifikalarını yapılandırmasını istedik. Daha sonra küçük bir kod değişikliği ile, her kullanıcı giriş yapmaya çalıştığında, rastgele bir alt alan numarası ile bir sekmede oturum açar. böylece her sekmenin bağımsız olarak kendi oturumu olabilir. Ayrıca, herhangi bir çakışmayı önlemek için, rasgele sayıyı bir karma veya md5 kullanıcı kimliği kullanarak geliştirdik.

— user3534653
kaynak
3
Bu, URL yeniden yazmanın akıllıca bir alternatifi gibi görünüyor. Görünen ancak rahatsız edici olmayan bir HTTP uyumlu yerde istenen değişken (oturum kimliği) ile sonuçlanırsınız. Akla gelen nits: 1) DNS üzerinde joker karakter gerekir, açıkçası, 2) tüm web siteniz, kullanıcıyı (")" alt alan adına geri yönlendirecek mutlak URL'lerden kaçınmalıdır, 3) büyük olasılıkla web tarayıcılarını uzak tutmak ister , ancak bu muhtemelen özel bir web durumudur, bu zaten yapılabilir. Bunu paylaştığın için teşekkürler!
— Ron Burk
@ user3534653: Yaklaşımı seviyorum. Ama dediniz ki, "programlama yok". Sonra "küçük kod değişikliği ile" söylemeye devam edin. Gerçekten, küçük bir kod değişikliği programlama değil mi? ;) Ayrıca, etki alanının sabit olarak kodlandığı / yapılandırıldığı (standart olarak) standart bağlantılara sahip birden çok uygulamanız varsa, bu yaklaşım çalışmayabilir.
— Stefan Steiger
5

Burada dürüst olacağım. . . Her şey üstünde veya gerçek olabilir veya olmayabilir, ama hepsi görünüyor YOL sekmesi kullanılan sunucu tarafı ediliyor bilerek adres çok karmaşık, ya da değildir.

Bazen Occam'ın tıraş makinesini uygulamamız gerekir.

İşte Occam'ın yaklaşımı: (hayır, ben Occam değilim, 1347'de öldü)

1) yüklendiğinde sayfanıza bir tarayıcı benzersiz kimliği atayın. . . yalnızca pencerenin henüz bir kimliği yoksa (bu nedenle bir önek ve algılama kullanın)

2) sahip olduğunuz her sayfada (genel bir dosya veya başka bir şey kullanın) odaklama olayını ve / veya fareyle üzerine gelme olayını algılamak için kodu yerleştirmeniz yeterlidir. (Kod yazma kolaylığı için bu bölüm için jquery kullanacağım)

3) odak (ve / veya fareyle üzerine gelme) işlevinizde, window.name içinde bir çerez ayarlayın

4) sekmeye özgü verileri okumanız / yazmanız gerektiğinde bu çerez değerini sunucu tarafından okuyun.

Müşteri tarafı:

//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;
}

sunucu tarafı (C # - örneğin amaçlar) 

//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];

Bitti.

— Mike A.
kaynak
1
Basitleştirilmiş cevabınızı ve Occam'ın jilet referansını gerçekten seviyorum. Bu çözümün sizin için hala çalışıp çalışmadığını bir kez daha kontrol etmek istedim.
— Jeff Marino
1
Sayfanın yenilenmesinin oturumunu sürdürmesi gerektiğinde bu yaklaşımın işe yaramayacağını fark etmek gerekir. Window.sessionStorage kullanmanın başka bir cevabında önerilen diğer yaklaşım benim için daha makul görünüyor.
— rosenfeld
@quijibo Hala benim uygulama mükemmel çalışıyor, evet. Sayfayı yenilemeye gelince, bazı tarayıcılar için doğru olabilir, window.sessionStorage kullanarak sorunu çözebilir, denemedim
— Mike A.
3
"Se_appframe ()" işlevi nedir?
— AndreMiranda
Nedir se_appframe ?
— Kiquenet
2

Tek bir sayfadan başlarken tüm URL'lerinize benzersiz bir tanımlayıcı eklemek için bağlantı yeniden yazma özelliğini kullanabilirsiniz (ör. İndex.html / jsp / whatever). Eğer çerezleri koymak her şey böylece tarayıcınız tüm sekmeler için aynı çerezleri kullanır değil benzersiz olması.

— top şeker
kaynak
2
Oturumları kodlamak için bağlantıları yeniden yazmak sıkıcı ve hataya açık bir şey olduğunu düşünüyorum. Çok fazla bağlantıya sahip büyük bir uygulamam var, şeffaf bir çözüme ihtiyacım var veya uygulanması kolay.
— Oriol Terradas
2

Muhtemelen istediğiniz sekmeler arasında gezinme durumunu korumak ve özellikle sekme başına tek bir oturum oluşturmak değil. Bu, Seam çerçevesinin Konuşma kapsamı / bağlamıyla tam olarak başardığı şeydir. Uygulamaları, her istekle bir konuşma kimliğinin yayıldığı gerçeğine dayanır ve sunucu tarafında bir konuşma kavramı yaratır; bu, bir oturum ile bir istek arasında bulunan bir şeydir. Navigasyon akış kontrolü ve durum yönetimine izin verir.

Bu esas olarak JSF'yi hedeflemesine rağmen, bunun bazı fikirler alabileceğiniz bir şey olup olmadığını kontrol edin: http://docs.jboss.org/seam/latest/reference/en-US/html_single/#d0e3620

— lsoliveira
kaynak
1

Çalışan başka bir yaklaşım, benzersiz bir pencere kimliği oluşturmak ve bu değeri oturum kimliği ile birlikte bir veritabanı tablosunda depolamaktır. Sık kullandığım pencere kimliği tam sayı (şimdi). Bu değer, bir pencere açıldığında ve pencere yenilenir, yeniden yüklenir veya kendisine gönderilirse aynı pencereye yeniden atandığında oluşturulur. Pencere değerleri (girişler) bağlantı kullanılarak yerel tabloya kaydedilir. Bir değer gerekli olduğunda, pencere kimliği / oturum kimliği bağlantısına dayalı olarak veritabanı tablosundan alınır. Bu yaklaşım yerel bir veritabanı gerektirse de, neredeyse kusursuzdur. Bir veritabanı tablosunun kullanımı benim için kolaydı, ancak yerel dizilerin de işe yaramamasının bir nedeni göremiyorum.

— Stephen
kaynak
1

Not: Buradaki çözümün uygulama tasarımı aşamasında yapılması gerekir. Bunu daha sonra yapmak zor olurdu.

Oturum tanımlayıcıyı dolaşmak için gizli bir alan kullanın .

Bunun çalışması için her sayfanın bir form içermesi gerekir:

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

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

</form>

Gezinme dahil olmak üzere, tarafınızdaki her işlem formu geri gönderir ( actionuygun şekilde ayarlanır ). İçin "güvenli olmayan" istekleri, başka bir parametre içerebilir, verinin JSON değeri sunulacak içeren ki:

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

Çerez olmadığından, her sekme bağımsız olacak ve aynı tarayıcıdaki diğer oturumlar hakkında bilgi sahibi olmayacaktır.

Özellikle güvenlik söz konusu olduğunda birçok avantaj:

  • JavaScript veya HTML5'e güvenilmez.
  • Doğası gereği karşı korur CSRF'e .
  • Çerezlere güvenilmez, bu yüzden POODLE'a karşı korur .
  • Oturum sabitlemesine karşı savunmasız değil .
  • Kullanıcıların sitenizde belirli bir yolu izlemelerini istediğinizde istenen geri düğmesi kullanımını engelleyebilir (bu, bazen sipariş dışı istekler tarafından saldırıya uğrayabilen mantık hatalarının önlenebileceği anlamına gelir).

Bazı dezavantajları:

  • Geri düğmesi işlevselliği istenebilir.
  • Her eylem bir POST olduğu için önbelleklemede çok etkili değildir.

Daha fazla bilgi burada .

— SilverlightFox
kaynak
1

Bunu şu şekilde çözdüm:

  • Pencereye bir ad verdim, bu ad bağlantı kaynağı ile aynı.
  • artı 1 eklemek bağlantı için çerez saklanan kurtulmak için.
  • Tüm xmloutput yanıtı yakalamak ve sid ve kurtulmak için çerez json formatında atamak için bir işlev oluşturdum. Bunu her window.name için yapıyorum.

İşte kod:

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);
    }

Umarım sana yardım eder

— Almanca Sanchez
kaynak
0

Bu yazıyı okudum çünkü aynı şeyi yapmak istediğimi düşündüm. Üzerinde çalıştığım bir uygulama için de benzer bir durum var. Ve gerçekten pratiklikten daha fazlasını test etme meselesi.

Bu cevapları, özellikle Michael Borgwardt'ın verdiği cevabı okuduktan sonra, var olması gereken iş akışını fark ettim:

  1. Kullanıcı giriş ekranına giderse mevcut bir oturumu kontrol edin. Varsa, giriş ekranını atlayın ve karşılama ekranına gönderin.
  2. Kullanıcı (benim durumumda) kayıt ekranına giderse, mevcut bir oturumu kontrol edin. Varsa, kullanıcıya bu oturumu kapatacağınızı bildirin. Kabul ederlerse, çıkış yapın ve kayda başlayın.

Bu, kullanıcının oturumlarında "başka bir kullanıcının" verilerini görmesi sorununu çözecektir. Oturumlarında gerçekten "başka bir kullanıcının" verilerini görmüyorlar, açtıkları tek oturumdaki verileri gerçekten görüyorlar. Açıkçası bu, bazı işlemler bazı oturum verilerinin üzerine yazarken diğerlerinin değil bazı oturum verilerinin üzerine yazıldığından, bu tek oturumda bir veri kombinasyonuna sahip olmanızdır.

Şimdi, test sorununu ele almak için. Geçerli tek yaklaşım Önişlemci Direktiflerini kullanmak olacaktır. oturumların kullanılıp kullanılmayacağını belirlemek için kullanmak olacaktır. Gördüğünüz gibi, belirli bir ortam için belirli bir yapılandırma oluşturarak, ortam ve ne için kullanıldığına dair bazı varsayımlar yapabilirim. Bu, teknik olarak aynı anda iki kullanıcının oturum açmamı sağlar ve test cihazı, bu sunucu oturumlarından herhangi birini kapatmadan aynı tarayıcı oturumundan birden fazla senaryoyu test edebilir.

Bununla birlikte, bu yaklaşımın bazı ciddi uyarıları vardır. En azından, test edicinin test ettiği şey, üretimde çalışacak olan şey değildir .

Sanırım söylemeliyim ki, bu sonuçta kötü bir fikir.

— Mike Perrenoud
kaynak
0

Daha önce ayarlanmamışsa timeStamp'ın window.sessionStorage içinde saklanması. Bu, her sekme için benzersiz bir değer verecektir (URL'ler aynı olsa bile)

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

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

Bu yardımcı olur umarım.

— misafir
kaynak
1
Bu muhtemelen iyidir, ancak teorik olarak güvensizdir. Bazı işletim sistemleri (örn. Windows) çok kaba bir zaman damgası ayrıntısına sahiptir, bu da zaman damgasını birden çok kez arayabileceğiniz ve aynı değeri geri alabileceğiniz anlamına gelir. Ayrıca, bir kilitlenmeden sonra bir tarayıcıyı yeniden açar ve aynı sekmeyi aynı anda alabilecekleri anda tüm sekmeleri yeniden açar.
— Gili
0 
How to differ sessions in browser-tabs?

Tarayıcı sekmelerinde oturumları farklılaştırmanın en kolay yolu, çerezleri ayarlamak için belirli alan adınıza izin vermemektir. Bu şekilde, ayrı sekmelerden ayrı oturumlarınız olabilir. Bu alan adından çerezlere izin vermediğinizi varsayalım: www.xyz.com. Sekme 1'i açın, giriş yapın ve göz atmaya başlayın. Ardından Sekme 2'yi açarsınız ve aynı kullanıcı veya farklı bir kullanıcı olarak giriş yapabilirsiniz; her iki durumda da, Sekme 1'den ayrı bir oturumunuz olacaktır.

Ancak elbette bu, müşteri tarafı üzerinde kontrolünüz olduğunda mümkündür. Aksi takdirde, burada insanlar tarafından öngörülen çözümler uygulanmalıdır.

— Kingz
kaynak
0

yapmanız gerekecek

1- Hesaplar listesi için bir çerez saklayın

2- İsteğe bağlı olarak varsayılan çerez için bir çerez saklayın

3- acc1, acc2 gibi dizinli her hesap için mağaza

4- url koymak bir şey hesapların dizin temsil eder ve eğer değilse google mail domain.com gibi varsayılan bir varsayılan seçecektir.com/some-url >> 0 burada hesap dizinini temsil de nasıl bilmeniz gerekebilir urlwrite kullan

5- bir çerez seçtiğinizde, urlpath'inize göre hesap dizinini temsil eden bir çerez seçin

Saygılarımızla

— mhmd
kaynak
0

Oturum kimliği çerezlerini işlemek için istemci tarafı değişiklikleri olan birçok uygulama görüyorum. Ancak genel oturum kimliği çerezleri HttpOnly olmalıdır, bu nedenle java komut dosyası erişemez, aksi takdirde XSS aracılığıyla Oturum Hijackine yol açabilir

— vasa.v03
kaynak
0

Her sekmenin uygulamanızda farklı bir akış yürütmesi ve her iki akışın karıştırılması sorunlara neden oluyorsa, oturum nesnelerinizi "Bölgeselleştirmek", böylece her akış oturumun farklı bir bölgesini kullanır

Bu bölge, her akış için farklı öneklere sahip olarak uygulanabilir veya oturum nesnesi birden çok haritaya sahip olur (her akış için bir tane) ve oturum öznitelikleri yerine bu haritaları kullanırsınız, en iyisi oturum sınıfınızı genişletmek ve bunun yerine kullanın.

— hussein.g
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.