Il trucco iframe con cookie di terze parti di Safari non funziona più?


137

Quindi questa è l'ennesima vendetta della domanda "Come faccio a far funzionare i cookie di terze parti in Safari" ma lo sto chiedendo di nuovo perché penso che il campo di gioco sia cambiato, forse dopo febbraio 2012. Uno dei trucchi standard per ottenere il 3 ° i cookie di gruppo in Safari erano i seguenti: utilizzare un po 'di javascript per inviare a un iframe nascosto. (In passato) induceva Safari a pensare che l'utente avesse interagito con i contenuti di terze parti e quindi consentire l'impostazione dei cookie.

Penso che questa scappatoia sia stata chiusa a seguito del lieve scandalo in cui è stato rivelato che Google stava usando quel trucco con le sue pubblicità. Per lo meno, durante l'utilizzo di questo trucco non sono stato completamente in grado di impostare i cookie in Safari. Ho scoperto alcuni post su Internet casuali che sostenevano che Apple stesse lavorando per chiudere la scappatoia ma non ho trovato alcuna parola ufficiale.

Come fallback ho anche provato a ridisegnare il frame principale di terze parti in modo da dover fare clic su un pulsante prima che il contenuto si caricasse, ma anche quel livello di interazione diretta non è stato sufficiente per sciogliere il freddo cuore di Safari.

Qualcuno sa per certo se Safari ha davvero chiuso questa scappatoia? In tal caso, esistono altre soluzioni alternative (oltre a includere manualmente un ID sessione in ogni richiesta)?


21
Utilizzando un terzo iframe partito che ha bisogno di cookie è certamente non è , per definizione, un attacco di sicurezza! Gestiamo un webshop che viene utilizzato in un iframe su una moltitudine di domini diversi e abbiamo tutti i tipi di problemi con Safari negli ultimi tempi, quindi sono anche molto interessato alla risposta a questa (legittima) domanda.
martedì

14
Praticamente tutti coloro che costruiscono app di Facebook hanno questo problema con Safari. Le app di Facebook funzionano in un iframe e, per definizione, provengono tutte da terze parti. Ecco perché il supporto per Safari sulle app di Facebook è un po 'discutibile: non è possibile utilizzare i cookie.
gs hurley,

Non riesco a riprodurre questo problema su Safari 5.1.7. Accetta i cookie dalla mia app Facebook iframe con l'impostazione predefinita "nessun cookie di terze parti". Tuttavia Chrome 19.0.1084.46 con la stessa impostazione blocca il cookie.
Evgeny Shadchnev,

4
Chrome 19+ con l'opzione (per fortuna) non predefinita "Blocca cookie di terze parti e dati del sito" selezionata è / ancora più dura / dell'impostazione predefinita di Safari "Blocca cookie di terze parti e inserzionisti". In Chrome, anche se visiti un dominio di terze parti e hai impostato i cookie, questi non verranno trasmessi all'iframe. L'utente deve effettivamente aggiungere una "eccezione" per il tuo dominio nelle sue impostazioni di sicurezza di Chrome.
Aaron Gibralter,

Cosa intendi con febbraio 2012? C'è un cambiamento tecnico in Safari o un cambio di legge?
liquido

Risposte:


51

Volevo solo lasciare qui una soluzione di lavoro semplice che non richiede l'interazione dell'utente .

Come ho affermato in un post, ho scritto :

Fondamentalmente tutto ciò che devi fare è caricare la tua pagina su top.location, creare la sessione e reindirizzarla su Facebook.

Aggiungi questo codice nella parte superiore index.phpe imposta $page_urll'URL della scheda / app finale dell'applicazione e vedrai che l'applicazione funzionerà senza alcun problema.

<?php
    // START SAFARI SESSION FIX
    session_start();
    $page_url = "http://www.facebook.com/pages/.../...?sk=app_...";
    if (isset($_GET["start_session"]))
        die(header("Location:" . $page_url));

    if (!isset($_GET["sid"]))
        die(header("Location:?sid=" . session_id()));
    $sid = session_id();
    if (empty($sid) || $_GET["sid"] != $sid):
