Discord window.localStorage未定义.如何在Discord页面上访问localStorage? [英] Discord window.localStorage is undefined. How to get access to the localStorage on Discord page?

问题描述

当我在 https://stackoverflow.com 上运行 window.localStorage 时，它返回 localStorage ，但是当我在不和谐页面，每次都会返回 undefined .

When I run window.localStorage on https://stackoverflow.com it returns the localStorage but when I use the same command on Discord page it returns undefined every time.

Discord是否正在采取某些措施从客户端删除其 localStorage ?如果是这样，是否有办法在删除 localStorage 之前对其进行更改，防止其被删除或以其他任何方式在 undefined 未定义之前对其进行访问?

Is there something that Discord is doing to remove their localStorage from the client side? And if so, is there a way to change the localStorage before it is removed, prevent it from being removed or any other way to somehow access it before it is undefined?

有什么帮助吗?

推荐答案

您仍然可以通过编程方式获得访问权限.他们已删除 window.localStorage .这是自己的窗口实例的属性，但这不是数据属性，而是

You can still obtain access programmatically. They’ve deleted window.localStorage. This is an own-property of window instances, but it’s not a data property, it’s an accessor. The accessor’s get function will return the localStorage value associated with any appropriate receiver (this arg)*. Deleting the localStorage accessor has no impact on whether the object itself exists, so all you’ll need to do to access it again is find another get localStorage() function. Fortunately, you can obtain one many ways — every Window object gets created with one.

// If we create an <iframe> and connect it to our document, its
// contentWindow property will return a new Window object with
// a freshly created `localStorage` property. Once we obtain the
// property descriptor, we can disconnect the <iframe> and let it
// be collected — the getter function itself doesn’t depend on
// anything from its origin realm to work**.

function getLocalStoragePropertyDescriptor() {
  const iframe = document.createElement('iframe');
  document.head.append(iframe);
  const pd = Object.getOwnPropertyDescriptor(iframe.contentWindow, 'localStorage');
  iframe.remove();
  return pd;
}

// We have several options for how to use the property descriptor
// once we have it. The simplest is to just redefine it:

Object.defineProperty(window, 'localStorage', getLocalStoragePropertyDescriptor());

window.localStorage.heeeeey; // yr old friend is bak

// You can also use any function application tool, like `bind` or `call`
// or `apply`. If you hold onto a reference to the object somehow, it
// won’t matter if the global property gets deleted again, either.

const localStorage = getLocalStoragePropertyDescriptor().get.call(window);

如果这是一场军备竞赛，则有兴趣隐藏localStorage的一方可以尝试修补整个DOM中的每个方法和访问器，从而可以返回对尚未删除localStorage属性的窗口对象的引用.这比显而易见的难做.即使成功，最终的词语仍然留在用户端:浏览器扩展程序的清单可以声明内容脚本，该脚本在文档加载时将比其他任何代码先被评估.甚至CSP也无法阻止它.(一方面，这很糟糕……另一方面，如果没有这种功能，阻止广告的扩展程序将永远无法工作.)

If this is an arms race thing, the party interested in hiding localStorage could attempt patching every method and accessor throughout the DOM that could return a reference to a window object whose localStorage property has not already been deleted. That’s harder to do than might be obvious. Even if they succeeded, though, the final word will remain on the user side: a browser extension’s manifest can declare a content script that will be evaluated before any other code when the document loads. Even a CSP can’t prevent it. (On one hand this sucks ... on the other, without that capability, adblocking extensions could never work.)

Storage API(无论是sessionStorage还是localStorage)均不用于保存敏感数据.它根本没有受到保护.尝试隐藏它可能暗示它可能会被滥用-如果该站点的作者认为删除该属性可提供某种安全性，则您可能需要在该站点上输入敏感数据时要格外小心.

The Storage API, whether sessionStorage or localStorage, isn’t meant for holding sensitive data. It’s not protected at all. An attempt to hide it is a hint that it may be getting misused — you might want to be careful about entering sensitive data on that site if its authors are under the impression that deleting the property is providing some kind of security.

*此处合适的接收者是没有被用户禁用存储功能(例如Safari隐身)的任何窗口对象，并且其起源是非透明"的(例如，它在浏览器的 about:空白页面，因为存储需要与正常来源关联.

* An appropriate receiver here would be any window object that hasn’t had storage disabled by the user (e.g. Safari incognito) and which has a ‘non-opaque’ origin (meaning for example that it doesn’t work in the browser’s about:blank page, since storage needs to be associated with a normal origin).

此外:关于全球品牌属性的额外优惠.

**无论如何，它通常不取决于其来源领域 .但是，当接收者为null或未定义时，通过[Global]界面上的Web IDL属性创建的属性可能会表现出独特的行为，但是原始领域会变得很重要.如果我们要使用 no 接收器(例如

** It doesn’t depend on its origin realm normally, anyway. Properties created from Web IDL attributes on [Global] interfaces can exhibit a unique behavior when the receiver is null or undefined, though, where the origin realm can become significant. If we were to call the get function with no receiver, e.g.

const { get } = getLocalStoragePropertyDescriptor();
get(); // ... null?

...然后它会返回null，而不是像典型的那样抛出TypeError.实际上，所有平台属性(不仅是[Global]接口上的属性)都具有默认接收者.如果给定接收器为null或未定义，默认接收器即为该接收器，该接收器是创建函数的领域的全局对象.与[Global]情况不同的是，此默认值实际上可以是并且通常是 valid 接收器-即它可以是确实实现该属性为(任何其他)接口的对象.函数最终仍会抛出相同的TypeError，因此您永远不会知道此默认接收器).

...then it would, instead of throwing a TypeError like is typical, return null. In fact, all platform attributes, not just those on [Global] interfaces, have a default receiver. The default receiver, which kicks in if the given receiver is null or undefined, is the global object of the realm where the function was created. What’s different for the [Global] case is that this default can actually be, and usually is, a valid receiver — i.e. it can be an object that really does implement the interface whose attribute this is (any other functions would still end up throwing the same TypeError, so you’d never know about this default receiver).

在该示例中，它默认为原始iframe中的window对象.它尝试获取其 localStorage 对象，但是由于iframe早已消失，因此它返回null.我实际上不确定最后的行为在哪里指定.我猜实际上是未指定 ，因为它与该属性的IDL定义相抵触.不过，这样做很有意义(必须做些事情)，而这正是Chrome可以做到的.在Firefox中，尝试执行此操作会导致引擎内部错误，这表明这种边缘情况可能只是没有得到足够的考虑.

In that example, it defaults to the window object from the original iframe. It tries to grab its localStorage object, but because the iframe is long gone, it instead returns null. I’m not actually sure where that last behavior is specified. I’m guessing it’s not specified, actually, since it contradicts the IDL definition for the attribute. It makes sense though (it’s gotta do something), and it’s what Chrome does. In Firefox, attempting this leads to an internal engine error, suggesting this edge case might just not have gotten a lot of consideration.

这篇关于Discord window.localStorage未定义.如何在Discord页面上访问localStorage?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！