Access ASP.NET Core HttpContext.Session in Custom RequestCultureProvider - asp.net-core

Question

In our ASP.NET Core web app, I need to be able to access HttpContext.Session within a Custom RequestCultureProvider I've written. There is alot of background here... To be brief, I'll just mention that the business requirement is that I'm trying to meet, is to be able to display data in at least two different cultures, in our web app. A user may navigate to one page, where it should display in fr-FR and navigate to another page where it should display in zh-CN.
I have all of this working, when it comes to the "Response" from the server. By using an ActionFilter on a per-Action basis I can set the current thread's culture to whatever I want. We look up the various cultures from a database and store them in Session and then n the ActionFilter, based on an argument I pass to the ActionFilter method... I can even load ViewComponents via Controller Actions in the various cultures and have each view component display with a different culture setting. Given this, you can see why I can't store session in a Cookie or use the Querystring.
But the PROBLEM comes into play with "Requests" to the server, like when I edit Form data in a view and Submit/post the data back to an Action.
When I do that, my Dates are sent back in as NULL. BTW, I do Model binding and I have my dates marked with this attributes in my ViewModels:
[DataType(DataType.Date)]
[DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:dd-MMM-yyyy}")]
According to the well written article below, the order in which the Request culture is looked up, is:
https://www.jerriepelser.com/blog/how-aspnet5-determines-culture-info-for-localization/
From the query string
From a cookie
From the Accept-Language HTTP header
From the DefaultRequestCulture property of the RequestLocalizationOptions class
From the thread culture
I can certainly verify the above. If I use a cookie, it works. If I add French fr-FR as the first language in Chrome Settings, it works. If I change my default request culture in my Startup localization to fr-FR, it works...
For example, in the web page a Kendo DatePicker (or even an tag) will contain a French date like "14-août-2019", yet when I post it back to an Action, it is NULL unless I've set the querystring, cookie, Accept-Language or DefaultRequestCulture to fr-FR.
One odd thing is that #5 says it should use the current Thread Culture, and in my Action that I post Form data to I check the current thread's culture, and it is indeed fr-FR, so I don't know why my french dates are not being recognized...
So what I tried to get around this was to clear out all of those default providers and write a custom provider.
In Startup.ConfigureServices, I now do this:
services.Configure<RequestLocalizationOptions>(options =>
{
var supportedCultures = new[]
{
new CultureInfo("en-US"),
new CultureInfo("fr-FR"),
new CultureInfo("zh-CN"),
new CultureInfo("en-IE"),
};
var defaultCultureSettingOverride = this.Configuration.GetSection("appsettings").GetValue<string>("DefaultCultureOverride");
defaultCultureSettingOverride = defaultCultureSettingOverride == null ? "en-US" : defaultCultureSettingOverride;
options.DefaultRequestCulture = new RequestCulture(defaultCultureSettingOverride);
options.SupportedCultures = supportedCultures;
options.SupportedUICultures = supportedCultures;
options.RequestCultureProviders.Clear();
options.RequestCultureProviders.Insert(0, new MyCustomRequestCultureProvider()
{
Options = options,
});
});
And that works too, as long as my MyCustomRequestCultureProvider returns the correct culture!
My problem now is: I NEED to be able to access Session state in my custom RequestCultureProvider. But the HttpContext sent into DetermineProviderCultureResult has a null Session. Why? Is it the wrong place in the pipeline?
And when I call options.RequestCultureProviders.Insert(0, , new MyCustomRequestCultureProvider() in ConfigureServices, I don't have access yet (as far as I can tell) to the HttpContextAccessor.
If I pass new MyCustomRequestCultureProvider(new HttpContextAccessor()), that does me no good...
And while I have access to IHttpContextAccessor accessor as a parameter passed into Startup.Configure, I can't do the same thing with Startup.ConfigureServices. If I add (IHttpContextAccessor accessor) as an additional parameter to ConfigureServices, .NET Core errors when I run it, telling me that method can only access an IServicesCollection parameter.
I'm at a dead end...

Answer 1

Well, Session being NULL in my custom RequestCultureProvider was my fault.
In Startup.Configure, we had app.UseSession() AFTER app.UseRequestLocalization()
Once I moved app.UseSession() BEFORE app.UseRequestLocalization(), I was able to access Session in my custom RequestCultureProvider.
And now once I get the user's culture from Session and use it to return the proper ProviderCultureResult, my form posts do contain the dates.