如何通过浏览器后退按钮阻止SignInResponseMessage重新发布 [英] How to prevent SignInResponseMessage repost via browser back button

问题描述

我有一个使用WIF的ASP.NET MVC 3应用程序和STS。

我相信我们的安排是标准的。

I have an ASP.NET MVC 3 application and STS that use WIF.
I believe that our arrangement is faily standard.

I在WSFederationAuthenticationModule.SignOut（）之后遇到了一种情况，STS使用SignInResonseMessage.WriteFormPost（）生成的原始表单帖子可以通过浏览器的后退按钮重新发布到应用程序，实际上是
登录用户回来了。 显然，这并不好。

I've encountered a situation where, following a WSFederationAuthenticationModule.SignOut(), the original form post generated by the STS using SignInResonseMessage.WriteFormPost() can be re-posted to the application via the browser's back button, effectively logging the user back in.  Obviously, this isn't good.

应用程序页面具有禁用缓存的http标头，因此提示用户确认重新发送表单数据。但是，一旦确认，数据就会被发布。

The application pages have http headers to disable caching and so the user is prompted to confirm resending the form data. But, upon confirmation, the data is posted.

我已经创建了一个试用解决方法，其基础是在注销时使ASP.NET会话ID cookie失效并注意到新的会话ID -post。

I've created an trial workaround based on expiring the ASP.NET session ID cookie on sign out and noticing a new session ID on the re-post.

还有其他人遇到过这种情况吗？ 如果是这样，采取了哪种方法来阻止它呢？

Has anyone else encountered this situation?  If so, what sort of approaches have been taken to prevent it?

推荐答案

这是我从不建议人们创造的一个例子他们自己的STS。如果您环顾市场并发现现有产品没有满足您的需求，A）打电话给我，B）哈希传入的SAML断言，将摘要存储在STS的缓存
中，并拒绝任何包含您之前见过的断言的请求。 

This is an example of why I never suggest that people create their own STS. If you looked around in the market and found that no existing product will meet your needs, A) call me and B) hash the incoming  SAML assertion, store the digest in a cache in your STS, and reject any request that contains an assertion you have seen before. 

HTH！

 

这篇关于如何通过浏览器后退按钮阻止SignInResponseMessage重新发布的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！