Замена ASP.NET machineKey в ASP.NET Core

Реализация <machineKey> элемента в ASP.NET может быть заменена. Это позволяет большинству вызовов ASP.NET криптографических подпрограмм направляться через механизм защиты данных замены, включая новую систему защиты данных.

Установка пакета

Примечание.

Новая система защиты данных может быть установлена только в существующем приложении ASP.NET, предназначенном для .NET 4.5.1 или более поздней версии. Установка завершится ошибкой, если приложение предназначено для .NET 4.5 или ниже.

Чтобы установить новую систему защиты данных в существующий проект ASP.NET 4.5.1+ , установите пакет Microsoft.AspNetCore.DataProtection.SystemWeb. Это создаст экземпляр системы защиты данных с помощью параметров конфигурации по умолчанию.

При установке пакета она вставляет строку в web.config , которая сообщает ASP.NET использовать его для большинства криптографических операций, включая проверку подлинности форм, состояние просмотра и вызовы MachineKey.Protect. Он не использует API защиты данных. Строка, вставленная, считывается следующим образом.

<machineKey compatibilityMode="Framework45" dataProtectorType="..." />

Совет

Вы можете определить, активна ли новая система защиты данных, проверяя такие поля, как __VIEWSTATEэто должно начинаться с CfDJ8, как показано в приведенном ниже примере. CfDJ8 — это представление базового4-го заголовка "09 F0 C9 F0", определяющего полезные данные, защищенные системой защиты данных.

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="CfDJ8AWPr2EQPTBGs3L2GCZOpk...">

Конфигурация пакета

Система защиты данных создается с конфигурацией нулевой настройки по умолчанию. Тем не менее, так как по умолчанию ключи сохраняются в локальной файловой системе, это не будет работать для приложений, развернутых в ферме. Чтобы устранить эту проблему, можно предоставить конфигурацию, создав тип, который подклассы DataProtectionStartup и переопределяет его метод ConfigureServices.

Ниже приведен пример пользовательского типа запуска защиты данных, который настраивает как место хранения ключей, так и способ шифрования неактивных ключей. Она также переопределяет политику изоляции приложений по умолчанию, указав собственное имя приложения.

using System;
using System.IO;
using Microsoft.AspNetCore.DataProtection;
using Microsoft.AspNetCore.DataProtection.SystemWeb;
using Microsoft.Extensions.DependencyInjection;

namespace DataProtectionDemo
{
    public class MyDataProtectionStartup : DataProtectionStartup
    {
        public override void ConfigureServices(IServiceCollection services)
        {
            services.AddDataProtection()
                .SetApplicationName("my-app")
                .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\myapp-keys\"))
                .ProtectKeysWithCertificate("thumbprint");
        }
    }
}

Совет

Можно также использовать <machineKey applicationName="my-app" ... /> вместо явного вызова SetApplicationName. Это удобный механизм, чтобы избежать принудительного создания производного от разработчика типа DataProtectionStartup, если все, что они хотели настроить, задало имя приложения.

Чтобы включить эту настраиваемую конфигурацию, вернитесь в web.config и найдите <appSettings> элемент, добавленный пакетом в файл конфигурации. Эта разметка будет выглядеть следующим образом:

<appSettings>
  <!--
  If you want to customize the behavior of the ASP.NET Core Data Protection stack, set the
  "aspnet:dataProtectionStartupType" switch below to be the fully-qualified name of a
  type which subclasses Microsoft.AspNetCore.DataProtection.SystemWeb.DataProtectionStartup.
  -->
  <add key="aspnet:dataProtectionStartupType" value="" />
</appSettings>

Введите пустое значение с именем созданного вами типа, производного от сборки. Если имя приложения — DataProtectionDemo, это будет выглядеть следующим образом.

<add key="aspnet:dataProtectionStartupType"
     value="DataProtectionDemo.MyDataProtectionStartup, DataProtectionDemo" />

Недавно настроенная система защиты данных теперь готова к использованию внутри приложения.