ブラウザタブでセッションを区別するにはどうすればよいですか？

135

JSPとサーブレットを使用してJavaで実装されたWebアプリケーション。ユーザーセッションに情報を保存すると、この情報は同じブラウザのすべてのタブから共有されます。ブラウザタブでセッションを区別するにはどうすればよいですか？この例では：

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

このコードをjspページにコピーし（testpage.jsp）、このファイルをサーバー上のWebアプリケーションの既存のコンテキストにデプロイし（私はApache Tomcatを使用）、正しいURLを使用してブラウザー（FF、IE7またはOpera）を開きます（localhost/context1/testpage.jsp）、タイプ入力であなたの名前を入力し、フォームを送信します。次に、同じブラウザーで新しいタブを開くと、新しいタブに自分の名前（セッションから取得）が表示されます。ブラウザーのキャッシュに注意してください。時々発生しないように見えますが、キャッシュにあるため、2番目のタブを更新してください。

ありがとう。

jsp  servlets  browser  web-applications  sessionid 
— オリオール・テラダス
ソース
— Bozho
1
これは、ユーザーがしなければならないことです。IEを開き、[ファイル]
— Stefan Steiger
3
@Quandary、あなたのソリューションは一般的なソリューションではなく（他のブラウザでは機能しません）、最も重要なのは、ユーザーフレンドリーではありません（ユーザーはセッションについて知らない）。
— Oriol Terradas、2011年
2
これの目的が何であるか想像できない人もいるようです。問題のドメインは、Webサイトのさまざまな「ビュー」を許可したいほとんどすべての状況です。ユーザーがWebサイトの複数のビューを持つことができると、必然的に2つの異なるビューに同時にアクセスするのに時間がかかります（または誤って試行します）。例には次のものがあります。サンドボックス化（他の人がまだ確認できないWebサイトに変更を加える）; 役割ベースのビュー（権限の低いユーザーに対してWebサイトがどのように見えるかを参照）。など
— Ron Burk

回答:

92

HTML5 SessionStorage（window.sessionStorage）を使用できます。ランダムなIDを生成し、ブラウザータブごとにセッションストレージに保存します。次に、各ブラウザタブには独自のIDがあります。

sessionStorageを使用して保存されたデータは、2つのタブの両方に同じドメインからのWebページが含まれている場合でも、ブラウザーのタブ間で保持されません。つまり、sessionStorage内のデータは、呼び出しページのドメインとディレクトリだけでなく、ページが含まれているブラウザのタブにも限定されます。これを、タブ間でデータを保持するセッションCookieと比較してください。

— ゴンザロ・ガロッティ
ソース
7
ドキュメントから：「2つのタブの両方に同じドメインオリジンからのWebページが含まれている場合でも、sessionStorageを使用して保存されたデータはブラウザのタブ間で保持されません。つまり、sessionStorage内のデータは、呼び出しページのドメインとディレクトリだけでなく、ページが含まれているブラウザのタブ。タブ間でデータを保持するセッションCookieとは対照的です。」簡単なテストでは、ChromeとFFでこの動作が確認されています。
— jswanson 2013
21
Chromeの「タブの複製」機能を使用すると、IDが複製されることに注意してください。これは一般的に問題ではありませんが、十分に検討する必要があります。
— JosiahDaniels
ChromeまたはFirefoxでタブを「複製」する場合を除きます。この場合、SessionStorageがコピーされます。
— Tiago Freitas Leal
@ゴンザロ・ガロッティ：セッションがサーバー側の場合、それはどのように役立ちますか？）））
— Stefan Steiger
@StefanSteiger。次に、Ajax呼び出しでBrowserTab ID（セッションストレージに保存）を送信できます。サーバー側では、WebSessionが同じであるため、カスタムロジックが必要になります。ただし、Sessionオブジェクトを含むHashMapをタブごとに作成できます。
— ゴンザロガロッティ
23