?>
   <script>
        top.window.location="?start_session=true";
    </script>
<?php
    endif;
    // END SAFARI SESSION FIX
?>

Nota: questo è stato creato per Facebook, ma in realtà funzionerebbe in qualsiasi altra situazione simile.


Modifica 20-dic-2012 - Mantenimento della richiesta firmata:

Il codice sopra non mantiene i dati di post delle richieste e perderai la richiesta firmata, se la tua applicazione si basa su una richiesta firmata non esitare a provare il seguente codice:

Nota: questo è ancora testato correttamente e potrebbe essere meno stabile della prima versione. L'uso a proprio rischio / feedback è apprezzato.

(Grazie a CBroe per avermi indicato la giusta direzione qui permettendo di migliorare la soluzione)

// Start Session Fix
session_start();
$page_url = "http://www.facebook.com/pages/.../...?sk=app_...";
if (isset($_GET["start_session"]))
    die(header("Location:" . $page_url));
$sid = session_id();
if (!isset($_GET["sid"]))
{
    if(isset($_POST["signed_request"]))
       $_SESSION["signed_request"] = $_POST["signed_request"];
    die(header("Location:?sid=" . $sid));
}
if (empty($sid) || $_GET["sid"] != $sid)
    die('<script>top.window.location="?start_session=true";</script>');
// End Session Fix

Grazie, funziona come un fascino ed è così facile da implementare nelle app esistenti :-)
SamiSalami

Quindi questo funziona fondamentalmente con un paio di reindirizzamenti, giusto?
Aaron Gibralter,

1
@hugoderhungrige sei il benvenuto, ho appena aggiunto una nuova versione, sentiti libero di provarlo se hai bisogno di mantenere la richiesta firmata sulle tue app.
Diogo Raminhos,

1
@CBroe Grazie mille per averlo sottolineato! Avevi ragione, funziona, dal momento che dalla seconda richiesta l'utente ha già avviato una sessione! Immagino che "il peggior cieco è colui che non vuole vedere".
Diogo Raminhos,

1
@Whiteagle Potete fornire un caso di prova che dimostri 1 e 2?
Gajus,

35

Hai detto che volevi che i tuoi utenti facessero clic su un pulsante prima che il contenuto venga caricato. La mia soluzione era quella di avere un pulsante per aprire una nuova finestra del browser. Quella finestra imposta un cookie per il mio dominio, aggiorna l'apri e quindi si chiude.

Quindi il tuo script principale potrebbe apparire come:

<?php if(count($_COOKIE) > 0): ?>
<!--Main Content Stuff-->
<?php else: ?>
<a href="/safari_cookie_fix.php" target="_blank">Click here to load content</a>
<?php endif ?>

Quindi safari_cookie_fix.php assomiglia a:

<?php
setcookie("safari_test", "1");
?>
<html>
    <head>
        <title>Safari Fix</title>
        <script type="text/javascript" src="/libraries/prototype.min.js"></script>
    </head>
    <body>
    <script type="text/javascript">
    document.observe('dom:loaded', function(){
        window.opener.location.reload();
        window.close();
    })
    </script>
    This window should close automatically
    </body>
</html>

Stavo pensando a qualcosa del genere. Funziona perfettamente. Lo carico insieme alla finestra di dialogo delle autorizzazioni. Grazie!
vwoelm,

Sembra che questo stia funzionando anche attorno alle impostazioni di Safari, e che, una volta che è noto, le conoscenze verranno messe al tappeto proprio come le altre "soluzioni". Sto cercando una soluzione completamente diversa, perché sta diventando abbastanza ovvio che i cookie di terze parti sono ora il diavolo, anche se utilizzati in modo appropriato.
LocalPCGuy

1
Questa soluzione ha funzionato per me, tuttavia, è necessario il popup? Potresti reindirizzare il tuo iframe alla pagina del safari, impostare il cookie, quindi reindirizzare di nuovo al gioco con le intestazioni di reindirizzamento? O hai bisogno del popup in modo che l'utente abbia una qualche forma di contatto diretto con il server?
Anthony Hastings,

