ASP.NET MVC:SimpleMembership,SQLSession存储,身份验证和授权如何工作?

Alv*_*nus 7 c# asp.net cookies asp.net-mvc session

我一直在努力使用这些元素大约2个月.

当我的MVC4应用程序被回收时出现了第一个问题.当前登录的用户突然无法访问标记为[授权]的任何控制器操作.此外,任何成功访问需要数据库连接的控制器操作都会产生此错误:

无法打开用户默认数据库.登录失败.用户'IIS APPPOOL\DefaultAppPool'登录失败.

这很奇怪,因为如果我清除我的身份验证cookie,它可以正常工作.所以ASPXAUTH.ASPNET_SessionId cookie 存在问题.

后来我发现这些错误是由服务器重启或回收后会话失效引起的.我的会话设置是InProc模式.这意味着每次重新启动或回收服务器时会话都会丢失.

然后我将会话配置更改为自定义会话SQLStore,其中描述了

https://msdn.microsoft.com/en-us/library/ms178588.aspx

https://msdn.microsoft.com/en-us/library/ms178589.aspx

目的是将会话数据存储在SQLServer中,但问题似乎不会消失.服务器重新启动或回收后,当前登录的用户仍然无法访问控制器操作.

我的想法是SimpleMembership没有将登录会话存储在数据库中.这是我登录的方式:

WebSecurity.Login(userName, model.Password, persistCookie: true)
Run Code Online (Sandbox Code Playgroud)

如果我是正确的,系统将尝试将身份验证cookie登录会话数据进行匹配,并确定身份验证是否仍然有效.这就是我的用户遇到问题的原因,因为会话和cookie之间的匹配会产生一些奇怪的东西.

我在过去的两个月里做了很多研究,我发现了很多与我相似的问题,但我找不到合适的解决方案.

我正在使用的临时解决方案是在服务器被回收或重新启动时注销用户.这不是一个好的解决方案,因为如果用户处于重要事务或提交的中间,则数据可能会丢失,并且用户将再次重定向到登录页面.


更新

我有我的机器密钥集:

<machineKey validationKey="685DD0E54A38F97FACF4CA27F54D3DA491AB40FE6941110A5A2BA2BC7DDE7411965D45A1E571B7B9283A0D0B382D35A0840B46EDBCE8E05DCE74DE5A37D7A5B3"
  decryptionKey="15653D093ED55032EA6EDDBFD63E4AAA479E79038C0F800561DD2CC4597FBC9E"
  validation="SHA1" decryption="AES" />
Run Code Online (Sandbox Code Playgroud)

我尝试调试我的自定义SQL会话存储,我发现数据库中没有存储认证会话.我只能"__ControllerTempData"从我的SQL会话中找到检索,没有别的.

如果我错了,请纠正我,网站重用身份验证cookie的方式并通过比较身份验证cookie和身份验证会话验证它,我是对的吗?

显然,SimpleMembership Login()不会将身份验证会话存储到SQL状态服务器中.

那么哪个会话密钥用于比较?

Alv*_*nus 0

这对我来说太愚蠢了。我没有放:

if (!WebSecurity.Initialized)
    WebSecurity.InitializeDatabaseConnection("DefaultConnection", "UserProfile", "UserId", "UserName", autoCreateTables: false);
Run Code Online (Sandbox Code Playgroud)

在我的应用程序初始化中(global.asax 或从 global.asax 调用的任何初始化代码)。

WebSecurity.InitializeDatabaseConnection()我只在代码需要时调用,并且WebSecurity.InitializeDatabaseConnection()当我在服务器重新启动时发出请求时,网络会以某种方式丢失。

会话和执行某些验证的 auth cookie 之间没有连接。他们之间没有验证。登录身份验证纯粹由 cookie 保存。

我仍然需要自定义 sql 存储会话。因为TempData变成了坚持。这不会导致服务器重新启动时表单提交失败。