サーバー側セッションはHTTPの人工的なアドオンであることを理解する必要があります。HTTPはステートレスであるため、サーバーは、要求が、知っている特定のユーザーに属し、セッションを持っていることを何らかの方法で認識する必要があります。これを行うには2つの方法があります。

  • クッキー。よりクリーンでより一般的な方法ですが、1人のユーザーによるすべてのブラウザのタブとウィンドウがセッションを共有することを意味します-IMOこれは実際に望ましいです。新しいタブごとにログインするサイトで私は非常にイライラします。タブを非常に集中的に使用する
  • URLの書き換え。サイト上のURLには、セッションIDが追加されています。これはより手間がかかりますが（サイト内部リンクがある場所ならどこでも何かを行う必要があります）、リンクを介して開いたタブは引き続きセッションを共有しますが、異なるタブで別々のセッションを作成できます。また、ユーザーがサイトにアクセスするときは、常にログインする必要があります。

とにかく何をしようとしていますか？タブに個別のセッションを持たせたいのはなぜですか？セッションをまったく使用せずに目標を達成する方法はありますか？

編集： テストのために、別のVMで複数のブラウザーインスタンスを実行するなど、他のソリューションを見つけることができます。1人のユーザーが同時に異なる役割で行動する必要がある場合は、「役割」の概念をアプリで処理して、1つのログインが複数の役割を持つことができるようにする必要があります。Cookieベースのセッションでブラウザのタブを個別に処理することは単純に不可能であるため、URLの書き換えを使用するか、現在の状況で生活するだけでよいかを判断する必要があります。

— マイケル・ボルグワート
ソース
6
これは、ユーザー情報と環境を保持する大きなアプリケーション用です。誰かが別のタブで別のユーザーを使ってログインしたり、テストや別の役割のためにログインしたりすると、タブからの情報にまたがっています。
— Oriol Terradas 2008
その理由については、非常に遅いアドオンです。たとえば、自分のサイトのどのページかを知るためにこれを知る必要があるため、たとえば、ユーザーがページからページに移動しただけでなく、ユーザーが集中しているためです（代わりにタブからタブに移動しました）。
— オリバーウィリアムズ
16

window.name JavaScriptプロパティは、タブアクティビティ全体で持続する唯一のものですが、（URLガフの代わりに）独立したままにできます。

— デイブ・ビッシュ
ソース
3
window.sessionStorageも同様に機能します
— felickz '19 / 02/19
3
ユーザーが「新しいタブで開く」を選択すると、セッションストレージが新しいタブにコピーされるので注意してください。詳細へのリンクが欲しいのですが、次を参照してください：bugzilla.mozilla.org/show_bug.cgi
— id
2
window.name設定に保存した内容は、ユーザーが同じタブ内の他のページに移動したときに、他のドメインでも引き続き使用できることに注意してください。
— nakib 2013
15

すべきではない。そのようなことをしたい場合は、その場でURLを書き込むことにより、ユーザーにアプリケーションの単一のインスタンスを使用するように強制する必要があります。同様に、sessionIDを使用し（sessionidは機能しません）、すべてのURLに渡します。

なぜそれが必要なのかはわかりませんが、完全に使用できないアプリケーションを作成する必要がない限り、それを行わないでください。

— 博士。悪の
ソース
9
これは、ユーザー情報と環境を保持する大きなアプリケーション用です。誰かが別のタブで別のユーザーを使ってログインしたり、テストや別の役割のためにログインしたりすると、タブからの情報にまたがっています。
— Oriol Terradas 2008
38
古い回答ですが、Googleメールではタブごとに異なるアカウントを使用でき、「まったく使用できないアプリケーション」ではありません
— George
2
@George、正解です。たとえば、URL番号に表示される例では、Cookieに保存されているアカウントのインデックスが表示されます。Googleのメールでは、すべてのCookieが保存され、URLに応じて1つ選択されます。
— Mhmd 2014年
5
答えがまだ正しいかわからない、あなたは明らかにそれを行うことができます。Gmailはそれを行います。それがどのように行われるかについては、エレガントではないかもしれませんが、機能し、それが重要です
— George
2
古い答えですが、Wh​​atsappとTelegramでは2つのタブを同時に開くことはできません。これはそれらを使用不可にしません
— チャーリー
13

