Allow SqlSessionStateProviderAsync AppId to be configurable

[charles-muller]

Functional Impact

The inability to explicitly set the appId and instead rely on the HttpRuntime.AppDomainAppId to arrive at a unique suffix for the session identifier has an impact on blue-green deployments. Specifically, currently logged-in users will lose their existing session when the swap operation occurs. In my case, blue-green deployments are achieved using Azure app service slots.

Minimal repro steps

1. Create a web application project targeting 4.6.2
2. Install SqlSessionStateProviderAsync 1.0.1 nupkg and configure it
3. Create an aspx page which writes session data
4. Create an aspx page which reads/displays the session data
5. Create an Azure app service to contain the app
6. Create a deployment slot (call, it say "staging")
7. Deploy the web app to the staging slot
8. Swap staging to production
9. Navigate to production web page which writes session data
10. Navigate to production web page which displays the session data; verify that it is displayed
11. Deploy the web app to the staging slot a 2nd time
12. Swap staging to production
13. Navigate/refresh production web page which displays the session data; data is lost!

Expected result

Swapping the staging slot with the production slot should preserve the existing session. Based on my own observations, a new/different AppDomainAppId is being used by the newly deployed app, meaning a different suffix is appended to the sessionId. As such, the previous sessionId is not recognized.

Actual result

Current session is discarded

Further technical details

At the very least, I'd expect to be able define an AppId or ApplicationName in the session state provider section of the web.config file. This setting (if provided) should be obtained as part of the SqlSessionStateProviderAsync.Initialize() method and be used to calculate a unique value for the s_appSuffix member

[StephenMolloy]

Desktop ASP.Net Session State was never designed for use across different applications. Thats why it relies on AppId. Because of the uncertainties around the correctness of implementation and potential unknown security and performance implications, it has been the ASP.Net teams policy to not officially support cross-app sharing of session state. Thus, we won't be accepting addresing this bug ta this time.

There are unofficial ways to work around this. The internet has quietly discussed it for years. Using this repo alone, it would be easy enough to subclass the async sql provider and fiddle with the AppId property upon initialization.