questo ha funzionato bene; fortunatamente, la pressione di un pulsante per inizializzare questo non era un grosso problema nella mia app.
littlered

@LocalPCGuy Non sono così sicuro che verrà eliminato come le altre soluzioni perché richiede che un utente faccia effettivamente clic / interagisca con la pagina per non bloccare il popup. Questa soluzione proposta da Safari sembra funzionare bene: gli inserzionisti non saranno in grado di impostare segretamente i cookie tra domini e le app incorporate richiederanno l'interazione di un utente prima di poter impostare un cookie.
Aaron Gibralter,

15

Ho ingannato Safari con un .htaccess:

#http://www.w3.org/P3P/validator.html
<IfModule mod_headers.c>
Header set P3P "policyref=\"/w3c/p3p.xml\", CP=\"NOI DSP COR NID CUR ADM DEV OUR BUS\""
Header set Set-Cookie "test_cookie=1"
</IfModule>

E ha smesso di funzionare anche per me. Tutte le mie app stanno perdendo la sessione in Safari e stanno reindirizzando da Facebook. Dato che ho fretta di sistemare quelle app, sto attualmente cercando una soluzione. Vi terrò aggiornati.

Modifica (2012-04-06): Apparentemente Apple lo ha "riparato" con 5.1.4. Sono sicuro che questa è la reazione alla cosa di Google: "Si è verificato un problema nell'applicazione della sua politica sui cookie. I siti Web di terze parti potrebbero impostare i cookie se la preferenza" Blocca cookie "in Safari è stata impostata sull'impostazione predefinita di" Di terze parti e inserzionisti ". Http://support.apple.com/kb/HT5190


1
Apparentemente Apple lo ha "riparato" con 5.1.4. Sono sicuro che questa è la reazione alla cosa di Google: "Si è verificato un problema nell'applicazione della sua politica sui cookie. I siti Web di terze parti potrebbero impostare i cookie se la preferenza" Blocca cookie "in Safari è stata impostata sull'impostazione predefinita di" da terzi e gli inserzionisti". support.apple.com/kb/HT5190
vwoelm

1
Quindi penso che questo commento di vwoelm sia il più vicino alla risposta che stavo cercando. Innanzitutto, volevo la conferma che Apple ha definitivamente chiuso la scappatoia e il riferimento all'articolo di supporto Apple è proprio questo. La seconda parte della mia domanda riguarda comunque. Quali sono le opzioni disponibili per soluzioni alternative. Chiaramente, possiamo codificare gli ID di sessione come parametri GET / POST ma quali sono le altre opzioni. La memoria locale funziona in questo contesto? Cookie Flash?
gs hurley,

@vwoelm: questa è davvero la risposta che stavo cercando (ma non sperando). Se lo metti in una risposta anziché in un commento, ti assegnerò la generosità.
mscha

3
@gshurley Penso che l'invio di ID di sessione tramite parametri GET / POST sia l'unica opzione. È insicuro, ma Facebook ci costringe a servire comunque applicazioni canvas senza SSL. E oltre a cosa ottieni hackerando un'app di Facebook haha? Siamo in balia di Apple e sono attualmente in modalità crudele.
Hekevintran,

14

Nel tuo controller Ruby on Rails puoi usare:

private

before_filter :safari_cookie_fix

def safari_cookie_fix
  user_agent = UserAgent.parse(request.user_agent) # Uses useragent gem!
  if user_agent.browser == 'Safari' # we apply the fix..
    return if session[:safari_cookie_fixed] # it is already fixed.. continue
    if params[:safari_cookie_fix].present? # we should be top window and able to set cookies.. so fix the issue :)
      session[:safari_cookie_fixed] = true
      redirect_to params[:return_to]
    else
      # Redirect the top frame to your server..
      render :text => "<script>alert('start redirect');top.window.location='?safari_cookie_fix=true&return_to=#{set_your_return_url}';</script>"
    end
  end
end

C'è un problema simile con le sessioni in Safari?
Principiante di Rails il

puoi sostituire set_your_return_url in request.env ['HTTP_REFERER'] poiché siamo all'interno di un iframe :-D
Luc Boissaye,