新しいソリューションを思いついたので、オーバーヘッドはわずかですが、これまでのところプロトタイプとして機能しているようです。タブを切り替えるたびにパスワードを再要求することでこれを適応させることができますが、1つの仮定は、ログインのための名誉あるシステム環境にいることです。

localStorage（または同等のもの）とHTML5ストレージイベントを使用して、新しいブラウザータブがアクティブなユーザーを切り替えたことを検出します。その場合は、現在のウィンドウを使用できないことを示すメッセージでゴーストオーバーレイを作成します（または、一時的にウィンドウを無効にすると、このウィンドウを目立たせたくない場合があります）。ウィンドウが再びフォーカスを取得したら、AJAXリクエストログを送信します。ユーザーが戻ってきました。

このアプローチの1つの注意点：通常のAJAX呼び出し（つまり、セッションに依存する呼び出し）は、フォーカスのないウィンドウ（たとえば、遅延後に呼び出しが発生した場合）では発生しません。その前に手動でAJAX再ログイン呼び出しを行います。したがって、実際に必要なことは、AJAX関数を最初にチェックしてlocalStorage.currently_logged_in_user_id === window.yourAppNameSpace.user_idを確認し、そうでない場合は最初にAJAX経由でログインすることです。

もう1つは競合状態です。ウィンドウを十分に速く切り替えて混乱させると、relogin1-> relogin2-> ajax1-> ajax2シーケンスになり、ajax1が間違ったセッションで作成される可能性があります。これを回避するには、ログインAJAXリクエストをアレイにプッシュしてからストレージに格納し、新しいログインリクエストを発行する前に、現在のすべてのリクエストを中止します。

注意すべき最後の問題は、ウィンドウの更新です。AJAXログインリクエストがアクティブであるが完了していないときに誰かがウィンドウを更新すると、間違った人の名前でウィンドウが更新されます。この場合、非標準のbeforeunloadイベントを使用して、潜在的な混同についてユーザーに警告し、AJAXログイン要求を再発行している間にキャンセルをクリックするようにユーザーに要求できます。次に、リクエストが完了する前に[OK]をクリックする（または、OKは-この場合は残念ながらデフォルト-であるため、誤ってEnterキーまたはスペースバーを押す）ことで、ユーザーはそれを妨害できます。このケースを処理する方法は他にもあります。 F5およびCtrl + R / Alt + Rの押下を検出します。これはほとんどの場合に機能しますが、ユーザーのキーボードショートカットの再構成または代替のOSの使用によって妨害される可能性があります。しかし、これは実際には少しエッジケースです。最悪のシナリオは決して悪くありません。名誉あるシステム構成では、間違った人物としてログインします（ただし、色、スタイル、目立つように表示される名前でページをパーソナライズすることで、これが事実であることを明確にすることができます。等。）; パスワード設定では、ログアウトまたはセッションを共有するためにパスワードを最後に入力した人に責任があります。または、この人が実際に現在のユーザーである場合、違反はありません。

しかし、最終的には、タブを1ユーザー1人で使用できるアプリケーションがあり、（うまくいけば）必ずしもプロファイルを設定したり、IEを使用したり、URLを書き換えたりする必要はありません。ただし、特定のタブにログインしている各タブでそれを明確にしてください...

— ケヴ
ソース
6
本当にこれをじっくりと考えるのに時間がかかったので、+ 1してください！:-)すべての警告を見ると、それが悪いアイデアであることがわかります。このことから学んだ教訓は、どのデータをセッションに入れるか、どのデータを入れないかを真に理解することです。
— Peter
10

