谷歌浏览器跨域ie不跨域_单一登录或如何跨域在浏览器中共享数据

谷歌浏览器跨域ie不跨域

Every modern browser offers mechanisms to store data that can be retrieved when opening a new window or a new tab. The different storage options are cookies, local storage, and session storage. The problem is that these storage options are segmented per domain (or subdomain). That means that xyz.com will not be allowed to access any of the information that abc.com has set. And browsers don’t provide any options to share data across domains, for obvious security and data privacy reasons.

每种现代的浏览器都提供了存储可以在打开新窗口或新选项卡时检索的数据的机制。 不同的存储选项是cookie，本地存储和会话存储。 问题在于这些存储选项是按域(或子域)分段的。 这意味着xyz.com将不允许访问abc.com设置的任何信息。 而且出于明显的安全性和数据隐私性原因，浏览器不提供任何跨域共享数据的选项。

At Bloom Partners, we build digital solutions that drive long-term consumer engagement through content delivery. This often requires our users to use several web apps, that connect to the same authentication API. Those web-apps may not use the same framework, as the purpose of the app drives what platform it is based on.

在Bloom Partners，我们建立了数字解决方案，通过内容交付来推动长期的消费者参与。 这通常要求我们的用户使用多个连接到相同身份验证API的Web应用程序。 这些Web应用程序可能不会使用相同的框架，因为该应用程序的目的是驱动该应用程序所基于的平台。

Considering that a secure API only allows a few active authentication tokens, if your user needs to use more apps than the number of available tokens allowed by the API, he will not be able to stay logged in all the apps he needs to use. Therefore he will need to go through the authentication process multiple times a day.

考虑到安全的API仅允许使用几个活动的身份验证令牌，如果您的用户需要使用的应用数量超过了API允许的可用令牌数量，则他将无法保持登录所需的所有应用程序的身份。 因此，他将需要每天多次进行身份验证过程。

The article is a step by step guide on a solution we built at Bloom Partners to answer this problem in a secure, framework-agnostic manner, using Webpack and Typescript only.

本文是在Bloom Partners上构建的解决方案的分步指南，该解决方案仅使用Webpack和Typescript以安全的，与框架无关的方式回答了此问题。

解决方案概述 (Overview of the solution)

The main idea is to have a domain that all your applications can share. In order to do that, you will develop a JavaScript snippet, that will spawn an iframe on the page. The domain of this iframe will be the one used to share data across your different web apps.

主要思想是拥有一个所有应用程序都可以共享的域。 为此，您将开发一个JavaScript代码段，该代码段将在页面上生成一个iframe。 此iframe的域将是用来在您不同的Web应用程序之间共享数据的域。

The previously mentioned snippet will also register a few methods (set, retrieve, delete) on the window object, adding a layer between the iframe and your application to streamline the communication between them.

前面提到的代码段还将在window对象上注册一些方法(设置，检索，删除)，从而在iframe和您的应用程序之间添加了一层，以简化它们之间的通信。

The compiled result will be composed of

编译结果将由

• A “snippet.js” script, registering the iframe on the index.html, and providing the methods to the window object. The methods provided to the window object should return promises, that will be resolved or rejected when the snippet receives specific events from the iframe.
  “ snippet.js”脚本，将iframe注册在index.html上，并将方法提供给window对象。 提供给window对象的方法应返回承诺，当代码段从iframe接收特定事件时，这些承诺将被解决或拒绝。
• An index.html, that will import its script: “iframe.js”. This script will listen to the events coming from the snippet and send events in response.
  一个index.html，它将导入其脚本：“ iframe.js”。 该脚本将侦听来自摘要的事件，并发送事件作为响应。

The communication between the script and the iframe will be done through the window.postMessage interface.

脚本和iframe之间的通信将通过window.postMessage接口完成。

As a good picture is worth a thousand words, here is a time diagram showing the path of an application requesting an authentication token to the sign in script:

由于一张好的图片总值一千个单词，因此以下是一个时序图，显示了向登录脚本请求身份验证令牌的应用程序的路径：

Time diagram showing the communication between a frontend application, the single sign application and the API

时序图，显示前端应用程序，单点登录应用程序和API之间的通信