Ho provato questa soluzione e l'unico problema è che non posso tornare all'URL iframe principale. Esiste un metodo in Rails per ottenere l'URL dell'iframe principale? grazie
idejuan,

Mi ci è voluto del tempo ma alla fine ho capito che il modo più semplice (TMO) è semplicemente aggiungerlo come parametro di stringa di query all'URL di reindirizzamento dell'app rails. Wasy e pulito.
Guyaloni,

1
Questa risposta crea un redirector aperto, che è un problema di sicurezza comune. Il codice pericoloso è redirect_to params[:return_to]. Tale parametro deve essere verificato rispetto a una whitelist di luoghi sicuri a cui reindirizzare. Vedi owasp.org/index.php/…
phylae

13

Per la mia situazione specifica ho risolto il problema utilizzando window.postMessage () ed eliminando qualsiasi interazione dell'utente. Nota che funzionerà solo se puoi in qualche modo eseguire js nella finestra principale. O includendolo includendo un js dal tuo dominio o se hai accesso diretto alla fonte.

Nell'iframe (dominio-b) controllo la presenza di un cookie e, se non impostato, invierà un postMessage al genitore (dominio-a). Per esempio;

if (navigator.userAgent.indexOf('Safari') != -1 && navigator.userAgent.indexOf('Chrome') == -1
    && document.cookie.indexOf("safari_cookie_fix") < 0) {
    window.parent.postMessage(JSON.stringify({ event: "safariCookieFix", data: {} }));
}

Quindi, nella finestra principale (dominio-a), ascolta l'evento.

if (typeof window.addEventListener !== "undefined") {
    window.addEventListener("message", messageReceived, false);
}

function messageReceived (e) {
    var data;

    if (e.origin !== "http://www.domain-b.com") {
        return;
    }

    try {
        data = JSON.parse(e.data);
    }
    catch (err) {
        return;
    }

    if (typeof data !== "object" || typeof data.event !== "string" || typeof data.data === "undefined") {
        return;
    }

    if (data.event === "safariCookieFix") {
        window.location.href = e.origin + "/safari/cookiefix"; // Or whatever your url is
        return;
    }
}

