URL中的SAML响应时间太长

我正在关注一篇神奇的文章SAML for Your Serverless JavaScript Application，该文章适用于使用来自给定IdP的SAML响应的AWS Cognito提供SSO的Web应用程序。下面是架构图： architecture URL中的SAML响应时间太长

所以我的问题是在API-G重定向到我的网站的最后。我可以在chrome/firefox开发工具中看到302重定向工作，并且在url中有正确的url和saml响应，但是页面无法加载。 Chrome浏览器显示“取消”，而Firefox对此无能为力。

我注意到总的网址长度大约是8500个字符，如果我使它大约7500个字符或更少，那么它可以工作，但大于7500左右，则会中断。

那么为什么写这篇文章的人会工作，但我无法得到它？该错误可能与我认为的不同，它似乎只是网址的长度。

本地我正在运行一个包含ng serve的Angular 4应用程序，最终的应用程序将是S3存储桶外的单页应用程序。

来源

2017-06-07 canada11

你正在修改什么URL从8500字符下降到7500？ 301重定向到了什么样的服务？ –

直接删除SAML响应中的字符。 302来自AWS API-G/Lambda，重定向是一个GET到承载网络应用程序的S3存储区（因为它是一个SPA和一个无服务器设置） – canada11

如果您将AWS CloudFront与您的S3存储桶一起使用，则存在8,192字节的URL限制，这似乎是导致问题的原因。

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html

甲SAML响应可以是不同的原因不同的长度。部分原因可能是：

包括签署公证书（以及它的变量）
属性声明（附带断言用户信息）

因此，或许笔者是生产SAML回应说导致更小的重定向网址。

此外，RFC中似乎没有任何规定URI长度的限制，所以他们的服务器/浏览器可能与您的设置不同。

来源

2017-06-10 11:14:26 vexdev

我会把它当作现在的答案。是的，我无法完全解决这个问题，但是看起来好像我们只是在SAML中添加了更多内容，使其变得更大。此外，我还需要提供许多关于这个人可以在AWS中承担的角色的信息，所以我现在只是走了一条不同的路线。至于URI长度的限制，这就是为什么我很好奇，在我的情况下，我应该建立完全一样的博客我跟随，这只是一个简单的SPA托管在S3（无服务器设置）。我猜S3在有7500多个字符的情况下出现问题 – canada11

您是否在使用CloudFront访问您的S3存储桶？如果是这样，我认为你在正确的轨道上。 CloudFront具有8,192字节的URL限制，看起来像是您在那里工作的领域。 http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html – vexdev

这个，你可以添加一个实际的答案或答案。因为就是这样，我正在使用cloudfront。这就是为什么然后，它不工作。 – canada11

URL中的SAML响应时间太长

回答

相关问题