I am running a B2B website, where customers login, view the catalog and place orders. The website runs on a sub-domain (I think this is an important side note because of this). By the time customers finish their order and click on the place order button, they are sent back to the login screen, loosing their order. Sometimes, this period is shorter sometimes longer. Something to do with the Application Pool being restarted?.
So I created a logging functionality to see what's happening and came to find out whenever a user logs in, the following logs are created:
Using an in-memory repository. Keys will not be persisted to storage.
Neither user profile nor HKLM registry available. Using an ephemeral key repository. Protected data will be unavailable when application exits.
No XML encryptor configured. Key {6a86c315-5115-4d16-a3f8-2ec49450b794} may be persisted to storage in unencrypted form.
I searched these and found a webpage explaining in detail why this happens. The prblem being a bug in IIS (which it is unlikely to be corrected) solution is to change a setting on IIS which I am not able to do. I am on a shared hosting. I've already discussed this with their support and they said they cannot change the settings on IIS for shared servers. So, setting the Load User Profile
to True
on IIS is not an option for me.
I also read somewhere that using Azure Apps I can change where the keys generated are stored. I have not looked into this yet though.
So any ideas how this issue might be resolved? Is a dedicated server or using Azure services my only options?
For reference, below is the related section from my Startup.cs
file
services.Configure<IdentityOptions>(options =>
{
// password settings
options.Password.RequireDigit = false;
options.Password.RequireLowercase = false;
options.Password.RequireUppercase = false;
options.Password.RequireNonAlphanumeric = false;
options.Password.RequiredLength = 6;
options.Password.RequiredUniqueChars = 1;
// lockout settings
options.Lockout.DefaultLockoutTimeSpan = System.TimeSpan.FromMinutes(5);
options.Lockout.MaxFailedAccessAttempts = 5;
options.Lockout.AllowedForNewUsers = true;
// sign in settings
options.SignIn.RequireConfirmedEmail = true;
// user settings
options.User.AllowedUserNameCharacters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._@+";
options.User.RequireUniqueEmail = true;
});
services.ConfigureApplicationCookie(options =>
{
options.Cookie.HttpOnly = true;
options.ExpireTimeSpan = System.TimeSpan.FromDays(45);
options.LoginPath = "/Identity/Account/Login";
options.AccessDeniedPath = "/Identity/Account/AccessDenied";
options.SlidingExpiration = true;
});
If you are unable to use any of the default key persistence methods, there are other options available, e.g. storing the key in a Database (via Entity Framework), Redis, Services like Azure KeyVault etc.
See Key Storage Providers for more details.