Infine sul tuo server (http://www.domain-b.com/safari/cookiefix) imposti il ​​cookie e reindirizzi da dove proviene l'utente. L'esempio seguente utilizza ASP.NET MVC

public class SafariController : Controller
{
    [HttpGet]
    public ActionResult CookieFix()
    {
        Response.Cookies.Add(new HttpCookie("safari_cookie_fix", "1"));

        return Redirect(Request.UrlReferrer != null ? Request.UrlReferrer.OriginalString : "http://www.domain-a.com/");
    }

}

Non ricevi un errore di sintassi con la tua chiamata a postMessage?
Akousmata,

È necessario aggiungere un secondo parametro "*"per PostMessagecorreggere l'errore di sintassi
Michael Baldry,

Vorrei poter dare a questa risposta più voti. È il modo più semplice e corretto per affrontare effettivamente questo problema. Grazie per averlo pubblicato!
AaronP

9

Ho avuto lo stesso problema e oggi ho trovato una soluzione che funziona bene per me. Se l'agente utente contiene Safarie non sono impostati cookie, reindirizzo l'utente alla finestra di dialogo OAuth:

<?php if ( ! count($_COOKIE) > 0 && strpos($_SERVER['HTTP_USER_AGENT'], 'Safari')) { ?>
<script type="text/javascript">
    window.top.location.href = 'https://www.facebook.com/dialog/oauth/?client_id=APP_ID&redirect_uri=MY_TAB_URL&scope=SCOPE';
</script>
<?php } ?>

Dopo l'autenticazione e la richiesta di autorizzazioni, la finestra di dialogo OAuth reindirizzerà al mio URI nella posizione superiore. Quindi è possibile impostare i cookie. Per tutte le nostre app per la tela e la scheda della pagina ho già incluso il seguente script:

<script type="text/javascript">
    if (top.location.href==location.href) top.location.href = 'MY_TAB_URL';
</script>

Quindi l'utente verrà reindirizzato nuovamente alla scheda della pagina Facebook con un cookie valido già impostato e la richiesta firmata verrà nuovamente inviata.


Ottimo lavoro su questo. Ho aggiornato il controllo dell'agente utente per assicurarmi che Chrome non fosse nell'agente utente poiché Chrome ha anche Safari nella stringa dell'agente utente. Il reindirizzamento alla pagina del tuo dominio, l'impostazione dei cookie necessari / la sessione iniziale e il reindirizzamento alla tua app su apps.facebook.com hanno funzionato come un fascino. Sembra sciocco, ma funziona bene. Grazie Sascha per l'informazione!
Mike,

7

Alla fine ho optato per una soluzione simile a quella fornita da Sascha, anche se con qualche piccola modifica, dato che sto impostando esplicitamente i cookie in PHP:

// excecute this code if user has not authorized the application yet
// $facebook object must have been created before

$accessToken = $_COOKIE['access_token']

if ( empty($accessToken) && strpos($_SERVER['HTTP_USER_AGENT'], 'Safari') ) {

    $accessToken = $facebook->getAccessToken();
    $redirectUri = 'https://URL_WHERE_APP_IS_LOCATED?access_token=' . $accessToken;

} else {

    $redirectUri = 'https://apps.facebook.com/APP_NAMESPACE/';

}

// generate link to auth dialog
$linkToOauthDialog = $facebook->getLoginUrl(
    array(
        'scope'         =>  SCOPE_PARAMS,
        'redirect_uri'  =>  $redirectUri
    )
);

echo '<script>window.top.location.href="' . $linkToOauthDialog . '";</script>';

Ciò che fa è verificare se il cookie è disponibile quando il browser è Safari. Nel passaggio successivo, ci troviamo nel dominio dell'applicazione, ovvero l'URI fornito come URL_WHERE_APP_IS_LOCATED sopra.

if (isset($_GET['accessToken'])) {

    // cookie has a lifetime of only 10 seconds, so that after
    // authorization it will disappear
    setcookie("access_token", $_GET['accessToken'], 10); 

} else {

  // depending on your application specific requirements
  // redirect, call or execute authorization code again
  // with the cookie now set, this should return FB Graph results

}

Quindi, dopo essere stato reindirizzato al dominio dell'applicazione, viene impostato esplicitamente un cookie e reindirizzo l'utente al processo di autorizzazione.

Nel mio caso (dal momento che sto usando CakePHP ma dovrebbe funzionare bene con qualsiasi altro framework MVC) sto richiamando di nuovo l'azione di accesso in cui l'autorizzazione FB viene eseguita un'altra volta, e questa volta ha esito positivo a causa del cookie esistente.

Dopo aver autorizzato l'app una volta, non ho avuto più problemi con l'app con Safari (5.1.6)

Spero che possa aiutare chiunque.


1
questo ha funzionato per me !! Grazie!! .. ho avuto questo problema con Safari 5.1.7 .... ora è risolto!
Khalizar,

5

Ho avuto questo problema su dispositivi con iOS. Ho creato un negozio integrabile in un normale sito Web utilizzando un iframe. In qualche modo, ad ogni pageload l'utente ha ottenuto un nuovo sessionid, con conseguente blocco degli utenti a metà del processo perché alcuni valori non erano presenti nella sessione.

Ho provato alcune delle soluzioni fornite in questa pagina, ma i popup non funzionano molto bene su un iPad e avevo bisogno della soluzione più trasparente.

L'ho risolto usando un reindirizzamento. Il sito Web che incorpora il mio sito deve prima reindirizzare l'utente al mio sito, quindi il frame superiore contiene l'URL al mio sito, dove imposto un cookie e reindirizza l'utente alla pagina corretta sul sito Web che incorpora il mio sito, che viene passato attraverso l'URL.

Esempio di codice PHP

Il sito Web remoto reindirizza l'utente a

http://clientname.example.com/init.php?redir=http://www.domain.com/shop/frame

init.php

<?php
// set a cookie for a year
setcookie('initialized','1',time() + 3600 * 24 * 365, '/', '.domain.com', false, false);
header('location: ' . $_GET['redir']);
die;

L'utente finisce su http://www.domain.com/shop/framedove è incorporato il mio sito, memorizzando le sessioni come dovrebbe e mangiando i cookie.

Spero che questo aiuti qualcuno.


3

Vorrei condividere la mia correzione in ASP.NET MVC 4. L'idea principale è come nella risposta corretta per PHP. Il prossimo codice aggiunto nel layout principale nell'intestazione vicino alla sezione degli script:

@if (Request.Browser.Browser=="Safari")
{
    string pageUrl = Request.Url.GetLeftPart(UriPartial.Path);
    if (Request.Params["safarifix"] != null && Request.Params["safarifix"] == "doSafariFix")
    {
        Session["IsActiveSession"] = true;
        Response.Redirect(pageUrl);
        Response.End();
    }
        else if(Session["IsActiveSession"]==null)
    {
        <script>top.window.location = "?safarifix=doSafariFix";</script>
    }
}

3

Questa soluzione si applica in alcuni casi - se possibile:

Se la pagina del contenuto iframe utilizza un sottodominio della pagina contenente l'iframe, il cookie non viene più bloccato.


Queste sono informazioni utili - proprio quello che stavo cercando. Anche se sono sicuro che molte persone non possono cambiare i domini, è quello che farò. Chiedi al sito in cui sto incorporando di creare un sottodominio <mycompany>. <theircompany> .com che si associa al mio IP e un VHost dalla mia parte per quel dominio e usa quell'URL nell'iFrame. Complicato, ma dovrebbe essere a prova di proiettile.
Elocution Safari

1
Questo può complicarsi se si utilizza https con il sottodominio, poiché il server del sottodominio avrà bisogno di un certificato SSL per corrispondere.
Roger Halliburton,

1

Google in realtà fa uscire il gatto dalla borsa su questo. Lo stavano usando da un po 'per accedere ai cookie di tracciamento. È stato risolto quasi immediatamente da Apple = \

post originale sul Wall Street Journal


Conosco la cosa di Google, ma in realtà non ho visto nulla di Apple che "risolve" (e rompeva metà di Internet). Hai qualche dettaglio a riguardo?
mscha

1

Ecco un po 'di codice che uso. Ho scoperto che se imposto qualsiasi cookie dal mio sito, i cookie funzionano magicamente nell'iframe da allora in poi.

http://developsocialapps.com/foundations-of-a-facebook-app-framework/

 if (isset($_GET['setdefaultcookie'])) {
        // top level page, set default cookie then redirect back to canvas page
        setcookie ('default',"1",0,"/");
        $url = substr($_SERVER['REQUEST_URI'],strrpos($_SERVER['REQUEST_URI'],"/")+1);
        $url = str_replace("setdefaultcookie","defaultcookieset",$url);
        $url = $facebookapp->getCanvasUrl($url);
        echo "<html>\n<body>\n<script>\ntop.location.href='".$url."';\n</script></body></html>";
        exit();
    } else if ((!isset($_COOKIE['default'])) && (!isset($_GET['defaultcookieset']))) {
        // no default cookie, so we need to redirect to top level and set
        $url = $_SERVER['REQUEST_URI'];
        if (strpos($url,"?") === false) $url .= "?";
        else $url .= "&";
        $url .= "setdefaultcookie=1";
        echo "<html>\n<body>\n<script>\ntop.location.href='".$url."';\n</script></body></html>";
        exit();
    }

1

Una versione leggermente più semplice in PHP di ciò che altri hanno pubblicato:

if (!isset($_COOKIE, $_COOKIE['PHPSESSID'])) {
    print '<script>top.window.location="https://example.com/?start_session=true";</script>';
    exit();
}

if (isset($_GET['start_session'])) {
    header("Location: https://apps.facebook.com/YOUR_APP_ID/");
    exit();
}

1

Ho trovato la risposta perfetta a questo, tutto grazie a un ragazzo di nome Allan che qui merita tutto il merito. ( http://www.allannienhuis.com/archives/2013/11/03/blocked-3rd-party-session-cookies-in-iframes/ )

La sua soluzione è semplice e facile da capire.

Sul server dei contenuti iframe (dominio 2), aggiungi un file chiamato startession.php a livello di dominio radice che contiene:

<?php
// startsession.php
session_start();
$_SESSION['ensure_session'] = true;
die(header('location: '.$_GET['return']));

Ora sul sito Web di livello superiore contenente l'iframe (dominio1), la chiamata alla pagina contenente l'iframe dovrebbe apparire come:

<a href="https://domain2/startsession.php?return=http://domain1/pageWithiFrame.html">page with iFrame</a>

E questo è tutto! Simples :)

Il motivo per cui funziona è perché stai indirizzando il browser a un URL di terze parti e gli stai dicendo di fidarti di esso prima di mostrare il contenuto all'interno di iframe.


0

Ho usato il parametro modificato del Whiteagle (aggiunto il parametro firmato_request al link) e ha funzionato bene per Safari, ma IE aggiorna costantemente la pagina in quel caso. Quindi la mia soluzione per Safari e Internet Explorer è:

$fbapplink = 'https://apps.facebook.com/[appnamespace]/';
$isms = stripos($_SERVER['HTTP_USER_AGENT'], 'msie') !== false;

// safari fix
if(! $isms  && !isset($_SESSION['signed_request'])) {

    if (isset($_GET["start_session"])) {
        $_SESSION['signed_request'] = $_GET['signed_request'];
        die(header("Location:" . $fbapplink ));

    }
    if (!isset($_GET["sid"])) {
        die(header("Location:?sid=" . session_id() . '&signed_request='.$_REQUEST['signed_request']));
    }
    $sid = session_id();
    if (empty($sid) || $_GET["sid"] != $sid) {
    ?>
    <script>
        top.window.location="?start_session=true";
    </script>
    <?php
    exit;
    }
}

// IE fix
header('P3P: CP="CAO PSA OUR"');
header('P3P: CP="HONK"');


.. later in the code

$sr = $_REQUEST['signed_request'];
if($sr) {
        $_SESSION['signed_request'] = $sr;
} else {
        $sr = $_SESSION['signed_request'];
}

0

Ho anche sofferto di questo problema, ma finalmente ho ottenuto la soluzione, inizialmente carica direttamente l'URL iframe nel browser come un piccolo popup quindi accedi solo ai valori della sessione all'interno dell'iframe.



-2

Ho deciso di sbarazzarmi della $_SESSIONvariabile tutti insieme e ho scritto un wrapper attorno a memcache per imitare la sessione.

Controlla https://github.com/manpreetssethi/utils/blob/master/Session_manager.php

Caso d'uso: nel momento in cui un utente atterra sull'app, archivia la richiesta firmata utilizzando Session_manager e poiché è nella cache, puoi accedervi da qualsiasi pagina d'ora in poi.

Nota: questo non funzionerà durante la navigazione privata in Safari poiché session_id si reimposta ogni volta che la pagina viene ricaricata. (Stupido Safari)


-9

Puoi risolvere questo problema aggiungendo l'intestazione come politica p3p .. ho avuto lo stesso problema su Safari, quindi dopo aver aggiunto l'intestazione sopra i file ha risolto il mio problema.

<?php
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
?>

Sei sicuro che funzioni (ancora) con l'ultima versione di Safari? Abbiamo avuto intestazioni P3P per anni, per IE, ma Safari è ancora rotto.
mscha

2
Prova a cancellare tutti i cookie e riprova. Il problema non si mostra se il tuo browser ha già dei cookie per il tuo sito iframed.
rmarscher,

Hmmm, non riesco nemmeno a far funzionare le intestazioni P3P. Funzionano comunque in IE!
Seth Brown,

2
Questo funzionava. Ma per la versione più recente di Safari no. Svuota la cache e riprova ....
chantheman,

2
Voglio affermare che questa soluzione funziona. assicurati di eliminare TUTTI i cookie su Safari. E poi prova questo.
dnuske,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.