Làm cách nào để khác nhau các phiên trong tab trình duyệt?

135

Trong một ứng dụng web được triển khai trong java bằng cách sử dụng JSP và Servlets; nếu tôi lưu trữ thông tin trong phiên người dùng, thông tin này được chia sẻ từ tất cả các tab từ cùng một trình duyệt. Làm cách nào để khác nhau các phiên trong tab trình duyệt? Trong ví dụ này:

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

Sao chép mã này trong trang jsp ( testpage.jsp), triển khai tệp này trong ngữ cảnh hiện có của ứng dụng web trên máy chủ (Tôi sử dụng Apache Tomcat), sau đó mở trình duyệt (FF, IE7 hoặc Opera) bằng cách sử dụng URL ( localhost/context1/testpage.jsp) chính xác tên của bạn trong đầu vào và gửi mẫu. Sau đó mở một tab mới trong cùng một trình duyệt và sau đó bạn có thể thấy tên của mình (lấy từ phiên) trên tab mới. Hãy cẩn thận với bộ đệm của trình duyệt, đôi khi dường như điều đó không xảy ra, nhưng trong bộ đệm, hãy làm mới tab thứ hai.

Cảm ơn.

jsp  servlets  browser  web-applications  sessionid 
— Thổ Nhĩ Kỳ
nguồn
— Mạnh
1
Đây là việc người dùng phải làm: Mở IE, nhấp vào "Tệp-> Phiên mới"
— Stefan Steiger
3
@Quandary, giải pháp của bạn không phải là giải pháp chung chung (trong các trình duyệt khác không hoạt động) và quan trọng nhất là nó không thân thiện với người dùng (người dùng không biết về phiên).
— Oriol Terradas
2
Một số người dường như không thể tưởng tượng mục đích của việc này là gì. Miền vấn đề là hầu hết mọi tình huống mà bạn muốn cho phép các "lượt xem" khác nhau của trang web của mình. Khi người dùng có thể có nhiều lượt xem trang web của bạn, họ chắc chắn sẽ lâu (hoặc vô tình thử) để truy cập hai chế độ xem khác nhau cùng một lúc. Các ví dụ bao gồm: phiên bản tạm thời (chuyển sang xem trang web khi nó tồn tại ở một thời điểm nhất định trong quá khứ); sandboxing (thay đổi trang web mà người khác không thể nhìn thấy); lượt xem dựa trên vai trò (xem trang web trông như thế nào đối với người dùng ít đặc quyền hơn); vv
— Ron Burk

Câu trả lời:

92

Bạn có thể sử dụng HTML5 SessionStorage (window.sessionStorage). Bạn sẽ tạo một id ngẫu nhiên và lưu trong phiên Lưu trữ trên mỗi Tab Trình duyệt. Sau đó, mỗi tab trình duyệt có Id riêng của mình.

Dữ liệu được lưu trữ bằng sessionStorage không tồn tại trên các tab của trình duyệt, ngay cả khi cả hai tab đều chứa các trang web từ cùng một nguồn gốc tên miền. Nói cách khác, dữ liệu bên trong sessionStorage không chỉ giới hạn tên miền và thư mục của trang gọi mà còn cả tab trình duyệt chứa trang. Tương phản với cookie phiên, dữ liệu vẫn tồn tại từ tab này sang tab khác.

