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"
в выборку устранило проблему.
В заключение
Это была сложная изолированная ошибка, которую нужно было отследить и исправить, тем более, что в некоторой документации по учетным данным для выборки предполагается, что они применимы только к запросам из разных источников. Надеюсь, пока вы читаете это, мы избавили вас от нескольких часов путаницы.