api网关 会话安全_关于会话存储API的鲜为人知的事情

api网关 会话安全

Explaining a scenario where session storage gets copied over from one tab to another

说明会话存储从一个选项卡复制到另一个选项卡的方案

背景： (Background:)

In this modern era of web-app development, the need for storage on client-side has increased and there are many types of storages available on client-side now with session storage being one of them. The session storage is best suitable for cases where data should only be confined to the tab that the app is running. But there is one case, where the session storage gets copied over from one tab to another tab which we will talk about in this article.

在这个现代的Web应用程序开发时代，对客户端存储的需求已经增加，现在客户端上有许多类型的存储可用，会话存储就是其中之一。 会话存储最适合仅将数据限制在应用程序正在运行的选项卡上的情况。 但是在一种情况下，会话存储空间将从一个选项卡复制到另一个选项卡，我们将在本文中进行讨论。

会话存储-背景： (Session storage — Background:)

From MDN docs:The sessionStorage property accesses a session Storage object for the current origin. sessionStorage is similar to localStorage; the difference is that while data in localStorage doesn't expire, data in sessionStorage is cleared when the page session ends.

从MDN docs： sessionStorage属性访问当前来源的会话Storage对象。 sessionStorage类似于localStorage ; 区别在于，尽管localStorage中的数据不会过期，但page Session结束时会清除sessionStorage数据。

Features of session-storage:

会话存储的特点：

1. The session storage is scoped at the browser-tab level; if we close the tab, the session storage for that tab instance is gone forever.
   会话存储的作用域在浏览器选项卡级别； 如果我们关闭标签页，则该标签页实例的会话存储将永远消失。
2. It is origin specific.
   它是特定于起源的。
3. Different types of protocols with the same origin have different session storage.
   具有相同来源的不同类型的协议具有不同的会话存储。
4. Session storage survive with tab refreshes.
   会话存储可以通过刷新选项卡生存。

Back to the point — Session storage gets copied over:

回到重点—会话存储被复制过来：

Browsers allow us to duplicate a tab, and during which the session storage also gets copied over to the new tab. Let’s talk through that scenario with an example.

浏览器允许我们复制选项卡，在此期间，会话存储也将复制到新选项卡。 让我们通过一个例子来讨论这种情况。

Let’s build a simple angular component that adds a value to session storage with a key RandomId if it doesn’t already exists.

让我们构建一个简单的角度组件，如果它不存在，则使用键RandomId向会话存储添加一个值。

Here is a simple code for that looks like:

这是一个简单的代码，看起来像：

RandomId RandomId更新会话存储

Now if I run this application, I see session storage has a new record with RandomId . Here is how it looks like

现在，如果我运行此应用程序，我将看到会话存储具有一个带有RandomId的新记录。 这是它的样子

Session storage on Tab1

Tab1上的会话存储

Now, right click on the current tab header and click on duplicate which opens up a new tab. During the application bootstrap process in the second tab, the component checks the session storage to see if RandomId exists and if it does it doesn’t do anything. Because of the session storage from tab-one gets copied over to tab-2, the application instance in second tab doesn’t try to add any value to session-storage thus we will see the same session storage values in second tab as well.

现在，右键单击当前选项卡标题，然后单击duplicate ，这将打开一个新选项卡。 在第二个选项卡的应用程序引导过程中，组件将检查会话存储以查看RandomId存在，如果存在，则它什么都不做。 由于将从选项卡1的会话存储复制到选项卡2，因此第二个选项卡中的应用程序实例不会尝试向会话存储添加任何值，因此我们在第二个选项卡中也将看到相同的会话存储值。

Duplicating a tab

复制标签

Now, if we take a look at the session storage of the duplicated tab, it looks like this:

现在，如果我们查看重复选项卡的会话存储，它看起来像这样：

Tab 2 — session storage

标签2-会话存储

This is the only scenario where session storage gets copied over to the new tab. So, when you are working with sessionStorage remember that the sessionStorage is not always unique to tab.

这是将会话存储复制到新选项卡的唯一方案。 因此，在使用sessionStorage请记住， sessionStorage并非总是tab唯一的。

结论： (Conclusion:)

When you duplicate a tab, the session storage gets copied over to the new tab though it is said that the session storage is tab scoped.

当您复制选项卡时，会话存储将复制到新选项卡，尽管据说会话存储是选项卡作用域的。

I hope you find this useful. Follow me on Medium for more interesting articles.

希望这个对你有帮助。 在更多的有趣文章上关注我。

翻译自: https://medium.com/swlh/a-less-known-thing-about-session-storage-api-4e59f6218af9

api网关 会话安全