— Gonzalo Gallotti
nguồn
7
Từ tài liệu: "Dữ liệu được lưu trữ bằng sessionStorage không tồn tại trên các tab trình duyệt, ngay cả khi cả hai tab đều chứa các trang web từ cùng một nguồn gốc. Nói cách khác, dữ liệu bên trong sessionStorage không chỉ giới hạn tên miền và thư mục của trang gọi, mà là tab trình duyệt chứa trang được chứa. Tương phản với cookie phiên, dữ liệu vẫn tồn tại từ tab này sang tab khác. " Thử nghiệm đơn giản xác nhận hành vi này trong Chrome và FF.
— jswanson
21
Lưu ý, ID sẽ được sao chép khi sử dụng tính năng "Tab trùng lặp" của Chrome. Điều này thường không phải là một vấn đề, nhưng nên suy nghĩ kỹ.
— JosiahDaniels 21/07/2015
Ngoại trừ khi bạn "Sao y" một tab trong Chrome hoặc Firefox. Trong trường hợp này, SessionStorage được sao chép.
— Tiago Freitas Leal
@Gonzalo Gallotti: Và điều đó sẽ giúp tôi như thế nào nếu phiên ở phía máy chủ? )))
— Stefan Steiger
@StefanSteiger. Sau đó, bạn có thể gửi id BrowserTab (được lưu trong Bộ lưu trữ phiên) với Cuộc gọi Ajax của bạn. Ở phía máy chủ, bạn sẽ cần logic tùy chỉnh, vì WebSession giống nhau. Nhưng bạn có thể tạo HashMap với các đối tượng Phiên theo tab.
— Gonzalo Gallotti
23

Bạn phải nhận ra rằng các phiên phía máy chủ là một tiện ích bổ sung nhân tạo cho HTTP. Vì HTTP không trạng thái, máy chủ cần bằng cách nào đó nhận ra rằng một yêu cầu thuộc về một người dùng cụ thể mà nó biết và có phiên. Có 2 cách để làm điều này:

  • Bánh quy. Phương pháp sạch hơn và phổ biến hơn, nhưng điều đó có nghĩa là tất cả các tab và cửa sổ trình duyệt của một người dùng chia sẻ phiên - IMO thực tế là mong muốn và tôi sẽ rất khó chịu tại một trang web khiến tôi đăng nhập cho mỗi tab mới, vì tôi sử dụng các tab rất chuyên sâu
  • Viết lại URL. Bất kỳ URL nào trên trang web đều có ID phiên được gắn vào nó. Đây là công việc nhiều hơn (bạn phải làm một cái gì đó ở mọi nơi bạn có liên kết nội bộ trang web), nhưng có thể có các phiên riêng biệt trong các tab khác nhau, mặc dù các tab được mở thông qua liên kết vẫn sẽ chia sẻ phiên. Nó cũng có nghĩa là người dùng luôn phải đăng nhập khi anh ta đến trang web của bạn.

Bạn đang cố gắng làm gì? Tại sao bạn muốn các tab có phiên riêng biệt? Có lẽ có một cách để đạt được mục tiêu của bạn mà không cần sử dụng phiên nào cả?

Chỉnh sửa: Để kiểm tra, các giải pháp khác có thể được tìm thấy (chẳng hạn như chạy một số phiên bản trình duyệt trên các máy ảo riêng biệt). Nếu một người dùng cần thực hiện các vai trò khác nhau cùng một lúc, thì khái niệm "vai trò" sẽ được xử lý trong ứng dụng để một lần đăng nhập có thể có một số vai trò. Bạn sẽ phải quyết định xem việc này, sử dụng viết lại URL hay chỉ sống với tình huống hiện tại có thể được chấp nhận hơn, vì đơn giản là không thể xử lý các tab trình duyệt riêng biệt với các phiên dựa trên cookie.

— Michael Borgwardt
nguồn
6
Đó là một ứng dụng lớn lưu giữ thông tin người dùng và môi trường. Khi ai đó đăng nhập với người dùng khác nhau trong các tab khác nhau, để kiểm tra hoặc cho các vai trò khác nhau, thì anh ta sẽ chuyển thông tin từ các tab.
— Oriol Terradas
Chỉ là một tiện ích bổ sung rất muộn, tại sao: vì tôi cần biết điều này để biết trang WHICH trên trang web của tôi, ví dụ, một người dùng tập trung vào, và không chỉ là họ đã đi từ trang này sang trang khác ( thay vào đó họ đi từ tab này sang tab khác).
— Oliver Williams
16

