Safari 13+ iframe блокирует файлы cookie CORS

Использование Safari не позволяет устанавливать файлы cookie в фреймах доменов, отличных от родительского, и проклятые заголовки CORS на стороне сервера.

Чтобы уточнить: пользователь находится на domainA.com. Iframe для domainB.com открыт и пытается аутентифицировать пользователя на domainB.com внутри iframe. Заголовок Set-Cookie возвращается с сервера внутри iframe domainB.com со всеми необходимыми заголовками, но Safari не отправляет его обратно при последующих вызовах.

Старый обходной путь выполнял отправку формы из iframe и устанавливал cookie в ответе. Я предполагаю, что им понравилось то, что пользователь нажимал что-то, чтобы отправить форму. Вам нужно будет опросить файл cookie, чтобы узнать, когда ответ вернулся, поскольку отправленные формы не имеют обратных вызовов, а в случае файлов cookie HttpOnly вы не можете, но, эй, это сработало! Пока этого не произошло.

Затем, более поздний обходной путь - перенаправление пользователя на домен iframe в совершенно новом окне / вкладке, установка там случайного файла cookie, и с этого момента этот поддомен был «доверенным» внутри iframe. Опять же, для открытия нового окна / вкладки требовался щелчок, и даже была визуальная индикация открытия новой вкладки. Большая безопасность, такие стандарты.

И теперь, начиная с Safari 13 - больше нет обходного пути. Нет более безопасной настройки iframe cookie 🤬

Любая другая схема аутентификации нам не подходит (например, заголовок Auth-X). Нам нужно использовать безопасный HttpOnly cookie, так как мы не хотим, чтобы этот токен был каким-либо образом доступен для клиентской части javascript.

Чтобы было ясно, все прекрасно работает в любом другом браузере.

Соответствующий WebKit Bugzilla

У кого-нибудь есть предложения?

Редактировать:

Спасибо за ссылку @tomschmidt, это похоже на правильное направление. Я попытался использовать API-интерфейс Apple Storage Access, но, к сожалению, хотя я запрашиваю доступ перед инициализацией логики входа в систему с помощью API:

requestStorageAccess = async() => {
    return new Promise(resolve => {
      //@ts-ignore
      document.requestStorageAccess().then(
        function () {
          console.log('Storage access was granted');
          resolve(true);
        },
        function () {
          console.log('Storage access was denied');
          resolve(false);
        }
      );    
    });
  }


const storageAccessGranted = await requestStorageAccess();
console.log(storageAccessGranted) // prints 'true'
await login();

Тем не менее файлы cookie, полученные в ответе API / login, не отправляются при последующих вызовах API :(

Я думаю, что мог бы найти решение: API доступа к хранилищу Apple: https://webkit.org/blog/8124/introduction-storage-access-api/

Таким образом, обходной путь все еще работает, пока новое окно хранит куки, которые вы хотите сохранить. Iframe по-прежнему не может хранить свои собственные куки. В моем случае все, что мне было нужно, это cookie сессионного идентификатора. Итак, я открываю небольшое всплывающее окно, когда пользователь предоставляет доступ к хранилищу. Он получает и сохраняет cookie идентификатора сессии, закрывает и перезагружает iframe. Затем iframe имеет доступ к cookie-идентификатору сеанса и отправляет его в последующих запросах. Я думаю, что это только временно, похоже, они собираются удалить доступ к хранилищу из всплывающих окон в будущем. Возможно, они исправят iframe, не имея возможности хранить куки к тому времени.