tl; dr Учетные данные для выборки по умолчанию изменены в Chrome / 68 и имеют значение для тех же исходных запросов.

Недавно мы запустили наш новый портал, позволяющий пользователям входить в систему и просматривать свое состояние. Процесс входа в систему довольно стандартный; пользователь вводит свой адрес электронной почты и пароль, и приложение отправляет их на сервер, который, если он действителен, отвечает, устанавливая файл cookie с токеном сеанса. Мы протестировали это в Chrome, Firefox и Safari, и это сработало, поэтому мы отправили его.

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

К счастью, у нас были журналы, которые мы могли проверить, и мы заметили, что эти сбои при входе в систему были связаны с браузерами, которые мы не проверяли ...SamsungBrowser/9.2 Chrome/67.0.3396.87..., ...Silk/66.2.10 like Chrome/66.0.3359.126... и другие. Оказывается, браузер Samsung занимает 4% рынка Великобритании, что немного больше, чем Firefox, поэтому мы сосредоточились на Samsung. К счастью, у нас есть телефон Samsung, и мы можем подтвердить то, что видят наши пользователи.

Тестирование в браузере Samsung показало, что вход в систему будет успешным, но файл cookie сеанса не будет установлен. Сначала мы предположили, что Samsung неправильно идентифицирует наш файл cookie как сторонний и блокирует его, но ничто из того, что мы пробовали или читали, не подтверждали это. Затем мы столкнулись с этим вопросом о переполнении стека, который вызвал резонанс, поскольку наш логин был запросом ajax с использованием API выборки,

await fetch(
    "/v0/login/",
    headers: {                                                                                                                              
      Accept: "application/json",                                                                                                           
      "Content-Type": "application/json",                                                                                                   
    },
    body: JSON.stringify({ email, password }),
    method: "POST",
)

Предложенный ответ заключался в том, чтобы добавить credentials: "same-origin" в выборку, чтобы разрешить отправку и получение файлов cookie. Тем не менее, это значение по умолчанию, что подтверждается в MDN. Это также казалось несвязанным, поскольку свойство учетных данных всегда документируется с точки зрения запросов из разных источников, тогда как наш вход был на тот же сайт.

После разочарований при чтении и поиске того, влияют ли учетные данные для получения на те же запросы происхождения, мы обнаружили, что в Chrome 68 значение по умолчанию было изменено с omit на same-origin. Из этого ясно, в чем была проблема: наши пользователи использовали последнюю версию браузера Samsung, но этот браузер был построен на устаревшем Chrome (Chrome 67), для которого по умолчанию установлено значение omit. Добавление credentials: "same-origin" в выборку устранило проблему.

В заключение

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