Thuộc tính Javascript của window.name, là thứ duy nhất tồn tại trên toàn bộ hoạt động của tab, nhưng vẫn có thể độc lập (thay vì URL guff).

— Dave Bish
nguồn
3
window.sessionStorage cũng vậy
— felickz
3
cẩn thận vì lưu trữ phiên được sao chép vào một tab mới khi người dùng chọn "mở trong tab mới" ... ước gì tôi có liên kết để biết chi tiết nhưng xem: bugzilla.mozilla.org/show_orms.cgi?id=818389
— felickz
2
Xin lưu ý rằng thứ bạn lưu trong cài đặt window.name vẫn sẽ có sẵn trong các tên miền khác, khi người dùng thay đổi sang các trang khác trong cùng một tab.
— nakib
15

Bạn không nên. Nếu bạn muốn làm một việc như vậy, bạn cần buộc người dùng sử dụng một phiên bản ứng dụng duy nhất của mình bằng cách viết URL khi đang sử dụng id phiên IDID (không phải phiên làm việc nó sẽ không hoạt động) và chuyển nó trong mỗi URL.

Tôi không biết tại sao bạn cần nó nhưng trừ khi bạn cần tạo một ứng dụng hoàn toàn không sử dụng được thì đừng làm điều đó.

— dr. tà ác
nguồn
9
Đó là một ứng dụng lớn lưu giữ thông tin người dùng và môi trường. Khi ai đó đăng nhập với người dùng khác nhau trong các tab khác nhau, để kiểm tra hoặc cho các vai trò khác nhau, thì anh ta sẽ chuyển thông tin từ các tab.
— Oriol Terradas
38
Tôi biết câu trả lời cũ, nhưng google mail cho phép bạn có các tài khoản khác nhau trên mỗi tab và đó không phải là "ứng dụng hoàn toàn không sử dụng được"
— George
2
@George, Câu trả lời vẫn đúng và ví dụ của bạn, bạn sẽ thấy trong số url đại diện cho chỉ mục các tài khoản được lưu trữ trong cookie, google mail chỉ lưu trữ tất cả cookie và chọn một theo url.
— Mhmd
5
Không chắc câu trả lời vẫn đúng, bạn rõ ràng có thể làm được. Gmail làm điều đó. Về cách thức hoạt động, nó có thể không thanh lịch nhưng nó hoạt động và đó là điều quan trọng
— George
2
Câu trả lời cũ nhưng tôi có thể thêm rằng Whatsapp và Telegram không cho phép bạn mở hai tab cùng một lúc. Điều này không làm cho chúng không sử dụng được
— Charlie
13

Tôi đã đưa ra một giải pháp mới, có một chút chi phí nhỏ, nhưng dường như đang hoạt động như một nguyên mẫu. Một giả định là bạn đang ở trong môi trường hệ thống danh dự để đăng nhập, mặc dù điều này có thể được điều chỉnh bằng cách lấy lại mật khẩu bất cứ khi nào bạn chuyển tab.

Sử dụng localStorage (hoặc tương đương) và sự kiện lưu trữ HTML5 để phát hiện khi tab trình duyệt mới đã chuyển đổi người dùng nào đang hoạt động. Khi điều đó xảy ra, hãy tạo lớp phủ ma với thông báo cho biết bạn không thể sử dụng cửa sổ hiện tại (hoặc tạm thời tắt cửa sổ, bạn có thể không muốn nó dễ thấy như vậy.) Khi cửa sổ lấy lại tiêu điểm, hãy gửi nhật ký yêu cầu AJAX người dùng quay lại

