На моей машине возникла одна и та же проблема, потому что пружинный сервер прекратил отвечать.
1: - Чтобы перезапустить тип пружинного сервера в терминале
$: spring restart
2: - Попробуйте запустить генератор снова.
Если для вашего MachineKey установлено значение AutoGenerate, то ваши токены проверки и т. Д. Не сохранятся после перезапуска приложения - ASP.NET сгенерирует новый ключ при запуске, а затем не будет способен правильно расшифровывать токены.
Если вы часто это видите, я бы предложил:
1 sup> Лучший способ сделать это - использовать приложение с балансировкой нагрузки, которое потребует от вас установить статический MachineKey. Другой вариант - отключить сайт, поместив файл с именем app_offline.htm
в корень сайта, который переведет сайт в автономный режим и отобразит ваше сообщение - по крайней мере, пользователи будут ожидать, что что-то пойдет не так.
У меня была эта проблема, и чтобы исправить то, что вам нужно сделать, это добавить явный ключ машины в вашу веб-конфигурацию ...
<machineKey validationKey="D82960E6B6E9B9029D4CAB2F597B5B4AF631E3C182670855D25FBDE1BFAFE19EFDE92ABBD1020FC1B2AE455D5B5F8D094325597CE1A7F8B15173407199C85A16" decryptionKey="577404C3A13F154908D7A5649EEC8D7C8A92C35A25A3EC078B426BB09D426A71" validation="SHA1" decryption="AES" />
обеспечить его размещение в web.config в ...
<system.web>
На данный момент я выбрал решение, которое очищает файлы cookie, если выбрасывается исключение. Если исключение будет сгенерировано снова, я просто позволю этому случиться, как было.
Я пока не буду отмечать это как «ответ» в надежде, что у кого-то есть лучший ответ.
public static class MyAntiForgeryExtensions
{
// Methods
public static string MyAntiForgeryToken(this HtmlHelper helper)
{
return MyAntiForgeryToken(helper, null);
}
public static string MyAntiForgeryToken(this HtmlHelper helper, string salt)
{
string fragment;
string path = helper.ViewContext.HttpContext.Request.ApplicationPath;
try
{
fragment = helper.AntiForgeryToken(salt, null, path);
}
catch (HttpAntiForgeryException)
{
// okay, scrub the cookie and have another go.
string cookieName = GetAntiForgeryTokenName(path);
helper.ViewContext.HttpContext.Request.Cookies.Remove(cookieName);
fragment = helper.AntiForgeryToken(salt, null, path);
}
return fragment;
}
#region AntiForgeryData code that shouldn't be sealed
// Copied from AntiForgeryData since they aren't accessible.
internal static string GetAntiForgeryTokenName(string appPath) {
if (String.IsNullOrEmpty(appPath)) {
return "__RequestVerificationToken";
}
else {
return "__RequestVerificationToken_" + Base64EncodeForCookieName(appPath);
}
}
private static string Base64EncodeForCookieName(string s) {
byte[] rawBytes = Encoding.UTF8.GetBytes(s);
string base64String = Convert.ToBase64String(rawBytes);
// replace base64-specific characters with characters that are safe for a cookie name
return base64String.Replace('+', '.').Replace('/', '-').Replace('=', '_');
}
#endregion
}
Если я сделаю iisreset на моем веб-сервере. и пользователь продолжает свой сеанс, на котором они попадают под логин страница.
Нет причин для iisreset, чтобы привести пользователя к странице входа в систему. Если вы используете cookies для отслеживания аутентификационной информации и имеете приложение без статуса пользователя, пользователь должен оставаться аутентифицированным даже после перезагрузки сервера (конечно, если запрос сделан во время перезагрузки, он не будет выполнен).
На самом деле я обнаружил, что это работает в моем действии входа в систему:
public ActionResult LogOn()
{
formsAuthentication.SignOut();
Response.Cookies.Clear();
Session[SessionKeys.USER_SESSION_KEY] = null;
Session.Clear();
Session.Abandon();
return View();
}
Важной частью была: Response.Cookies.Clear ();
{{ 1}}