2017-02-10 4 views
2

Я занимаюсь этим несколько дней и не вижу, что я делаю неправильно. Я был бы признателен, если кто-то может показать мне, что я делаю неправильно.Почему AspNet Core IDataProtection Azure Storage с использованием внутреннего ключа

Я прошел через несколько итераций. Это то, что я сейчас имею, что не работает.

Startup.cs

var creds = new StorageCredentials(settings.CloudStorageAccount, settings.CloudStorageKey); 
var account = new CloudStorageAccount(creds, true); 
var blobClient = account.CreateCloudBlobClient(); 
var container = blobClient.GetContainerReference($"{dpsFolder}-{_env.EnvironmentName}".ToLower()); 
container.CreateIfNotExistsAsync().GetAwaiter().GetResult(); 
services.AddDataProtection() 
     .SetApplicationName(settings.ApplicationName) 
     .PersistKeysToAzureBlobStorage(container, dpsFileName); 

контроллер т е р

public ExternalSettingController([FromServices] IExternalSettingRepo repo, 
           [FromServices] IOptions<AppSettings> opts, 
           [FromServices] ILogger<ExternalSettingController> logger, 
           [FromServices] IHostingEnvironment env, 
           [FromServices] IDataProtectionProvider dpp) 
     : base(opts, repo, logger) 
    { 
     _dataProtector = dpp.CreateProtector("blah.Integration"); 

    } 

Фактический вызов в Получ

toReturn.Plain = _dataProtector.Unprotect(found.SettingValue); 

Все, кажется, сработал хорошо, как лучше, как я могу сказать, через отладчик. Настройки верны. Когда вызов Unprotect сделан, система выбирает использовать один из ключей из C: \ Users \ blah \ AppData \ Local \ ASP.NET \ DataProtection-Keys вместо одного, загруженного в хранилище Azure Blob.

Немного фона, поскольку это может повлиять на вещи. Я изначально создал отдельный класс DataProtectionService, который шифровал с помощью IDataProtection, используя ключ, который я поддерживал для проекта. Это не устанавливается в читаемом месте на Azure, поэтому мне пришлось переключаться там, где он хранится. Это ключевой момент в Azure Storage. Данные, которые я пытаюсь расшифровать, были первоначально зашифрованы, когда один и тот же ключ хранился локально.

Что я делаю неправильно?

ответ

2

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

Это не объясняет проблему. Вот объяснение в надежде, что это поможет кому-то еще с течением времени:

Когда-то все переключилось на работу под Azure Blob Storage. Подсистема защиты данных добавила второй ключ к файлу keys.xml на Azure. Этот ключ попал внутрь начального элемента <key>. Он создал вложенный элемент <key> внутри корневого элемента <key>. По неизвестной причине, возможно, ошибка, код ключа в Data Protection затем проигнорировал элемент root <key>, который представляет необходимый мне ключ и загружает только вложенный элемент <key>.

Чтобы решить эту проблему, я включил их. Новый созданный теперь является корневым ключом, а старший - вложенным ключом. При этом правильная клавиша загрузилась, и теперь все счастливы.

+0

@ Mr Lister благодарит за изменения. –

 Смежные вопросы

  • Нет связанных вопросов^_^