ASP.NET MVC: How SimpleMembership, SQLSession Repository, Authentication, and Authorization Work?

Question

I struggled with these elements for about 2 months.

The first problem occurs when my MVC4 application is redesigned . The currently logged-in user suddenly cannot access any controller actions marked with [Authorize] . In addition, any successful access to a controller action that requires a database connection causes this error:

Cannot open user default database. Login failed. Login failed for user 'IIS APPPOOL \ DefaultAppPool'.

This is strange because if I clear my authentication cookies, it works fine. Therefore, there is a problem with the ASPXAUTH and .ASPNET_SessionId files .

Later I will find out that these errors are caused by the session invalidation after rebooting or rebooting the server. My session setup was in InProc mode. This means that the session is lost every time the server reboots or is recycled.

Then I change the session configuration to Custom Session SQLStore described in

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

and

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

The goal is to save session data in SQLServer , but the problem does not seem to go away. After restarting or reusing the server, the current user in the system still has a problem with access to the controller action.

My thought is that SimpleMembership does not store the database login session. Here is how I can log in:

WebSecurity.Login(userName, model.Password, persistCookie: true) 

If I'm right, the system will try to match authentication cookies with login session data and determine if authentication is valid. This is why my user has a problem because matching between session and cookies creates some strange things.

I have done a lot of research over the past 2 months, I found a lot of similar problems with mine, but I did not find the right solution.

The temporary solution that I use is to shut down the user if the server receives recirculation or restart. This is not a good solution, because if the user is in the middle of an important transaction or sending, the data may be lost and the user will be redirected to the login page again.

---

Update

I have a set of machine keys:

 <machineKey validationKey="685DD0E54A38F97FACF4CA27F54D3DA491AB40FE6941110A5A2BA2BC7DDE7411965D45A1E571B7B9283A0D0B382D35A0840B46EDBCE8E05DCE74DE5A37D7A5B3" decryptionKey="15653D093ED55032EA6EDDBFD63E4AAA479E79038C0F800561DD2CC4597FBC9E" validation="SHA1" decryption="AES" /> 

I am trying to debug my own SQL session store, I found that the authentication session is not stored in the database. I can find "__ControllerTempData" extracted from my SQL session and nothing else.

Please correct me if I am mistaken, how does the website reuse cookies for authentication and verify it by comparing authentication cookies and authentication session, right?

Apparently SimpleMembership Login () does not save the authentication session on the SQL state server.

Then what session key is used for comparison?

Answer 1

This is so stupid for me. I did not set:

 if (!WebSecurity.Initialized) WebSecurity.InitializeDatabaseConnection("DefaultConnection", "UserProfile", "UserId", "UserName", autoCreateTables: false); 

in my application initialization (global.asax or any initialization code called from global.asax).

I call WebSecurity.InitializeDatabaseConnection() only when the code is needed, and somehow the website skips WebSecurity.InitializeDatabaseConnection() when I made a request while restarting the server.

There is no connection between the session and the cookie, which performs some validation. There is no confirmation between them. Authorization is authorized exclusively using cookies.

I still need a special sql store tho session. Because TempData becomes constancy. This will not cause the form to fail when the server restarts.

Answer 2

Make sure you add the machineKey parameter to your web.config, otherwise your site will use an automatically generated machine key. If the car key is changed, all encrypted with the previous key cannot be decrypted , which will lead (partially) to the error you see.

I sent an answer to another question that covers adding machineKey to your web.config and how to generate the keys yourself, or you can use the code from this application that I made .

So the gist:

1) Add a machine key, for example (filling in the corresponding values) "

 <machinekey compatibilitymode="Framework45" validation="HMACSHA256" validationkey="YOURVALIDATIONKEYHERE" decryption="AES" decryptionkey="YOURDECRYPTIONKEYHERE" /> 

2) Restart the application pool. You will have another round of users potentially having problems accessing the site (unless you also change the name of the cookie), but removing their cookies will solve this problem.