views:

163

answers:

2

I just got pinged on another post because my application doesn't keep the user logged in after an iisreset.

http://stackoverflow.com/questions/2206595/how-do-i-solve-an-antiforgerytoken-exception-that-occurs-after-an-iisreset-in-my/2206609#2206609

I have to say I agree with the commenter that it is an artificial restriction.

From what I've read about Forms Authentication it appears that the logged in session information is all stored in memory and when the server is restarted you lose that information.

What I'd like to do is to simply be able to store that information somewhere, ideally in a database so that I can continue on with my sessions. I can't seem to find any way to extend it to do that though. Am I missing something? Have I misunderstood how it's working?

I realise that this is a 'free' piece of kit they're giving us but I'd rather not roll my own because there's a lot they got right and that I have the potential to screw up with my own solution.

Edit: Note this doesn't have anything to do with Session state. As far as I know I'm not using session state at all unless something under me in the framework uses it internally.

I realise that the cookies are used by the authentication but they haven't expired. I'm still getting bounced to the login page after an iisreset though.

+4  A: 

The Authentication session and the 'Session State' (Where anti forgeries tokens are tracked) are two completely seperate things in ASP.NET.

Authentication is tracked by a cookie in the browser (usually) and so will not be afected by iis restart.

Session State is, by default, stored in memory (where it will be killed by restart), but can be stored easily in SQL Server or a dedicated State Server process (which will both survice iis restarts).

UpTheCreek
Yes, if you move away from using InProc, then you get session persistence across application restarts, and across physical server moves if you're in a loadbalanced environment: See http://msdn.microsoft.com/en-us/library/ms178586.aspx for more details on the different modes.
Zhaph - Ben Duguid
You are right that session state is something different. From what I understand there is some state stored internally for the authentication though to prevent expiry fraud etc. At least I think that's what happens. Anyway, when I iisreset my apps they bounce you to the login page next request. I don't use Session anywhere afaik (unless ASP.Net MVC does under the hood).
Colin Newell
There's no Authentication state stored in server memory. It's just an encrypted cookie on the client. MVC does use session state now and then for some of it's features though. Did you biuld this from the MVC demo? Maybe it is checking a session var?
UpTheCreek
To tell the truth it looks like I have an answer on my original question that answers this. I'm just verifying it now. I was assuming there was state since it stopped working but it looks like it might actually be because the machine key is regenerated. http://stackoverflow.com/questions/2206595/how-do-i-solve-an-antiforgerytoken-exception-that-occurs-after-an-iisreset-in-my/2207535#2207535
Colin Newell
+3  A: 

Sounds like your problem here is that the <machineKey /> validationKey and decryptionKey attributes are set to AutoGenerate which means they're changing across IIS resets.

This means that encrypted persistent forms authentication cookies will no longer be valid the next they're presented.

You can fix this by manually configuring a fixed validationKey and decryptionKey. To do this take a look at this article:

How To: Configure MachineKey in ASP.NET 2.0

Scroll down to the section on "Web Farm Deployment Considerations" and Generate Cryptographically Random Keys.

Kev