Safari 플랫 아웃을 사용하면 부모 도메인과 다른 도메인의 iframe에서 쿠키를 설정할 수 없으므로 서버 측 CORS 헤더가 손상됩니다.
명확히하기 위해 : 사용자는 domainA.com에 있습니다. domainB.com 용 iframe이 열려 있고 iframe 내의 domainB.com에서 사용자를 인증하려고합니다. Set-Cookie 헤더는 필요한 모든 헤더와 함께 domainB.com iframe 내의 서버에서 반환되지만 Safari는 후속 호출에서 헤더를 다시 보내지 않습니다.
오래된 해결 방법은 iframe에서 양식 제출을 수행하고 응답에 쿠키를 설정했습니다. 그들은 사용자가 양식을 제출하기 위해 무언가를 클릭하고 있다는 사실을 좋아했다고 생각합니다. 양식 제출에는 콜백이 없으므로 HttpOnly 쿠키의 경우에는 할 수 없었지만 쿠키가 작동하지 않았기 때문에 응답이 언제 왔는지 확인하기 위해 쿠키를 폴링해야합니다. 그렇지 않을 때까지.
그런 다음 최신 해결 방법은 새로운 창 / 탭에서 사용자를 iframe 도메인으로 리디렉션하여 거기에 임의 쿠키를 설정 한 후 해당 하위 도메인이 iframe 내부에서 "신뢰"되었습니다. 다시 한 번 클릭하여 새 창 / 탭을 열어야했으며 새 탭 열기를 시각적으로 표시하기까지했습니다. 많은 보안, 표준.
이제 Safari 13부터는 더 이상 해결 방법이 없습니다. 더 이상 안전한 iframe 쿠키 설정이 없습니다
다른 인증 체계는 우리에게 좋지 않습니다 (예 : Auth-X 헤더). 자바 스크립트 클라이언트 측에서 토큰에 액세스 할 수 없도록하기 위해 HttpOnly 보안 쿠키를 사용해야합니다.
분명히 모든 것이 다른 브라우저에서 훌륭하게 작동합니다.
누구든지 제안이 있습니까?
편집하다:
@tomschmidt 링크에 감사드립니다. 올바른 방향으로 보입니다. Apple의 Storage Access API를 사용해 보았지만 불행히도 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();여전히 / login API 응답에서 수신 된 쿠키는 후속 호출에서 API에 전송되지 않습니다.