Safari 13+ iframe blocca i cookie CORS

Safari flat out non ti consente di impostare cookie in iframe di domini diversi dal dominio principale, le intestazioni CORS sul lato server devono essere dannate.

Per chiarire: l'utente è su domainA.com. Un iframe per domainB.com è aperto e tenta di autenticare l'utente su domainB.com all'interno dell'iframe. L'intestazione Set-Cookie viene restituita dal server all'interno dell'iframe domainB.com, con tutte le intestazioni richieste, ma Safari non lo restituisce nelle chiamate successive.

Una vecchia soluzione stava effettuando l'invio di un modulo dall'iframe e impostando il cookie nella risposta. Immagino che gli sia piaciuto il fatto che l'utente abbia fatto clic su qualcosa per inviare il modulo. Dovresti fare il polling per vedere il cookie quando la risposta è tornata, dato che l'invio del modulo non ha richiamate, e nel caso dei cookie HttpOnly non potresti, ma ehi, ha funzionato! Fino a quando non lo ha fatto.

Quindi, una soluzione più recente stava reindirizzando l'utente al dominio iframe in una nuova finestra / scheda, impostando un cookie casuale lì, e da quel momento in poi, quel sottodominio era "attendibile" all'interno dell'iframe. Ancora una volta, è stato richiesto un clic per aprire la nuova finestra / scheda e c'era anche un'indicazione visiva dell'apertura della nuova scheda. Molta sicurezza, tali standard.

E ora, a partire da Safari 13 - Non più soluzioni alternative. Niente più impostazioni sicure dei cookie iframe 🤬

Qualsiasi altro schema di autenticazione non è buono per noi (ad es. Intestazione Auth-X). Dobbiamo utilizzare un cookie sicuro di HttpOnly, poiché non vogliamo che quel token sia in alcun modo accessibile dal lato client javascript.

Per essere chiari, tutto funziona alla grande su qualsiasi altro browser.

Rilevante BugKilla WebKit

Qualcuno ha qualche suggerimento?

Modificare:

Grazie per il link @tomschmidt, che sembra la giusta direzione. Ho provato a utilizzare l'API di accesso allo storage di Apple, ma sfortunatamente, sebbene mi assicuri di richiedere l'accesso prima di inizializzare la mia logica di accesso con l'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();

Tuttavia, i cookie ricevuti sulla risposta dell'API / login non vengono inviati nelle chiamate successive all'API :(

Penso di aver trovato la soluzione: API di accesso allo storage di Apple: https://webkit.org/blog/8124/introducing-storage-access-api/

Quindi, la soluzione alternativa funziona ancora, purché la nuova finestra memorizzi il cookie che si desidera memorizzare. L'iframe non è ancora in grado di memorizzare i propri cookie. Nel mio caso, tutto ciò di cui avevo bisogno era il cookie ID sessione. Quindi, apro una piccola finestra popup quando l'utente concede l'accesso alla memoria. Ottiene e memorizza il cookie dell'ID sessione, chiude e ricarica l'iframe. L'iframe ha quindi accesso al cookie dell'ID sessione e lo invia nelle richieste successive. Penso che questo sia solo temporaneo, sembra che in futuro rimuoveranno l'accesso allo storage dalle finestre popup. Forse allora risolveranno l'iframe che non è in grado di memorizzare i cookie.