小编mac*_*jna的帖子

我正在尝试找出 Web 应用程序配置的最佳方法。目标是：

1. 可配置性。强制在部署时指定配置。确保配置与代码或可部署工件分开。
2. 安全。防止机密从部署环境中泄露。
3. 简单。确保解决方案简单，并且对操作系统进程的概念很自然。
4. 灵活性。不对配置的存储位置做任何假设。

根据12 因素应用程序Web 应用程序配置最好在环境变量中提供。它简单而灵活，但看起来有一些与此相关的安全问题。

另一种方法是将所有配置作为命令行参数传递。这对操作系统来说又是简单、灵活和自然的，但整个配置然后在主机的进程列表中可见。这可能是也可能不是问题（我不是操作系统专家），但解决方案至少很麻烦。

流行的Dropwizard框架采用了一种混合方法，其中命令行参数指定配置文件的位置，然后从那里读取配置。问题是它打破了对我的配置（本地文件）的位置做出假设的灵活性约束。它还使我的应用程序实现文件访问，虽然在大多数语言/框架/库中通常很容易实现，但本质上并不简单。

我正在考虑另一种方法，即在应用程序的stdin. 最终cat my-config-file.yml | ./my-web-app，在本地存储文件甚至wget https://secure-config-provider/my-config-file.yml | ./my-web-app. 管道看起来很简单并且是操作系统进程的本机。它似乎非常灵活，并且将配置如何提供给主机操作系统的问题分开了。

问题是它是否符合安全约束。假设一旦管道内容被消费它就永久消失是否安全？

我无法用谷歌搜索任何尝试这个的人，因此这个问题。

我正在尝试实现OpenID Connect隐式流程。前端单页应用程序将ID令牌向下传递到后端服务器（使用Authorization标头），在这里我需要对其进行验证。

该文档要求我检查我是否信任令牌的受众（aud和azp字段）。我正在努力了解此验证步骤的重要性以及不进行验证的安全隐患是什么。如果我不是预期的接收者，为什么我应该不信任令牌？

我的理由是，如果我信任发行人，那么发行人的代币无关紧要。我希望任何clientId的声明都相同（这是错误的吗？）。理想情况下，当我在微服务周围传递ID令牌时，他们应该知道的是哪些发行者可以信任（并使用发现协议来确定密钥）。

如果我跳过此验证步骤，攻击向量是什么？

我正在尝试使用HSpec和QuickCheck来验证Monoid的属性（关联性和标识元素）。我将验证特定的实例，但想保留大多数代码的多态性。这是几个小时后我想到的：

module Test where

import Test.Hspec
import Test.QuickCheck
import Data.Monoid

instance (Arbitrary a) => Arbitrary (Sum a) where
    arbitrary = fmap Sum arbitrary

instance (Arbitrary a) => Arbitrary (Product a) where
    arbitrary = fmap Product arbitrary

prop_Monoid_mappend_mempty_x x = mappend mempty x === x

sumMonoidSpec = it "mappend mempty x = x" $ property (prop_Monoid_mappend_mempty_x :: Sum Int -> Property)
productMonoidSpec = it "mappend mempty x = x" $ property (prop_Monoid_mappend_mempty_x :: Product Double -> Property)

main :: IO () …