Một lưu ý cho cách tiếp cận này: bạn không thể có bất kỳ cuộc gọi AJAX bình thường nào (nghĩa là các cuộc gọi phụ thuộc vào phiên của bạn) xảy ra trong một cửa sổ không có tiêu điểm (ví dụ: nếu bạn có một cuộc gọi xảy ra sau khi trì hoãn), trừ khi bạn thực hiện thủ công cuộc gọi đăng nhập lại AJAX trước đó. Vì vậy, thực sự tất cả những gì bạn cần làm là kiểm tra chức năng AJAX của bạn trước để đảm bảo localStorage.c hiệnly_logged_in_user_id === window.yourAppNameSpace.user_id và nếu không, hãy đăng nhập trước qua AJAX.

Một điều kiện khác là điều kiện chủng tộc: nếu bạn có thể chuyển đổi các cửa sổ đủ nhanh để gây nhầm lẫn, bạn có thể kết thúc bằng một chuỗi relogin1-> relogin2-> ajax1-> ajax2, với ajax1 được thực hiện dưới phiên sai. Giải quyết vấn đề này bằng cách đẩy các yêu cầu AJAX đăng nhập vào một mảng, sau đó lưu trữ và trước khi đưa ra yêu cầu đăng nhập mới, hủy bỏ tất cả các yêu cầu hiện tại.

Gotcha cuối cùng cần chú ý là làm mới cửa sổ. Nếu ai đó làm mới cửa sổ trong khi bạn đã kích hoạt yêu cầu đăng nhập AJAX nhưng chưa hoàn thành, nó sẽ được làm mới bằng tên của người sai. Trong trường hợp này, bạn có thể sử dụng sự kiện tải trước không chuẩn để cảnh báo người dùng về hỗn hợp tiềm năng và yêu cầu họ nhấp vào Hủy, trong khi phát lại yêu cầu đăng nhập AJAX. Sau đó, cách duy nhất họ có thể làm hỏng nó là bằng cách nhấp vào OK trước khi yêu cầu hoàn thành (hoặc bằng cách vô tình nhấn enter / spacebar, vì OK là - không may cho trường hợp này - mặc định.) Có nhiều cách khác để xử lý trường hợp này, như phát hiện các lần nhấn F5 và Ctrl + R / Alt + R, sẽ hoạt động trong hầu hết các trường hợp nhưng có thể bị cản trở bởi cấu hình lại phím tắt người dùng hoặc sử dụng hệ điều hành thay thế. Tuy nhiên, đây là một chút trường hợp cạnh trong thực tế, và các trường hợp xấu nhất không bao giờ tệ đến thế: trong cấu hình hệ thống danh dự, bạn đã đăng nhập sai người (nhưng bạn có thể thấy rõ rằng đây là trường hợp bằng cách cá nhân hóa các trang với màu sắc, kiểu dáng, tên hiển thị nổi bật, Vân vân.); trong cấu hình mật khẩu, trách nhiệm thuộc về người cuối cùng đã nhập mật khẩu của họ để đăng xuất hoặc chia sẻ phiên của họ hoặc nếu người này thực sự là người dùng hiện tại, thì không có vi phạm.

Nhưng cuối cùng, bạn có một ứng dụng một người dùng trên mỗi tab (hy vọng) chỉ hoạt động như bình thường, mà không nhất thiết phải thiết lập hồ sơ, sử dụng IE hoặc viết lại URL. Hãy chắc chắn rằng bạn làm cho nó rõ ràng trong mỗi tab được đăng nhập vào tab cụ thể đó, mặc dù ...

— Kev
nguồn
6
+1 vì bạn đã dành thời gian để thực sự nghĩ về điều này! :-) Nhìn vào tất cả các cảnh báo bạn chỉ biết đó là một ý tưởng tồi. Bài học của tôi rút ra từ công cụ này là thực sự hiểu dữ liệu nào nên đi vào phiên và dữ liệu nào không nên.
— Peter
10

Chúng tôi đã có vấn đề này và chúng tôi đã giải quyết nó rất dễ dàng. Ý tôi là dễ dàng vì không có lập trình liên quan. Điều chúng tôi muốn làm là cho phép người dùng đăng nhập vào nhiều tài khoản trong cùng một cửa sổ trình duyệt mà không xung đột các phiên.

