Safari 13+ iframe блокирует файлы cookie CORS - PullRequest
9 голосов
/ 13 января 2020

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

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

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

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

А теперь, начиная с Safari 13 - больше нет обходного пути. Больше нет безопасного iframe cook ie setting ?

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

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

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

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

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

Спасибо для ссылки @tomschmidt это кажется правильным направлением. Я пытался использовать API-интерфейс Apple Storage Access, но, к сожалению, хотя я и запрашиваю доступ, прежде чем инициализировать мои логины для входа в систему c с помощью 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, полученные на / login Ответ API не отправляется при последующих вызовах API: (

Ответы [ 2 ]

1 голос
/ 15 января 2020

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

0 голосов
/ 08 апреля 2020

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...