Chrome не будет перенаправлять обратно на URL после обработки аутентификации - PullRequest
1 голос
/ 13 февраля 2020

Как минимум пару лет я использую код, подобный этому, в моих MVC решениях ...

[Authorize]
public class HomeController : Controller
{
    [HttpGet]
    public ActionResult Index()
    {
          ..........

Затем в моем коде аутентификации

myAuthenticationProperties = new Microsoft.Owin.Security.AuthenticationProperties();
myAuthenticationProperties.AllowRefresh = true;
myAuthenticationProperties.ExpiresUtc = DateTime.UtcNow.AddMinutes(60); 
myAuthenticationManager.SignIn(myAuthenticationProperties, myClaimsIdentity);

return RedirectToAction("Index", "Home");

И в моем стартапе ..

    public void Configuration(IAppBuilder app)
    {
        CookieAuthenticationOptions myAuthOptions = new CookieAuthenticationOptions();
        myAuthOptions.AuthenticationType = "ApplicationCookie";               
        myAuthOptions.CookieHttpOnly = true; 
        myAuthOptions.SlidingExpiration = true; 
        myAuthOptions.LoginPath = new PathString("/Authentication/LogIn");

        //This is what was added for the Owin cookie "fix"
        myAuthOptions.CookieSameSite = SameSiteMode.Strict;                                 
        myAuthOptions.CookieSecure = CookieSecureOption.Always;


        app.UseCookieAuthentication(myAuthOptions);
    }

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

Затем у меня был прорыв, я попытался использовать IE и Edge, и кажется, работать каждый раз. Только Chrome зависает и делает это как минимум 75% времени, если не больше.

** ОБНОВЛЕНИЕ **

Я использовал Fiddler и Chrome Debugging ( Вкладки «Консоль» и «Сеть») и когда происходит RedirectToAction, то, что касается веб-сайта, это делается. Однако ничто, и я ничего не имею в виду, возвращается в сеть к моему клиенту (согласно Fiddler и Chrome 's Networking).

Тем не менее, если я вручную изменю URL-адрес на go дома, Chrome счастлив, теперь я прошел проверку подлинности, и мой [Authorize] теперь позволяет загружать контроллер.

Я изучил новую вещь Chrome cook ie, и хотя "fix" Кажется, это так же ясно, как грязь, я смог найти кого-то, кто использовал код, чтобы заставить повара SameSite ie сообщить что-то, кроме LAX. Я реализовал это, фактически установив его на «Строгий» и все еще .... Chrome Зависает.

** Бинты **

Я не знаю сколько время это собирается купить меня, но я решил проблему с помощью таймера Javascript, который, когда пользователь нажимает кнопку отправки, запускается таймер, ждет 6 секунд, а затем перенаправляет обратно в Home / Index.

Если проблема не существует (IE, Edge), Клиент перенаправляет автоматически, прежде чем таймер получит шанс завладеть им. Если они используют Chrome и он решает зависнуть, через 6 секунд он будет вести себя так, как будто их браузер работает медленно, и также доставит их в правильное место.

** Исправлено (возможно) **

Таким образом, даже несмотря на то, что нет сетевого трафика c, возвращающегося к клиенту, я закончил (в дополнение к описанному выше лейкопластырю), внеся некоторые дополнительные изменения, так что теперь и Owin, и Asp. net файлы cookie сообщают о безопасности и sameSite = Strict. Это, кажется, меняет мою проблему, и в тех случаях, когда она все еще хочет зависнуть, мой таймер перенаправления завершает проблему.

Для тех, кто также может испытать эту странность, суть Cook ie это исправить ...

  1. Обновите пакеты Owin, чтобы убедиться, что вы используете версию 4.1
  2. Настройте параметры CookieAuthenticationOptions в файле Startup.cs для добавленных мной элементов. выше, чтобы сделать Owin cook ie совместимым.
  3. Обновите следующее в вашем Web.config, чтобы сделать ваш Asp. net cook ie совместимым

    <system.web>
       <sessionState cookieSameSite="Strict" />
       <httpCookies requireSSL="true" />
    </system.web>
    

Выполнение этих трех действий (наряду с запуском вашего проекта по протоколу SSL) приведет к Chrome сообщению обо всех файлах cookie как безопасных и строгих.

1 Ответ

0 голосов
/ 13 февраля 2020

Google внес изменение в , как Chrome обрабатывает файлы cookie без атрибута SameSite. Раньше Chrome обрабатывал отсутствие атрибута SameSite, установленного для повара ie, так же, как и SameSite=None, что означало, что браузер будет принимать все файлы cookie. Теперь они воспринимают это как наличие SameSite=Lax, которое будет принимать куки только с того же домена. Чтобы получить тот же эффект, что и у старого метода, атрибут должен быть установлен как SameSite=None; Secure.

Я не могу сказать, влияет ли это на вас, но если это так, вы увидите ошибку в консоли Chrome.

imageSameSite console warning.">

Официальный релиз состоялся 4 февраля IIR C, но они проводят поэтапное развертывание, чтобы судить возникающие проблемы.

Некоторые ресурсы:
Microsoft ASP. NET блог о предстоящих изменениях / Архивная копия
Блог Chromium / Архивная копия

...