Использование 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, не имея возможности хранить куки к тому времени.
источник