我最近偶然发现了在JavaScript中使用for..in循环的问题.

根据这个 问题的答案,for..in旨在枚举对象的属性,包括继承的属性.

如果是这样,为什么我们能够使用Object.defineProperty将属性定义为不可枚举？这不符合for..in的全部意图吗？或者它被认为是不好的做法,应该避免？

另外,为什么我们要首先以这种方式迭代所有属性(即使用for..in循环)？什么时候可以派上用场？

为什么不将所有(Array)原型扩展定义为不可枚举并继续使用for..in和数组？

不久前，我致力于在 Web 应用程序中设置 SSO 用户身份验证。特定的 IdP 是 ADFS 服务器，但我认为这不是很重要。

配置应用程序的 SSO 设置时，我注意到需要 IdP 证书的指纹，而不是证书本身。现在，据我了解，应用程序使用指纹来验证已颁发的 SAML 令牌上的 IdP 签名。

问题是应用程序如何仅使用证书指纹来验证签名？它不需要证书的公钥，它是证书本身的一部分，但不是它的指纹的一部分？这个签名验证过程如何进行？

TL; DR

我试图遮蔽akka库的一个版本并将其与我的应用程序捆绑在一起(以便能够spray-can在CDH 5.7版本上运行服务器Spark 1.6).着色过程混淆了akka默认配置,并且在为阴影手动提供单独版本的akkas之后,看起来仍然看起来两个版本以某种方式混淆了.reference.confakka

是否akka已知阴影版本会导致问题？我究竟做错了什么？

背景

我有一个Scala/ Spark应用程序当前在Spark 1.6.1独立运行.应用程序使用spray-canhttp服务器运行spray 1.3.3,这需要akka 2.3.9(Spark 1.6.1独立包括兼容akka 2.3.11).

我正在尝试将应用程序迁移到运行该版本的新的Cloudera基于Spark群集的群集.问题是,在与捆绑这是不足够的正常工作.CDH 5.7Spark 1.6Spark 1.6CDH 5.7akka 2.2.3spray 1.3.3

试图解决方案

根据这篇文章中的建议,我决定将akka 2.3.9它与我的应用程序一起进行着色并捆绑.虽然这次我偶然发现了一个新问题 - akka它是否在reference.conf文件中定义了默认配置,该文件应该位于应用程序的类路径中.由于着色功能中的已知问题,sbt-assembly阴影 …

考虑以下代码：

static IEnumerable<int> GetItems()
{
    return Enumerable.Range(1, 10000000).ToArray();  // or: .ToList();
}

static void Main()
{
    int count = GetItems().Count();
}

它会迭代所有 100 亿个整数并一一计数，还是会使用数组Length/列表的Count属性？

在使用 IdP 通过 IdP 对其用户进行身份验证的 Web 应用程序中，oauth2用于实现用户权限（客户端和服务器端）的更标准/推荐选项是什么？

通过“用户权限”，我指的是用户在应用程序中允许或不允许执行的操作。
例如，假设应用程序有一个“管理”页面，用于管理应用程序的某些设置，仅允许特定用户进入。其中一些用户仅被允许查看当前设置，而其他用户也被允许更改设置（可能只有其中一些）。

据我所知，oauth2 中“范围”的概念可能用于实现这样的要求，例如，仅被允许查看“管理”页面app:admin:view的用户将具有范围，而可以此外，编辑设置也会有一个app:admin:some-setting:edit范围。
但是，在大多数大型身份提供者服务中，管理这些范围并将它们分配给用户的任务似乎是一项相当乏味的任务。

这会是一个很好的解决方案吗？如果是这样，是否有任何产品/服务与 oauth2 IdP 集成并帮助更轻松地管理权限及其分配给用户（例如，具有漂亮直观的 UI）？如果没有，是否有任何既定方法处理此类情况？