Vì vậy, giải pháp là tên miền phụ ngẫu nhiên.

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

Vì vậy, chúng tôi đã yêu cầu quản trị viên hệ thống của chúng tôi định cấu hình chứng chỉ SSL cho * .abc.com thay vì abc.com Sau đó, với một chút thay đổi mã, mỗi khi người dùng cố gắng đăng nhập, anh ta sẽ đăng nhập vào một tab với số tên miền phụ ngẫu nhiên. vì vậy mỗi tab có thể có phiên riêng của nó một cách độc lập. Ngoài ra, để tránh mọi xung đột, chúng tôi đã phát triển số ngẫu nhiên bằng cách sử dụng hàm băm hoặc md5 của id người dùng.

— người dùng3534653
nguồn
3
Điều này có vẻ như là một thay thế thông minh để viết lại URL. Bạn kết thúc với biến mong muốn (ID phiên) ở một nơi phù hợp với HTTP có thể nhìn thấy nhưng không gây khó chịu. Rõ ràng là cần phải có: 1) cần ký tự đại diện trên DNS, rõ ràng, 2) toàn bộ trang web của bạn phải tránh mọi URL tuyệt đối sẽ chuyển người dùng trở lại (ví dụ) tên miền phụ "www", 3) có thể muốn ngăn chặn trình thu thập dữ liệu web , nhưng đây có lẽ là một tình huống web riêng tư để có thể được thực hiện. Cảm ơn đã chia sẻ điều này!
— Ron Burk
@ user3534653: Tôi thích cách tiếp cận. Nhưng bạn nói "không liên quan đến lập trình". Sau đó, bạn tiếp tục nói "với ít thay đổi mã". Vì vậy, thực sự, một chút thay đổi mã không phải là lập trình? ;) Ngoài ra, cách tiếp cận này có thể không hoạt động nếu bạn có nhiều ứng dụng có liên kết chính tắc trong đó tên miền được mã hóa / cấu hình cứng (theo quy tắc).
— Stefan Steiger
5

Tôi sẽ thành thật ở đây. . . mọi thứ ở trên có thể đúng hoặc không đúng, nhưng tất cả có vẻ CÁCH quá phức tạp hoặc không biết địa chỉ nào đang được sử dụng phía máy chủ.

Đôi khi chúng ta cần áp dụng dao cạo của Occam.

Đây là cách tiếp cận của Occam: (không, tôi không phải Occam, anh ấy đã chết năm 1347)

1) chỉ định một id duy nhất của trình duyệt cho trang của bạn khi tải. . . nếu và chỉ khi cửa sổ chưa có id (vì vậy hãy sử dụng tiền tố và phát hiện)

2) trên mỗi trang bạn có (sử dụng tệp toàn cầu hoặc nội dung nào đó) chỉ cần đặt mã vào vị trí để phát hiện sự kiện trọng tâm và / hoặc sự kiện di chuột. (Tôi sẽ sử dụng jquery cho phần này, để dễ viết mã)

3) trong chức năng tập trung (và / hoặc di chuột) của bạn, đặt cookie với window.name trong đó

4) đọc giá trị cookie đó từ phía máy chủ của bạn khi bạn cần đọc / ghi dữ liệu cụ thể của tab.

Phía khách hàng:

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

