小编sih*_*hil的帖子

我一直在努力研究如何使用Lambda代理集成来表达(在cloudformation中)具有Lambda函数集成类型的API网关资源.

这在AWS控制台中很容易实现,因为您可以选择一个复选框:

但是,AWS :: ApiGateway :: Method CloudFormation资源中没有相应的字段(它应该在Integration属性中).

如何在cloudformation中配置它？

我们使用JVM后端运行Web应用程序(Java 7更新75;代码在Scala中,但我不相信这是相关的).我们使用Google通过Oauth进行身份验证.

在过去的几个月中,我们一直在间歇性地无法对用户进行身份验证.

重定向,并从谷歌是成功的,但是当我们试图打电话给token_endpoint在https://www.googleapis.com/oauth2/v4/token验证验证我们有时出现以下情况例外:javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation.

这个关于另一个问题的评论让我发现了一个JDK错误,它可以表现为这个异常(什么意思是"javax.net.ssl.SSLHandshakeException:服务器证书更改在重新协商期间受到限制"以及如何防止它？).

我的工作假设是:

该错误(https://bugs.openjdk.java.net/browse/JDK-8072385)表示仅检查主题备用名称(SAN)列表中的第一个条目.当验证的主机名在SAN列表中但不在列表顶部时,抛出上述异常.

昨天(2015年5月27日)我们看到两个不同的证书是间歇性地从www.googleapis.com提供的.第一个(串行67:1a:d6:10:cd:1a:06:cc)有一个SAN列表,DNS:*.googleapis.com, DNS:*.clients6.google.com, DNS:*.cloudendpointsapis.com, DNS:cloudendpointsapis.com, DNS:googleapis.com而第二个(串行61:db:c8:52:b4:77:cf:78)有一个SAN列表:DNS:*.storage.googleapis.com, DNS:*.commondatastorage.googleapis.com, DNS:*.googleapis.com.

由于JVM中的错误,我们可以验证第一个证书,但是第二个证书会抛出异常(尽管完全有效),因为*.googleapis.com它不是SAN列表中的第一个条目.

修复程序尚未发布7u85(没有提及何时可用).

我已经将我们集群的一个节点降级到7u65,但是证书似乎在我们这样做的时候就已经恢复了(我们看到的最后一个错误是22:20GMT)所以很难确定肯定的解决方案.

有没有其他人经历过这个或类似的东西,除了降级之外还有其他任何解决方法(降级会删除各种其他SSL/TLS检查)？

我正在使用API​​ Gateway的代理集成来调用Lambda.输出格式规范遵循JSON格式:

{
  "statusCode": httpStatusCode,
  "headers": { "headerName": "headerValue", ... },
  "body": "..."
}

在一个响应中,我希望设置两个cookie(两个不同的auth cookie),但JSON不允许在headers对象中具有两个相同的键(好的,技术上规范,但大多数库没有).

RFC 7230指出应该专门处理Set-Cookie,但我看不出如何通过API网关发送多个Set-Cookie值.

有谁知道这是否可能？

我们最近部署了一个新应用程序，该应用程序使用ASG配置为启动具有加密EBS根卷的实例。我们有很多现有的应用程序都可以使用此设置正常工作，但是我们的新ASG拒绝启动实例。这些实例甚至都没有出现，我们在ASG活动历史记录中看到一个错误：Client.InternalError: Client error on launch。

经过实验后，我们发现，如果将所使用的AMI交换为未加密的AMI，则所有AMI都将按预期开始工作。令人困惑的是，我们在不同的ASG上使用了完全相同的AMI，并且它们均按预期工作（由几乎相同的CloudFormation模板组成）。同样，我们可以使用相同的AMI和实例配置文件直接从控制台启动EC2实例。

有人见过这种行为吗？

我在其他地方找到了一些解决方案（这使我们证明了它与加密卷有关），例如来自AWS的解决方案，但它们似乎与我们的方案没有直接关系。

我目前正在将群集升级到6.1，无法在启动时让节点相互发现。三个单独的节点启动，但随后陷入循环：

[2018-01-08T11:33:01,421][WARN ][o.e.d.z.ZenDiscovery     ] [ip-10-xxx-xxx-xxx] not enough master nodes discovered during pinging (found [[Candidate{node={ip-10-xxx-xxx-xxx}{gMlxxxxxRW-74axxxQ8V-3x}{6gBBYZxxxxxxxon=-1}]], but needed [2]), pinging again

我的配置的相关部分是：

# Use the AWS private IP as self identifier
http.host: _ec2:privateIp_
network.host: _ec2:privateIp_
http.bind_host: 0.0.0.0
network.bind_host: 0.0.0.0

discovery.zen.hosts_provider: ec2
# These are expanded in my CloudFormation template
discovery.ec2.tag.Stack: @@STACK
discovery.ec2.tag.App: @@APP
discovery.ec2.tag.Stage: @@STAGE

（使用logger.org.elasticsearch.discovery.ec2: "TRACE"）打开调试以进行发现为我提供了一些证据，证明发现过程失败了：

[2018-01-08T11:32:58,419][TRACE][o.e.d.e.AwsEc2UnicastHostsProvider] [ip-10-xxx-xxx-xxx] building dynamic unicast discovery nodes...
[2018-01-08T11:32:58,420][DEBUG][o.e.d.e.AwsEc2UnicastHostsProvider] [ip-10-xxx-xxx-xxx] using dynamic discovery nodes []