好，经过多次不同的迭代后，与：

变量

• 有两种数据存储：
  
  
  
  • IndexedDB 所有标签。
  
  
  • sessionStorage 每个标签唯一。
  
  


• 我们存储以下变量：
  
  
  
  • IndexedDB包含 publicToken ， nextTabId 。
  
  
  • sessionStorage包含 privateToken ， tabId 。
  
  

publicToken，privateToken

• 查看http://***.com/a/1592572/14731 了解身份验证令牌的定义。


• 有两种身份验证


• publicToken 是上次登录操作在所有标签页中返回的令牌。


• privateToken 是当前选项卡上次登录操作返回的令牌。

tabId

• 每个标签都由 tabId 。


• nextTabId 是可在所有标签之间访问的号码。


• 如果某个标签没有ID，它会根据 nextTabId 创建一个新的标签，并增加其值。


• code> tabId 可能具有值com.company.Tab X ，其中 X 是 nextTabId 返回的数字。

登录/

• 每次一个标签登录时， privateToken 和


• 当用户注销时，我们删除 privateToken 和 publicToken 在浏览器端， privateToken 。我们不会在服务器端删除 publicToken 。


• 这意味着任何时候一个标签注销， code> privateToken 也会注销。


• 多个标签何时共享相同的 privateToken ？当您在新窗口或标签中打开链接时，它会继承父标签的 privateToken 。


• 如果我们删除 publicToken 在服务器上，使用 privateToken X， publicToken Y会导致 privateToken Y的选项卡被注销（这是不可取的）。

b $ b

网页载入时

• 扫描网页中的HTML连结。


• 每个链接，将 tabId 查询参数附加到URL。参数值等于 tabId 的值。


• 取消 tabId URL参数从当前页使用 history.replaceState（） ，以便用户可以与他们的朋友分享链接（ tabId 是用户特定的，无法共享）。


• tabId cookie（以下详述）。

• 该标签创建一个 tabId cookie，并跟随该链接。


• Cookie的名称等于 tabId 的值，并且值等于 privateToken

当服务器收到请求时

• 如果缺少 tabId 参数，请将浏览器重定向到 GetTabId.html？referer = X X 是当前URL。


• 如果 tabId 令牌无效或过期，然后将浏览器重定向到登录屏幕。

GetTabId.html

• 如果选项卡没有 privateToken ，请复制 publicToken privateToken 和。 privateToken


• 该网页需要一个名为 referer 的网址参数 c> c> $ 参数重定向以从浏览器历史记录中删除 GetTabId.html 时使用.replace（）。

我们为什么继续删除/添加Cookie？

• 我们尽量减少发送的Cookie数量


• 如果我们在网页加载时未删除 tabId Cookie，则每次制作标签时

已知问题

• 查看源代码打开缺少 tabId 的URL。因此，它获取重定向到 GetTabId.html 而不是实际页面的页面的源代码。


• 尴尬长页面重新加载（客户端重定向到 GetTabId.html 并返回原始页面）。

对长期实施细节深表歉意，但我找不到更简单/更短的解决方案。

I'm trying to implement an authentication mechanism where each browser tab may be logged in as a different user.

Here are the rules of this system:

• An authentication token indicates which user is logged in.
• There are 2 kinds of authentication tokens: private and public.
• Each private token is bound to a single tab and determines its account information.
• The public token may be read/written to by any tab and indicates the last account that was logged into (across all tabs).
• When a user logs out in any tab, both the private and public tokens are removed.
• Each time a tab hits a page that requires authentication, the system tries reading the private token. If it is not set (as in the case of a new/blank tab), it tries copying the value of the public token into the private token. If the public token is not set then the user is redirected to an authentication screen.
• When a tab is already logged in and a user clicks on a link, the request must include the private token in a custom HTTP header. Sending this information in the URI is not an option, for security reasons.
• Ability to navigate using the back/forward button the same as you would for normal links (meaning, no prompts to re-submit form data).

What I've tried so far:

• Using cookies for both the private and public tokens: this doesn't work because the server has no way of knowing which cookie to look in. If a user clicks on a link from inside a tab, the request sends all cookies across all tabs and the server has no way of knowing which one clicked on the link.

