You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we have an ASP.NET core 2.2 web application exposing some web api controllers.
Our application does not have any kind of authentication mechanism, all the exposed endpoints can be called by an anonymous user (put another way: we don't use ASP.NET identity at all).
When we host the application on windows machine using IIS we get 3 strange warning messages at the application startup. These are the logs we get:
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 {GUID} may be persisted to storage in unencrypted form.
After some investigation on the subject i understood that these logs are related to the ASP.NET core data protection stack and, based on my understanding of the subject, I guess that we can safely ignore the warnings because we don't need authentication cookies, password reset tokens, email verification tokens and similar stuff.
My first question is just a confirmation of the previous point: is it safe for us to go on and ignore the warnings ?
Actually, if we try to run the same application by using an Azure app service, we don't see any warning logs at startup so I can conclude that, at least in Azure, the default key location is being used as expected.
I have checked that the IIS application pool hosting the web application has the option Load User Profile set to True as explained in the article linked above, but the warning logs are still there. Why IIS is not able to use the default storage for data protection keys ? My understanding is that this issue depends only on the configuration of our local IIS. What should we check ? Is it possible to fix this issue ?
Thanks for helping
The text was updated successfully, but these errors were encountered:
I finally solved, at least on my dev machine, thanks to the guide you linked in your reply.
The issue was related to the setProfileEnvironment inside the applicationHost.config of my dev machine. I just need to perform a complete test on a server machine (I have a Windows 10 professional installation on my machine), but I guess it's going to work.
Hi,
we have an ASP.NET core 2.2 web application exposing some web api controllers.
Our application does not have any kind of authentication mechanism, all the exposed endpoints can be called by an anonymous user (put another way: we don't use ASP.NET identity at all).
When we host the application on windows machine using IIS we get 3 strange warning messages at the application startup. These are the logs we get:
After some investigation on the subject i understood that these logs are related to the ASP.NET core data protection stack and, based on my understanding of the subject, I guess that we can safely ignore the warnings because we don't need authentication cookies, password reset tokens, email verification tokens and similar stuff.
My first question is just a confirmation of the previous point: is it safe for us to go on and ignore the warnings ?
We found an article that explains this specific issue.
The article refers to this Microsoft documentation which explains that the data protection stack has some defaults configuration and it should know out of the box where to store the keys it uses.
Actually, if we try to run the same application by using an Azure app service, we don't see any warning logs at startup so I can conclude that, at least in Azure, the default key location is being used as expected.
I have checked that the IIS application pool hosting the web application has the option Load User Profile set to True as explained in the article linked above, but the warning logs are still there. Why IIS is not able to use the default storage for data protection keys ? My understanding is that this issue depends only on the configuration of our local IIS. What should we check ? Is it possible to fix this issue ?
Thanks for helping
The text was updated successfully, but these errors were encountered: