Make Microsoft.AspNetCore.DataProtection.DataProtectionProvider class static

[javiercn]

https://github.com/aspnet/DataProtection/blob/dev/src/Microsoft.AspNetCore.DataProtection.Extensions/DataProtectionProvider.cs

https://docs.asp.net/en/latest/security/data-protection/configuration/non-di-scenarios.html

This class is meant to be used in Non-DI scenarios as an entry point for creating a IDataProtectionProvider instance that can be used acrross the app to protect and unprotect data. As such, making it static will avoid any confusion of mixing it with DI enabled scenarios. The advantages are:

• Clearly separates DI scenarios from non DI scenarios. (You can't register a static class in a DI Container)
• Makes the class cleaner (The current implementation creates a whole data protection stack inside the constructor, and wraps the default implementation without any perceived benefit.
• Is arguably less discoverable, it's easier to 'dot' into a static class and see a method that you can use to construct an instance of the thing that you want, than having to use 'new' on the type.
• By doing all the setup in a constructor, we are cornering ourselves in the future if we wan't to do more complicated things inside the setup, like for example, caching existing DataProtectionProviders.

As a reference, here is the implementation as a static class

using System;
using System.IO;
using Microsoft.Extensions.DependencyInjection;

namespace Microsoft.AspNetCore.DataProtection
{
    public static class DataProtectionProvider
    {
        public static IDataProtectionProvider Create(DirectoryInfo keyDirectory)
        {
            return Create(keyDirectory, setupAction: null);
        }

        public static IDataProtectionProvider Create(
            DirectoryInfo keyDirectory,
            Action<DataProtectionConfiguration> setupAction)
        {
            if (keyDirectory == null)
            {
                throw new ArgumentNullException(nameof(keyDirectory));
            }

            var serviceCollection = new ServiceCollection();
            var builder = serviceCollection.AddDataProtection();
            builder.PersistKeysToFileSystem(keyDirectory);

            if(setupAction != null)
            {
                setupAction(builder);
            }

            return serviceCollection.BuildServiceProvider().GetRequiredService<IDataProtectionProvider>();
        }
    }
}

[danroth27]

@blowdart

[blowdart]

By doing all the setup in a constructor, we are cornering ourselves in the future if we wan't to do more complicated things inside the setup, like for example, caching existing DataProtectionProviders.

This is the simple "Give me something and get the hell out of my way" class. We don't want to be doing anything complicated in it at all, beyond allowing X509 protection of the key ring.

What if this is what someone wants to register as a service in DI?

[javiercn]

@blowdart It doesn't make sense as a DI-able service, what would be the point? It's easier for a customer to write their own DataProtector wrapper if they need to than reusing this one.

[blowdart]

Well it doesn't affect anything really, so I'm ok either way