私たちはこの問題を抱えていて、それを非常に簡単に解決しました。プログラミングが必要ないので簡単です。私たちがやりたかったのは、セッションを競合させることなく、ユーザーが同じブラウザウィンドウ内の複数のアカウントにログインできるようにすることでした。

したがって、解決策はランダムなサブドメインでした。

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

そこで、システム管理者にabc.comではなく* .abc.comのSSL証明書を構成するように依頼しました。コードを少し変更するだけで、ユーザーがログインしようとするたびに、ランダムなサブドメイン番号のタブにログインします。そのため、各タブは独自に独自のセッションを持つことができます。また、競合を回避するために、ユーザーIDのハッシュまたはmd5を使用して乱数を開発しました。

— user3534653
ソース
3
これは、URL書き換えの賢い代替手段のようです。表示されていても邪魔にならないHTTP準拠の場所で、目的の変数（セッションID）を取得します。頭に浮かぶニット：1）DNSにワイルドカードが必要、明らかに、2）Webサイト全体が、ユーザーを「www」サブドメインに戻す絶対URLを回避する必要がある、3）おそらくWebクローラーを除外したい、しかしこれはおそらくプライベートウェブの状況なので、すでに行われている可能性があります。これを共有してくれてありがとう！
— Ron Burk 2016年
@ user3534653：私はこのアプローチが好きです。しかし、「プログラミングは必要ありません」とあなたは言った。次に、「コードをほとんど変更せずに」と言います。だから本当に、少しのコード変更はプログラミングではありませんか？;）また、ドメインがハードコード/構成されている（正規）正規リンクを持つ複数のアプリケーションがある場合、このアプローチは機能しない可能性があります。
— Stefan Steiger
5

ここで正直になります。。。すべて上記のは本当かであってもなくてもよいが、それはすべてのようだWAYを複雑すぎる、またはアドレス]タブを使用したサーバー側されているものを知っていません。

Occamのかみそりを適用する必要がある場合があります。

Occamのアプローチは次のとおりです。（いいえ、私はOccamではありません。彼は1347年に亡くなりました）。

1）ロード時にページにブラウザー固有のIDを割り当てます。。。ウィンドウにまだIDがない場合（そのため、プレフィックスと検出を使用します）

2）（グローバルファイルなどを使用して）すべてのページにコードを配置するだけで、フォーカスイベントやマウスオーバーイベントを検出できます。（コードの記述を簡単にするために、この部分にはjqueryを使用します）

3）フォーカス（またはマウスオーバー）関数で、window.nameを含むCookieを設定します

4）タブ固有のデータの読み取り/書き込みが必要な場合は、サーバー側からそのCookie値を読み取ります。

クライアント側：

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

サーバー側（C＃-例） 

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

できました。

— マイク・A
ソース
1
私はあなたの簡単な答えとOccamのかみそりの参照が本当に好きです。このソリューションがまだ機能していることを再確認したいだけです。
— ジェフ・マリノ
1
ページを更新してもセッションを維持する必要がある場合、このアプローチは機能しないことに注意してください。window.sessionStorageを使用する別の回答で提案されている他のアプローチは、私にはより合理的に思えます。
— ローゼンフェルド2014
@quijiboはまだ私のアプリケーションで完全に動作します、はい。ページの更新については、一部のブラウザではtrueである可能性があります。window.sessionStorageを使用すると問題が解決する可能性がありますが、試していない場合があります
— Mike A.
3
関数「se_appframe（）」とは何ですか？
— AndreMiranda 2016年
se_appframeとは何ですか？
— Kiquenet
2

リンク書き換えを使用して、単一のページ（たとえば、index.html / jsp / whatever）から開始するときに、すべてのURLに一意の識別子を追加できます。ブラウザはすべてのタブに同じCookieを使用するため、Cookieに入力するすべてが一意になるわけではありません。

— ボンベ
ソース
2
セッションをエンコードするためにリンクを書き直すのは退屈でエラーが発生しやすいと思います。私は大きなアプリケーションを持っていますが、多くのリンクがあり、透過的なソリューションまたは実装が簡単なものが必要です。
— Oriol Terradas 2008
2

