Вот рабочий процесс:
- Я отправляю электронное письмо клиенту. Это письмо содержит ссылку на мое приложение Angular:
acme.com?token=abcd - Пользователь нажимает на ссылку в письме и перенаправляется на мое приложение.
- Запрос GET выполнен. Заголовки этого ответа содержат
Set-Cookie XSRF:12345 - Затем, после ответа GET, выполняется запрос POST, предположительно с использованием предыдущего токена XSRF.
Проблема : в Safari / iPhone (и только в Safari / iPhone, работает в Safari / Ma c), повар ie не виден на стороне JS.
Напоминаем, что XSRF cook ie предназначен для чтения в JS и повторной вставки в заголовки HTTP последующих запросов POST / PUT / DELETE. В результате запрос POST отправляется без заголовка XSRF (но с обработкой XSRF ie) и заканчивается ошибкой 403. Все работает так, как будто повар ie был HttpOnly, но это не так!
Вот полная информация о Set-cookie:
Set-Cookie: XSRF=[...]; Expires=Thu, 23-Apr-2020 16:07:10 GMT; Path=/;SameSite=Strict;Secure
Я подозревал проблемы с SameSite политика, потому что пользователь заходит на сайт после нажатия на ссылку в электронном письме. Итак, я попытался добавить отскок: после нажатия пользователь теперь попадает на страницу acme.com/redirect.html?token=abcd, которая перенаправляет на acme.com?token=abcd (через window.location.href=...)
На самом деле, это работает ... но я не понимаю почему . Если это была проблема SameSite, почему бы XSRF cook ie по-прежнему отправляться? И, поскольку он не помечен как HttpOnly, почему я не могу прочитать его на стороне JS? Есть ли способ в Safari выяснить, почему повар ie отклонен? Кроме того, я обнаружил, что в некоторых версиях Safari могут быть ошибки с обработкой cook ie. Есть ли способ деактивировать политику SameSite в Safari / iPhone, чтобы понять, происходит ли она оттуда?