AuthenticationConfig RedisCachingProvider serialization error

[DNNMonster]

Description of problem

There is a caching error during login when running an installation using Azure Redis cache provider which expects all cache items to be serializable. This is a DNN installation using the provider plugin available here: https://github.com/davidjrh/dnn.rediscachingprovider

DotNetNuke.Providers.RedisCachingProvider.RedisCachingProvider - Error while trying to store in cache the key DNN_Authentication.DNN_0 (Object type: DotNetNuke.Services.Authentication.AuthenticationConfig): System.Runtime.Serialization.SerializationException: Type 'Microsoft.Extensions.DependencyInjection.ServiceProvider' in Assembly 'Microsoft.Extensions.DependencyInjection, Version=2.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' is not marked as serializable.

Steps to reproduce

1. Ensure you have a functional DNN installation using Azure Redis Cache Provider
2. Verify you're moving data into your cache via your Azure portal
3. Restart your DNN App Pool
4. Login
5. View the log4net file for the error as shown above

Additional Context

It may be related to the AuthenticationConfigBase protected IServiceProvider DependencyProvider property. Initial thought was to test adding the NonSerialized attribute but that won't work with protected members. This error is showing in an App Service install but it is likely that it affects any installation that tries to implement the Redis Caching Provider plugin or Redis in general. It's possible this is an installation specific issue. This is the only DNN error I see when reviewing the logs for redis related issues.

Affected browser

• Chrome
• Firefox
• Safari
• Internet Explorer
• Edge

[mitchelsellers]

This one could be interesting as the actual object failing is inside of the Microsoft assembly.

@ahoefling any thoughts on this?

[bdukes]

What version of DNN is this? Is this a new issue with DNN 9.5.0?

[DNNMonster]

v. 09.04.04 (5)

[stale]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[stale]

This issue has been closed automatically due to inactivity (as mentioned 14 days ago). Feel free to re-open the issue if you believe it is still relevant.

[ggiordan]

I'm seeing this with DNN9.10.0 -- Did anyone ever get to the bottom of this?
I'm seeing this on my production site. One thought that I had is that there might be an old Microsoft DLL sitting in the bin directory causing the problem?? (@mitchelsellers comment sparked this thought)

[bdukes]

I've submitted #4788 which should resolve this error.

[ggiordan]

@bdukes, @mitchelsellers I put a note on the PR, Looking at the source in the main repo, I don't see the "[NonSerialized]" in the AuthenticationBase class, in fact, it looks totally different.

Also, I was looking closer at my logs and I'm seeing this:
2021-08-19 15:09:52,438 [XXXXXXXXXXXX][Thread:6][ERROR] DotNetNuke.Providers.RedisCachingProvider.RedisCachingProvider - Error while trying to store in cache the key DNN_Authentication.DNN_1 (Object type: DotNetNuke.Services.Authentication.AuthenticationConfig): System.Runtime.Serialization.SerializationException: Type 'DotNetNuke.Web.Common.LazyServiceProvider' in Assembly 'DotNetNuke.Web, Version=9.10.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable.

Is the answer here as simple as decorating DotNetNuke.Web.Common.LazyServiceProvider
with [Serializable]?

The better question is why do I only see this on my production system and not on any of my test systems?

[bdukes]

LazyServiceProvider holds an IServiceProvider which isn't serializable, so it would be back to the original error message.

Are your test systems using the Redis caching provider?

[ggiordan]

Hmm, interesting, Decorated the class to be serializable and deployed the dll to production, it seems to have reduced the number of occurrences by a great deal.

I have this one left:
2021-08-23 01:30:43,188 [RD281878CE13C1][Thread:5][ERROR] DotNetNuke.Providers.RedisCachingProvider.RedisCachingProvider - Error while trying to store in cache the key DNN_Authentication.DNN_0 (Object type: DotNetNuke.Services.Authentication.AuthenticationConfig): System.Runtime.Serialization.SerializationException: Type 'Microsoft.Extensions.DependencyInjection.ServiceProvider' in Assembly 'Microsoft.Extensions.DependencyInjection, Version=2.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' is not marked as serializable.

This one is MUCH less frequent, perhaps 200 times over the course of a day (we have a very busy site, so, its really not too bad).
I think this last one is never going to get resolved. I'm going to make a change to the Redis caching provider and submit a PR to change the serialization errors to be warnings so that they can be quieted down for production. but still seen on DEV systems.

I'm not seeing the original one you found. Also, when I look @ the current DNN9.10.0 source, I do not see the decoration that you removed in your PR. (thus I'm confused and probably missing something important).

Yes, both my test and prod systems are running the Redis caching provider.

I feel like I'm playing whack-a-mole with this, I'm going to see if I still have some of the older logs that I was looking at to see how many different variations there were.

The really annoying thing is that I'm not sure where this is actually coming from. I haven't had a great deal of success recreating it on demand.

[bdukes]

Did you deploy the fix from #4788? The final fix there was changing protected IServiceProvider DependencyProvider { get; } to protected IServiceProvider DependencyProvider => Globals.DependencyProvider; and removing this.DependencyProvider = Globals.DependencyProvider; from the constructor.

The NotSerialized attribute was originally added by the PR, but it didn't work so it wasn't included in the final change with that PR. It wasn't part of 9.10.0 and it won't be part of 9.10.1 or 9.10.2.