おそらく、タブごとにナビゲーション状態を維持し、タブごとに1つのセッションを作成するのではなく、これはまさにSeamフレームワークが彼らのConversationスコープ/コンテキストで達成するものです。それらの実装は、会話IDが各要求と共に伝播され、サーバー側での会話の概念を作成するという事実に依存しています。これは、セッションと要求の間にあるものです。ナビゲーションフロー制御と状態管理を可能にします。

それは主にJSFを目的としていますが、それがあなたがいくつかのアイデアを得ることができる何かであるかどうかを見て、チェックしてください：http : //docs.jboss.org/seam/latest/reference/en-US/html_single/#d0e3620

— lsoliveira
ソース
1

機能する別のアプローチは、一意のウィンドウIDを作成し、この値をセッションIDとともにデータベーステーブルに格納することです。私がよく使用するウィンドウIDは整数（現在）です。この値は、ウィンドウが開かれたときに作成され、ウィンドウが更新、再ロード、または自分自身に送信された場合に、同じウィンドウに再割り当てされます。ウィンドウの値（入力）は、リンクを使用してローカルテーブルに保存されます。値が必要な場合は、ウィンドウID /セッションIDリンクに基づいてデータベーステーブルから取得されます。このアプローチはローカルデータベースを必要としますが、事実上簡単です。データベーステーブルを使用するのは簡単でしたが、ローカル配列がうまく機能しない理由はわかりません。

— スティーブン
ソース
1

注：ここでのソリューションは、アプリケーションの設計段階で実行する必要があります。これを後で設計するのは難しいでしょう。

非表示フィールドを使用してセッション識別子を渡す。

これが機能するには、各ページにフォームが含まれている必要があります。

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

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

</form>

ナビゲーションを含むすべてのアクションはフォームをPOSTします（action必要に応じてを設定）。「安全でない」リクエスト、あなたは別のパラメータを含めることができ、提出するデータのJSON値を含む言います：

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

Cookieがないため、各タブは独立しており、同じブラウザの他のセッションを認識しません。

特にセキュリティに関しては、多くの利点があります。

  • JavaScriptやHTML5に依存しません。
  • 本質的にCSRFから保護します。
  • Cookieに依存しないため、POODLEから保護します。
  • セッションの固定に対して脆弱ではありません。
  • 戻るボタンの使用を防ぐことができます。これは、ユーザーにサイト内の設定されたパスをたどるときに望ましいです（つまり、順序の乱れた要求によって攻撃される可能性のあるロジックバグを防ぐことができます）。

いくつかの欠点：

  • 戻るボタン機能が必要な場合があります。
  • すべてのアクションがPOSTであるため、キャッシングではあまり効果的ではありません。

詳細はこちら。

— SilverlightFox
ソース
1

私はこれを次の方法で解決しました：

  • ウィンドウに名前を割り当てました。この名前は接続リソースと同じです。
  • アタッチ接続のためにcookieに保存されているプラ​​ス1。
  • すべてのxmloutput応答をキャプチャし、sidとridをjson形式でcookieに割り当てる関数を作成しました。これをwindow.nameごとに行います。

ここにコード：

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

私はあなたを助けたいと思います

— ドイツのサンチェス
ソース
0

同じことをしたいと思ったので、この投稿を読んでいます。私が取り組んでいるアプリケーションについても同様の状況があります。そして実際、それは実用性以上のテストの問題です。

これらの回答、特にMichael Borgwardtからの回答を読んだ後、私は存在する必要のあるワークフローに気づきました。

  1. ユーザーがログイン画面に移動した場合は、既存のセッションを確認してください。存在する場合は、ログイン画面をバイパスして、ようこそ画面に送信します。
  2. ユーザー（私の場合）が登録画面に移動する場合は、既存のセッションを確認します。セッションが存在する場合は、そのセッションからログアウトすることをユーザーに知らせます。同意した場合は、ログアウトして登録を開始します。

これにより、ユーザーのセッションで「別のユーザー」のデータが表示される問題が解決されます。彼らは実際に自分のセッションで「別のユーザー」のデータを見ているのではなく、開いている唯一のセッションからのデータを実際に見ています。一部の操作が一部のセッションデータを上書きし、他のセッションデータを上書きしないため、この1つのセッションでデータの組み合わせが存在するため、これは明らかに興味深いデータの原因になります。

次に、テストの問題に対処します。実行可能な唯一のアプローチは、プリプロセッサディレクティブを活用することです。、Cookieのないセッションを使用する必要があるかどうかを判断することです。特定の環境に特定の構成を組み込むことで、環境とその用途についていくつかの仮定を立てることができます。これにより、技術的には2人のユーザーが同時にログインでき、テスターはそれらのサーバーセッションからログアウトせずに、同じブラウザーセッションから複数のシナリオをテストできます。

ただし、このアプローチにはいくつかの重大な注意事項があります。特に重要なのは、テスターがテストしているのが本番環境で実行されるものではないという事実です。

だから私は言わざるを得ないと思います、これは最終的に悪い考えです。

— マイク・ペレヌッド
ソース
0

まだ設定されていない場合は、timeStampをwindow.sessionStorageに格納します。これにより、各タブに一意の値が与えられます（URLが同じであっても）

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

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

お役に立てれば。

— ゲスト
ソース
1
これはおそらく大丈夫ですが、理論的には安全ではありません。一部のオペレーティングシステム（Windowsなど）のタイムスタンプの粒度は非常に粗いため、タイムスタンプを複数回検索して同じ値を返す可能性があります。さらに、クラッシュ後にブラウザを再び開いて、一度にすべてのタブを再度開いた場合、同じタイムスタンプが取得される可能性があります。
— Gili
0 
How to differ sessions in browser-tabs?

ブラウザのタブでセッションを変える最も簡単な方法は、特定のドメインがCookieを設定できないようにすることです。そうすることで、別々のタブから別々のセッションを持つことができます。このドメイン（www.xyz.com）からのCookieを禁止するとします。タブ1を開いてログインし、閲覧を開始します。次に、タブ2を開き、同じユーザーまたは別のユーザーとしてログインできます。どちらの場合も、タブ1とは別のセッションになります。

しかしもちろん、これはクライアント側を制御できる場合に可能です。そうでなければ、ここで人々によって規定された解決策が適用されるべきです。

— キングズ
ソース
0

あなたがする必要があります

1-アカウントリストのCookieを保存する

2-オプションで、デフォルトのCookieを保存します

3-アカウントごとに、acc1、acc2のようなインデックスを持つストア

4-何かをアカウントのインデックスを表すURLに入れます。そうでない場合は、google mail domain.com/0/some-urlのようなデフォルトのものを選択します>> 0ここでアカウントのインデックスを表します。また、方法を知る必要があるかもしれません。 urlwriteを使用する

5- Cookieを選択するとき、URLパスに応じて選択し、アカウントインデックスを表します

よろしく

— Mhmd
ソース
0

セッションIDのCookieを操作するためにクライアント側に変更を加えた実装がたくさんあります。ただし、一般にセッションIDのCookieはHttpOnlyである必要があるため、JavaScriptがアクセスできないため、XSSを介したセッションハイジャックにつながる可能性があります。

— vasa.v03
ソース
0

各タブがアプリケーションで異なるフローを実行するためであり、両方のフローを混合すると問題が発生する場合は、セッションオブジェクトを「リージョン化」して、各フローがセッションの異なる領域を使用するようにすることをお勧めします。

このリージョンは、フローごとに異なるプレフィックスを持つように簡単に実装できます。または、セッションオブジェクトが複数のマップ（フローごとに1つ）を保持し、セッション属性の代わりにそれらのマップを使用します。ただし、セッションクラスを拡張し、代わりに使用してください。

— hussein.g
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.