• Storing private tokens in sessionStorage: This doesn't work because when a user clicks on a link, there is no way to specify custom headers that should be sent alongside the HTTP GET request.

• Requesting the page using AJAX, then navigating to the page in memory using Data URIs: For security reasons, Internet Explorer doesn't allow the use of DATA URIs for HTML content. See http://msdn.microsoft.com/en-us/library/cc848897%28v=vs.85%29.aspx

• Using <form method="get" enctype="multipart/form-data"> and passing the token using hidden fields: enctype="multipart/form-data" is only supported for POST.

• Using <form method="post" enctype="multipart/form-data"> and passing the token using hidden fields: in theory, this should work but now the user gets prompted to re-submit form data if he uses the back/forward button.

• Requesting the page using AJAX, then rewriting the current page using document.open(); document.write(); document.close(). I tried both http://***.com/a/4404659/14731 and http://forums.mozillazine.org/viewtopic.php?p=5767285&sid=d6a5a2e8e311598cdbad124e277e0f52#p5767285 and in both cases the scripts in the new <head> block never gets executed.

Any ideas?

Okay, after going through many different iterations, here is the implementation we ended up with:

Variables

• There are two kind of data stores:
  • IndexedDB, which is shared across all tabs.
  • sessionStorage which is unique per tab.
• We store the following variables:
  • IndexedDB contains publicToken, nextTabId.
  • sessionStorage contains privateToken, tabId.

publicToken, privateToken

• See http://***.com/a/1592572/14731 for a definition of an authentication token.
• There are two kinds of authentication tokens: public and private.
• publicToken is the token returned by the last login operation, across all tabs.
• privateToken is the token returned by the last login operation of the current tab.

tabId

• Each tab is uniquely identified by a token called tabId.
• nextTabId is a number that is accessible across all tabs.
• If a tab does not have an id, it creates a new one based on nextTabId and increments its value.
• For example, tabId could have a value of "com.company.TabX" where X is the number returned by nextTabId.

Login/Logout

• Every time a tab logs in, privateToken and publicToken are overwritten using the authentication token returned by the server.
• When a user logs out, we delete privateToken and publicToken on the browser side, and privateToken on the server side. We do not delete publicToken on the server side.
• This means that anytime a tab logs out, all all tabs sharing the same privateToken will get logged out as well. Any tabs using a different token will be unaffected.
• When do multiple tabs share the same privateToken? When you open a link in a new window or tab, it inherits the privateToken of the parent tab.
• If we were to delete publicToken on the server, a tab logging out with privateToken X, publicToken Y would cause tabs with privateToken Y to get logged out (which is undesirable).

On page load

• Scan the page for HTML links.
• For each link, append a tabId query parameter to the URL. The parameter value is equal to the value of tabId.
• Strip the tabId URL parameter from the current page using history.replaceState() so users can share links with their friends (tabId is user-specific and cannot be shared).
• Delete the tabId cookie (more on this below).

When a link is clicked

• The tab creates a tabId cookie and follows the link.
• The cookie has a name equal to the value of tabId and a value equal to the value of privateToken

When a server receives a request

• If the tabId parameter is missing, then redirect the browser to GetTabId.html?referer=X where X is the current URL.
• If tabId is present but the authentication token is invalid or expired, then redirect the browser to the login screen.

GetTabId.html

• If the tab does not have a privateToken, copy publicToken into privateToken.
• If both privateToken and publicToken are undefined, redirect to the login page.
• The page takes a URL parameter called referer which indicates where to redirect to on success.
• If the tab has a privateToken, append the tabId parameter to the referer page and redirect back to it.
• Use window.location.replace() when redirecting to remove GetTabId.html from the browser history.

Why do we keep on deleting/adding cookies?

• We try to minimize the number of cookies sent to the server on each request.
• If we did not delete the tabId cookie on page load, then each time a tab would make a request all of the other tabs' cookies would get sent as well.

Known issues

• "View Source" opens the URL missing tabId. As result, it gets the source-code of the page which redirects to GetTabId.html instead of the actual page.
• Awkwardly long page reloads (client is redirected to GetTabId.html and back to the original page).

Apologies for the long implementation details, but I could not find an easier/shorter solution.