Я играю с шаблоном aspnetboilerplate.com для ядра dotnet. Я пытаюсь развернуть шаблон на сервере общего хостинга (windows) под управлением Plesk (обратите внимание, я вообще не могу управлять сервером).
Шаблон отлично работает локально, может входить в систему, добавлять пользователей, роли и т. Д. При его развертывании на сервере общего хостинга возникли некоторые проблемы, но это было решено относительно быстро (при настройке ядра dotnet и пришлось перейти на ядро dotnet 2.1 как 2.2 пока не поддерживается на сервере).
Проблема теперь в том, что после входа в систему я снова перенаправил на страницу входа. У меня была похожая проблема с ASP.NET MVC5, но предоставление машинного ключа в web.config и использование базы данных для данных сеанса устранило эту проблему. Поэтому я полагаю, что та же проблема с приложением dotnet.
Но поскольку ядро dotnet не использует машинные ключи и DataProtectionApis, необходим другой подход.
Итак, я попытался добавить services.AddDataProtection();
к StartUp.Configure()
Я прочитал Распределенное кеширование в ASP.NET Core и почти все ссылки там, а также пробовал несколько примеров кода, но либо я не знаю, что я делаю (высокая вероятность) или я что-то не так делаю.
Итак, как я могу предотвратить неожиданный выход пользователя из системы с помощью dotnet core 2.1 на сервере общего хостинга?
РЕДАКТИРОВАТЬ - 2019-01-25
Некоторая новая информация: попытался установить тайм-ауты, как предложено, но это либо ничего не делает, либо невозможно. Чтобы приложение dotnet работало на Plesk, мне пришлось отключить поддержку ASP.NET, чтобы ядро .NET получило пул приложений без управляемого кода. Попытка получить доступ к настройкам ASP.Net в Plesk (где у вас будет доступ к настройке пула приложений и т. Д.) Приводит к ошибке «Поддержка ASP.NET для этого веб-сайта».
Единственное, чего не происходит, это то, что папка App_Data / Logs никогда не создается при публикации. Мне пришлось вручную создавать и устанавливать разрешения, чтобы log4net мог создать файл журнала. Файл журнала предоставил мне дополнительную информацию:
ERROR 2019-01-25 09:33:03,005 [6 ] .Antiforgery.Internal.DefaultAntiforgery - An exception was thrown while deserializing the token.
Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException: The antiforgery token could not be decrypted. ---> System.Security.Cryptography.CryptographicException: The key {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} was not found in the key ring.
Поиск этой ошибки только еще раз привел меня к документации о добавлении services.AddDataProtection()
к методу ConfigureServices, но это напоминает о хранилищах ключей Azure (или других внешних провайдерах) или записи информации в общий UNC, чтобы другие серверы могли получить доступ к кэшированной ключевой информации (и это, вероятно, то, что мне нужно). Но, поскольку все эти опции мне недоступны, я нашел метод расширения, который позволяет хранить ключ на сервере MSSQL. Занят, настраивая это сейчас, чтобы проверить.
Если кто-то хочет высказать свое мнение, пожалуйста, будьте моим гостем.
ОБНОВЛЕНИЕ 2 - 2019-01-25 - УСПЕХ (на данный момент)
Похоже, что использование DataProtectionAPI - это путь. Журналы пока не сообщают о AntiforgeryValidationException
. Я собираюсь дать ему поработать некоторое время, и если все будет хорошо, я опубликую решение и как оно было реализовано.