I've searched around and this seems like a no-brainer. I am using the ASP.NET Universal Providers (1.1 of nuget package). However, session is clearly not being shared between the instances because after logging in, as I click around to links
I sometimes am re-directed to the login page and sometimes am authorized to access the content.
The only significant deviation with my configuration and the boilerplate configurations described out there is the machineKey and membership hashAlgorithmType configuration. These are necessary to ensure the password hash used by Azure to authenticate
a user's credentials match the hash used when creating the user accounts via the ASP.NET Configuration utility.
All the examples about using the universal providers are so straight-forward and never mention any "gotcha" issues to be aware of so I can't think where to even begin looking.
Well, I'm sure caching would work. However, there are additional fees associated with the caching approach which we don't want to incur (this is for a non-profit with very limited funds). They are already paying for a SQL Azure database and it
should be relatively trivial to get session managed in the database.
For the above reasons, I reject your answer. Correct me if I'm wrong.
Can anyone actually help me get the universal providers working? They are supposed to be fully supported by Microsoft after all.
I'm glad you realized that the caching preview does not incur additional costs.
However, the machine key may be the issue. I seem to recall that the machine key is generated dynamically by the host VM so this could be part of the issue. If you can get your membership provider to use another key, this may address the problem you're experiencing.
I'm actually encountering this same exact issue.
I wrote about it before and now after some more testing, the issue still persists. I followed this
guide and configured the site to use AppFabricCacheSessionStoreProvider, but my site throws the user back to login form almost all the time. Sometime the user can use the site and click the links
for few minutes before the need to login again but often it takes less than five clicks and the user is back starting at the login form. My cloud service is running on two instances.
When working with multiple instances, azure automatically adds a machinekey for you in web.config
This is so session can work on an application across multiple servers.
You drop (delete) your existing staging environment, then re-create it, then swap VIPs.
In this scenario you could have different machine keys between staging environment and production environment. At this point, the "stored" session object will not be correct because the hash would be different, therefore redirecting to login again.
Another is to drop your production environment and re-create, the same will occur, the session hash is stored in cache and then becomes incorrect.