phía máy chủ (C # - ví dụ mục đích) 

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

Làm xong.

— Mike A.
nguồn
1
Tôi thực sự thích câu trả lời đơn giản của bạn và tài liệu tham khảo dao cạo của Occam. Chỉ muốn kiểm tra lại xem giải pháp này có còn hiệu quả với bạn không.
— Jeff Marino
1
Điều đáng chú ý là nếu làm mới trang nên giữ phiên của nó thì phương pháp này sẽ không hiệu quả. Cách tiếp cận được đề xuất khác trong một câu trả lời khác về việc sử dụng window.sessionStorage có vẻ hợp lý hơn đối với tôi.
— rosenfeld
@quijibo Vẫn hoạt động hoàn hảo trong ứng dụng của tôi, vâng. Đối với việc làm mới trang, có thể đúng với một số trình duyệt, sử dụng window.sessionStorage có thể giải quyết vấn đề, chưa thử nó
— Mike A.
3
Hàm "se_appframe ()" là gì?
— AndreMiranda
Se_appframe là gì?
— Kiquenet
2

Bạn có thể sử dụng viết lại liên kết để nối thêm một mã định danh duy nhất cho tất cả các URL của bạn khi bắt đầu tại một trang duy nhất (ví dụ: index.html / jsp / sao cũng được). Trình duyệt sẽ sử dụng cùng một cookie cho tất cả các tab của bạn để mọi thứ bạn đặt vào cookie sẽ không phải là duy nhất.

— Bombe
nguồn
2
Tôi nghĩ rằng việc viết lại các liên kết để mã hóa các phiên là một công việc tẻ nhạt và dễ bị lỗi. Tôi có một ứng dụng lớn, với rất nhiều liên kết, tôi cần một giải pháp minh bạch hoặc dễ thực hiện.
— Oriol Terradas
2

Tôi nghĩ những gì bạn có thể muốn là duy trì trạng thái điều hướng trên các tab và không đặc biệt tạo một phiên duy nhất cho mỗi tab. Đây chính xác là những gì khung Seam đạt được với phạm vi / bối cảnh Hội thoại của họ. Việc triển khai của họ dựa trên thực tế là id cuộc hội thoại được truyền bá theo từng yêu cầu và tạo ra khái niệm về cuộc hội thoại ở phía máy chủ, đây là điều nằm giữa phiên và yêu cầu. Nó cho phép kiểm soát dòng điều hướng và quản lý nhà nước.

Mặc dù điều đó chủ yếu nhắm vào JSF, hãy xem và kiểm tra xem đó có phải là thứ mà bạn có thể lấy một số ý tưởng từ: http://docs.jboss.org/seam/latest/reference/en-US/html_single/#d0e3620

— lsoliveira
nguồn
1

Một cách tiếp cận khác hoạt động là tạo id cửa sổ duy nhất và lưu trữ giá trị này cùng với id phiên trong bảng cơ sở dữ liệu. Id cửa sổ tôi thường sử dụng là số nguyên (bây giờ). Giá trị này được tạo khi một cửa sổ được mở và gán lại cho cùng một cửa sổ nếu cửa sổ được làm mới, tải lại hoặc gửi cho chính nó. Giá trị cửa sổ (đầu vào) được lưu trong bảng cục bộ bằng liên kết. Khi một giá trị được yêu cầu, nó được lấy từ bảng cơ sở dữ liệu dựa trên liên kết id cửa sổ / id phiên. Trong khi phương pháp này đòi hỏi một cơ sở dữ liệu cục bộ, nó hầu như không thể đánh lừa được. Việc sử dụng bảng cơ sở dữ liệu rất dễ dàng đối với tôi, nhưng tôi thấy không có lý do nào khiến các mảng cục bộ không hoạt động tốt như vậy.

— Stephen
nguồn
1

Lưu ý: Giải pháp ở đây cần được thực hiện ở giai đoạn thiết kế ứng dụng. Nó sẽ là khó khăn để thiết kế này sau này.

Sử dụng một trường ẩn để vượt qua định danh phiên .

Để làm việc này, mỗi trang phải có một biểu mẫu:

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

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

</form>

Mọi hành động về phía bạn, bao gồm cả điều hướng, gửi lại biểu mẫu (đặt actiontùy chọn phù hợp). Đối với các yêu cầu "không an toàn" , bạn có thể bao gồm một tham số khác, giả sử có chứa giá trị JSON của dữ liệu được gửi:

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

Vì không có cookie, mỗi tab sẽ độc lập và sẽ không có kiến ​​thức về các phiên khác trong cùng một trình duyệt.

Rất nhiều lợi thế, đặc biệt là khi nói đến bảo mật:

  • Không phụ thuộc vào JavaScript hoặc HTML5.
  • Bảo vệ chống lại CSRF .
  • Không phụ thuộc vào cookie, vì vậy bảo vệ chống lại POODLE .
  • Không dễ bị sửa lỗi phiên .
  • Có thể ngăn việc sử dụng nút quay lại, điều này là mong muốn khi bạn muốn người dùng theo một đường dẫn được thiết lập thông qua trang web của bạn (có nghĩa là lỗi logic đôi khi có thể bị tấn công bởi các yêu cầu không theo thứ tự, có thể được ngăn chặn).

Một số nhược điểm:

  • Chức năng nút quay lại có thể được mong muốn.
  • Không hiệu quả lắm với bộ nhớ đệm vì mọi hành động đều là POST.

Thêm thông tin ở đây .

— SilverlightFox
nguồn
1

Tôi đã giải quyết điều này theo cách sau:

  • Tôi đã gán tên cho cửa sổ, tên này giống với tài nguyên kết nối.
  • cộng 1 để loại bỏ lưu trữ trong cookie để đính kèm kết nối.
  • Tôi đã tạo một chức năng để nắm bắt tất cả phản hồi xmloutput và gán sid và loại bỏ cookie ở định dạng json. Tôi làm điều này cho mỗi window.name.

đây là mã:

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

Tôi hy vọng giúp bạn

— Đức
nguồn
0

Tôi đã đọc bài viết này vì tôi nghĩ tôi muốn làm điều tương tự. Tôi có một tình huống tương tự cho một ứng dụng tôi đang làm việc. Và thực sự đó là vấn đề kiểm tra nhiều hơn là thực tế.

Sau khi đọc những câu trả lời này, đặc biệt là câu trả lời của Michael Borgwardt, tôi nhận ra dòng công việc cần tồn tại:

  1. Nếu người dùng điều hướng đến màn hình đăng nhập, hãy kiểm tra phiên hiện có. Nếu một tồn tại bỏ qua màn hình đăng nhập và gửi chúng đến màn hình chào mừng.
  2. Nếu người dùng (trong trường hợp của tôi) điều hướng đến màn hình đăng ký, hãy kiểm tra phiên hiện có. Nếu có, hãy cho người dùng biết bạn sẽ đăng xuất phiên đó. Nếu họ đồng ý, đăng xuất và bắt đầu đăng ký.

Điều này sẽ giải quyết vấn đề người dùng nhìn thấy dữ liệu "người dùng khác" trong phiên của họ. Họ không thực sự nhìn thấy dữ liệu "người dùng khác" trong phiên của họ, họ thực sự thấy dữ liệu từ phiên duy nhất họ đã mở. Rõ ràng điều này gây ra một số dữ liệu thú vị vì một số thao tác ghi đè lên một số dữ liệu phiên và không phải dữ liệu khác để bạn có sự kết hợp dữ liệu trong phiên duy nhất đó.

Bây giờ, để giải quyết vấn đề thử nghiệm. Cách tiếp cận khả thi duy nhất sẽ là tận dụng Chỉ thị tiền xử lý để xác định xem có nên sử dụng các phiên không có cookie hay không. Xem, bằng cách xây dựng một cấu hình cụ thể cho một môi trường cụ thể, tôi có thể đưa ra một số giả định về môi trường và những gì nó được sử dụng cho. Điều này sẽ cho phép tôi có hai người dùng đăng nhập cùng một lúc và người kiểm tra có thể kiểm tra nhiều kịch bản từ cùng một phiên trình duyệt mà không cần đăng xuất khỏi bất kỳ phiên máy chủ nào.

Tuy nhiên, cách tiếp cận này có một số cảnh báo nghiêm trọng. Không ít trong số đó là thực tế rằng những gì người kiểm tra đang thử nghiệm là không phải những gì sẽ chạy trong sản xuất.

Vì vậy, tôi nghĩ rằng tôi đã phải nói, đây cuối cùng là một ý tưởng tồi.

— Mike Perrenoud
nguồn
0

Lưu trữ timeStamp trong window.sessionStorage nếu nó chưa được đặt. Điều này sẽ cung cấp một giá trị duy nhất cho mỗi tab (ngay cả khi các URL giống nhau)

http://www.javascriptkit.com/javatutors/domst Storage.shtml

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

Hi vọng điêu nay co ich.

— khách mời
nguồn
1
Điều này có thể ổn, nhưng về mặt lý thuyết là không an toàn. Một số hệ điều hành (ví dụ Windows) có độ chi tiết dấu thời gian rất thô, có nghĩa là bạn có thể tra cứu dấu thời gian nhiều lần và lấy lại cùng một giá trị. Hơn nữa, nếu bạn mở lại một trình duyệt sau khi gặp sự cố và nó sẽ mở lại tất cả các tab cùng một lúc chúng có thể có cùng dấu thời gian.
— Gili
0 
How to differ sessions in browser-tabs?

Cách đơn giản nhất để các phiên khác nhau trong tab trình duyệt là không cho phép tên miền cụ thể của bạn đặt cookie. Bằng cách đó, bạn có thể có các phiên riêng biệt từ các tab riêng biệt. Giả sử bạn không cho phép cookie từ tên miền này: www.xyz.com. Bạn mở Tab 1, đăng nhập và bắt đầu duyệt. Sau đó, bạn mở Tab 2 và bạn có thể đăng nhập với cùng một người dùng hoặc một người dùng khác; dù bằng cách nào, bạn sẽ có một phiên tách biệt với Tab 1. Và cứ thế.

Nhưng tất nhiên điều này là có thể khi bạn có quyền kiểm soát phía khách hàng. Nếu không, các giải pháp theo quy định của những người ở đây nên áp dụng.

— Kingz
nguồn
0

bạn sẽ cần phải làm

1- lưu trữ cookie cho danh sách tài khoản

2- tùy chọn lưu trữ một cookie cho mặc định

3- lưu trữ cho mỗi tài khoản với chỉ mục như acc1, acc2

4- đặt trong url một cái gì đó đại diện cho chỉ mục của các tài khoản và nếu không, bạn sẽ chọn một mặc định như google mail domain.com / 0 / some-url >> 0 ở đây đại diện cho chỉ mục tài khoản, bạn cũng có thể cần biết cách sử dụng urlwrite

5- khi chọn cookie, hãy chọn nó theo urlpath của bạn đại diện cho chỉ mục tài khoản

Trân trọng

— Mhmd
nguồn
0

Tôi thấy nhiều triển khai có các thay đổi phía máy khách để thao tác cookie id phiên. Nhưng trong các cookie id phiên chung nên là HTTPOnly để java-script không thể truy cập nếu không nó có thể dẫn đến Phiên bản Hijack thông qua XSS

— vasa.v03
nguồn
0

Nếu đó là vì mỗi tab sẽ chạy một luồng khác nhau trong ứng dụng của bạn và việc trộn cả hai luồng gây ra sự cố, thì tốt hơn là "Khu vực hóa" các đối tượng phiên của bạn, để mỗi luồng sẽ sử dụng một vùng khác nhau của phiên

Vùng này có thể được triển khai đơn giản như có các tiền tố khác nhau cho mỗi luồng hoặc đối tượng phiên sẽ giữ nhiều bản đồ (một cho mỗi luồng) và bạn sử dụng các bản đồ đó thay vì các thuộc tính phiên, tốt nhất là mở rộng lớp phiên của bạn và sử dụng nó thay thế

— hussein.g
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.