¿El truco de iframe de cookies de terceros de Safari ya no funciona?

137

Esta es la enésima venganza de la pregunta "¿Cómo puedo hacer que las cookies de terceros funcionen en Safari?", Pero vuelvo a preguntar porque creo que el campo de juego ha cambiado, quizás después de febrero de 2012. Uno de los trucos estándar para obtener la tercera las cookies de fiesta en Safari fueron las siguientes: use algunos javascript para PUBLICAR en un iframe oculto. (Solía) engañar a Safari para que pensara que el usuario había interactuado con el contenido de terceros y luego permitir que se establecieran cookies.

Creo que esta laguna se ha cerrado a raíz del leve escándalo en el que se reveló que Google estaba usando ese truco con sus anuncios. Por lo menos, mientras uso este truco, no he podido configurar las cookies en Safari. Descubrí algunas publicaciones aleatorias en Internet que afirmaban que Apple estaba trabajando para cerrar la brecha pero no encontré ninguna palabra oficial.

Como alternativa, incluso intenté rediseñar el marco principal de terceros para que tuviera que hacer clic en un botón antes de que se cargara el contenido, pero incluso ese nivel de interacción directa no fue suficiente para derretir el frío y frío corazón de Safari.

Entonces, ¿alguien sabe con certeza si Safari realmente ha cerrado esta escapatoria? Si es así, ¿hay otras soluciones (además de incluir manualmente una ID de sesión en cada solicitud)?

gs hurley
fuente
21
¡Usar un iframe de un tercero que necesita cookies ciertamente no es, por definición, un ataque de seguridad! Tenemos una tienda web que se usa en un iframe en una multitud de dominios diferentes, y recientemente tenemos todo tipo de problemas con Safari, por lo que también estoy muy interesado en la respuesta a esta pregunta (legítima).
mscha
14
Casi todos los que crean aplicaciones de Facebook tienen este problema con Safari. Las aplicaciones de Facebook se ejecutan en un iframe y, por definición, todas provienen de terceros. Esta es la razón por la cual el soporte para Safari en las aplicaciones de Facebook es un poco irregular: no puede usar cookies.
GS Hurley
No puedo reproducir este problema en Safari 5.1.7. Acepta la cookie de mi iframe de la aplicación de Facebook con la configuración predeterminada "sin cookies de terceros". Sin embargo, Chrome 19.0.1084.46 con la misma configuración bloquea la cookie.
Evgeny Shadchnev
44
Chrome 19+ con la opción (afortunadamente) no predeterminada "Bloquear cookies de terceros y datos del sitio" marcada es / incluso más severa / que la configuración predeterminada "Bloquear cookies de terceros y anunciantes" de Safari. En Chrome, incluso si visita el dominio de terceros y tiene configuradas cookies, no se transmitirán al iframe. El usuario debe agregar una "excepción" para su dominio en su configuración de seguridad de Chrome.
Aaron Gibralter
¿Qué quieres decir con febrero de 2012? ¿Hay un cambio técnico en Safari o un cambio en la ley?
líquido el

Respuestas:

51

Solo quería dejar una solución de trabajo simple aquí que no requiera la interacción del usuario .

Como dije en una publicación que hice :

Básicamente, todo lo que necesita hacer es cargar su página en top.location, crear la sesión y redirigirla a Facebook.

Agregue este código en la parte superior de su index.phpy configúrelo $page_urlen la pestaña final de la aplicación / URL de la aplicación y verá que su aplicación funcionará sin ningún 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: Esto se hizo para Facebook, pero en realidad funcionaría en cualquier otra situación similar.


Edición 20-dic-2012 - Mantenimiento de la solicitud firmada:

El código anterior no mantiene los datos de publicación de solicitudes, y usted perdería la solicitud firmada, si su aplicación se basa en una solicitud firmada, no dude en probar el siguiente código:

Nota: Esto todavía se está probando correctamente y puede ser menos estable que la primera versión. Uso bajo su propio riesgo / Comentarios son apreciados.

(Gracias a CBroe por señalarme en la dirección correcta aquí permitiendo mejorar la solución)

// 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
Diogo Raminhos
fuente
Gracias, funciona de
maravilla
Entonces, este básicamente funciona con un par de redireccionamientos, ¿verdad?
Aaron Gibralter
1
@hugoderhungrige de nada, acabo de agregar una nueva versión, no dude en consultarla si necesita mantener la solicitud firmada en sus aplicaciones.
Diogo Raminhos
1
@CBroe ¡Muchas gracias por señalarlo! Tenías razón, funciona, ya que en la segunda solicitud, ¡el usuario ya ha comenzado una sesión! Supongo que "el peor ciego es el que no quiere ver".
Diogo Raminhos
1
@Whiteagle ¿Puede proporcionar un caso de prueba que demuestre 1 y 2?
Gajus
35

Dijiste que estabas dispuesto a que tus usuarios hicieran clic en un botón antes de que se cargue el contenido. Mi solución fue hacer que un botón abriera una nueva ventana del navegador. Esa ventana establece una cookie para mi dominio, actualiza el abridor y luego se cierra.

Entonces su script principal podría verse así:

<?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 ?>

Entonces safari_cookie_fix.php se ve así:

<?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>
drewrichards
fuente
Estaba pensando en algo así. Funciona perfectamente. Lo cargo junto con el diálogo de permiso. ¡Gracias!
vwoelm
Parece que esto también está funcionando en torno a la configuración de Safari, y eso, una vez que sea de conocimiento común, será eliminado como las otras "soluciones". Estoy buscando una solución completamente diferente, porque se está volviendo bastante obvio que las cookies de terceros ahora son el demonio, incluso cuando se usan de manera adecuada.
LocalPCGuy
1
Esta solución funcionó para mí, sin embargo, ¿es necesaria la ventana emergente? ¿Podrías redirigir tu iframe a la página de safari, configurar la cookie y luego volver a dirigir el juego con encabezados de redireccionamiento? ¿O necesita la ventana emergente para que el usuario tenga algún tipo de contacto directo con el servidor?
Anthony Hastings
esto funcionó bien; Afortunadamente, presionar un botón para inicializar esto no fue un gran problema en mi aplicación.
littlered
@LocalPCGuy No estoy tan seguro de que se elimine como otras soluciones porque requiere que un usuario realmente haga clic / interactúe con la página para que no se bloquee la ventana emergente. Parece que esta solución que ha creado Safari funciona bien: los anunciantes no podrán establecer en secreto cookies entre dominios, y las aplicaciones integradas requerirán que un usuario interactúe antes de poder configurar una cookie.
Aaron Gibralter
15

Engañé a 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>

Y dejó de funcionar para mí también. Todas mis aplicaciones están perdiendo la sesión en Safari y están redirigiendo fuera de Facebook. Como tengo prisa por arreglar esas aplicaciones, actualmente estoy buscando una solución. Te mantendré informado.

Editar (2012-04-06): Aparentemente Apple lo "arregló" con 5.1.4. Estoy seguro de que esta es la reacción al asunto de Google: "Existía un problema en la aplicación de su política de cookies. Los sitios web de terceros podrían establecer cookies si la preferencia" Bloquear cookies "en Safari estaba configurada en la configuración predeterminada" De terceros y anunciantes ". Http://support.apple.com/kb/HT5190

vwoelm
fuente
1
Aparentemente, Apple lo "arregló" con 5.1.4. Estoy seguro de que esta es la reacción al asunto de Google: "Existía un problema en la aplicación de su política de cookies. Los sitios web de terceros podrían establecer cookies si la preferencia" Bloquear cookies "en Safari estaba configurada en la configuración predeterminada de" de terceros y anunciantes". support.apple.com/kb/HT5190
vwoelm
1
Así que creo que este comentario de vwoelm es el más cercano a la respuesta que estaba buscando. En primer lugar, quería confirmación de que Apple cerró definitivamente la escapatoria y la referencia al artículo de soporte de Apple es solo eso. La segunda parte de mi pregunta aún es pertinente. ¿Cuál es el rango de opciones para soluciones alternativas? Claramente, podemos codificar ID de sesión como parámetros GET / POST pero cuáles son las otras opciones. ¿El almacenamiento local funciona en este contexto? ¿Flash cookies?
gs hurley
@vwoelm: esa es la respuesta que estaba buscando (pero no esperaba). Si pones esto en una respuesta en lugar de un comentario, te asignaré la recompensa.
mscha
3
@gshurley Creo que enviar ID de sesión a través de los parámetros GET / POST es la única opción. Es inseguro, pero de nuevo Facebook nos obliga a servir aplicaciones de lienzo sin SSL de todos modos. Y además, ¿qué obtienes realmente al hackear una aplicación de Facebook jaja? Estamos a merced de Apple y actualmente están en modo cruel.
hekevintran
14

En su controlador Ruby on Rails puede usar:

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
joost
fuente
¿Hay un problema similar con las sesiones de safari?
Rails principiante
puede reemplazar set_your_return_url por request.env ['HTTP_REFERER'] ya que estamos dentro de un iframe :-D
Luc Boissaye
He probado esta solución, y el único problema es que no puedo volver a la URL del iframe principal. ¿Hay algún método en Rails para obtener la url del iframe principal? gracias
idejuan
Me tomó tiempo, pero finalmente descubrí que la forma más fácil (TMO) es simplemente agregarlo como un parámetro de cadena de consulta a la URL de redireccionamiento de la aplicación rails. Wasy y limpio.
guyaloni
1
Esta respuesta crea un redirector abierto, que es un problema de seguridad común. El código peligroso es redirect_to params[:return_to]. Ese parámetro debe verificarse en una lista blanca de lugares seguros a los que redirigir. Ver owasp.org/index.php/…
phylae
13

Para mi situación específica, resolví el problema usando window.postMessage () y eliminando cualquier interacción del usuario. Tenga en cuenta que esto solo funcionará si de alguna manera puede ejecutar js en la ventana principal. Ya sea que incluya un js de su dominio, o si tiene acceso directo a la fuente.

En el iframe (dominio-b) verifico la presencia de una cookie y, si no está configurada, enviaré un mensaje posterior al padre (dominio-a). P.ej;

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: {} }));
}

Luego, en la ventana principal (dominio-a), escuche el 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;
    }
}

Finalmente, en su servidor (http://www.domain-b.com/safari/cookiefix) configura la cookie y redirige de nuevo a donde vino el usuario. El siguiente ejemplo está usando 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/");
    }

}
Franco
fuente
¿No recibe un error de sintaxis con su llamada a postMessage?
akousmata
Necesito agregar un segundo parámetro "*"para PostMessagecorregir el error de sintaxis
Michael Baldry
Ojalá pudiera dar esta respuesta más votos a favor. Es la forma más simple y correcta de abordar este problema. ¡Gracias por publicarlo!
AaronP
9

Tuve el mismo problema y hoy encontré una solución que funciona bien para mí. Si el agente de usuario contiene Safariy no se configuran cookies, redirijo al usuario al cuadro de diálogo 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 } ?>

Después de la autenticación y solicitar permisos, el cuadro de diálogo OAuth redirigirá a mi URI en la ubicación superior. Por lo tanto, es posible configurar cookies. Para todas nuestras aplicaciones de lienzo y pestaña de página, ya he incluido el siguiente script:

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

Por lo tanto, el usuario será redirigido nuevamente a la pestaña de la página de Facebook con una cookie válida ya configurada y la solicitud firmada se publica nuevamente.

Sascha Galley
fuente
Gran trabajo en esto. Actualicé la verificación del agente de usuario para asegurarme de que Chrome no estuviera también en el agente de usuario, ya que Chrome también tiene Safari en la cadena del agente de usuario. Redirigir a la página de su dominio, configurar las cookies necesarias / iniciar sesión y luego redirigir nuevamente a su aplicación en apps.facebook.com funcionó de maravilla. Parece tonto, pero funciona bien. Gracias Sascha por el dato!
Mike
7

Finalmente busqué una solución similar a la que proporcionó Sascha, sin embargo con algunos pequeños ajustes, ya que configuro las cookies explícitamente en 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>';

Lo que esto hace es verificar si la cookie está disponible cuando el navegador es safari. En el siguiente paso, estamos en el dominio de la aplicación, es decir, el URI proporcionado como URL_WHERE_APP_IS_LOCATED arriba.

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

}

Entonces, después de redirigir al dominio de la aplicación, se establece una cookie explícitamente y redirijo al usuario al proceso de autorización.

En mi caso (ya que estoy usando CakePHP pero debería funcionar bien con cualquier otro marco MVC), estoy llamando a la acción de inicio de sesión nuevamente donde la autorización FB se ejecuta otra vez, y esta vez tiene éxito debido a la cookie existente.

Después de autorizar la aplicación una vez, no tuve más problemas para usar la aplicación con Safari (5.1.6)

Espero que eso pueda ayudar a cualquiera.

Marcel Kalveram
fuente
1
esto funciono para mi !! ¡¡Gracias!! ... estaba teniendo este problema con Safari 5.1.7 ... ¡ahora está resuelto!
Khalizar
5

Tuve este problema en dispositivos con iOS. Hice una tienda que se puede insertar en un sitio web normal usando un iframe. De alguna manera, en cada carga de página, el usuario obtiene un nuevo ID de sesión, lo que hace que los usuarios se atasquen a mitad del proceso porque algunos valores no estaban presentes en la sesión.

Probé algunas de las soluciones dadas en esta página, pero las ventanas emergentes no funcionan muy bien en un iPad y necesitaba la solución más transparente.

Lo resolví usando una redirección. El sitio web que incrusta mi sitio primero debe redirigir al usuario a mi sitio, por lo que el marco superior contiene la URL a mi sitio, donde configuro una cookie y redirijo al usuario a la página correcta en el sitio web que incrusta mi sitio, que se pasa a través de la url.

Ejemplo de código PHP

El sitio web remoto redirige al usuario 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;

El usuario termina http://www.domain.com/shop/framedonde está incrustado mi sitio, almacena las sesiones como debería y come cookies.

Espero que esto ayude a alguien.

ar34z
fuente
3

Permítanme compartir mi solución en ASP.NET MVC 4. La idea principal como en la respuesta correcta para PHP. El siguiente código agregado en el diseño principal en el encabezado cerca de la sección de scripts:

@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>
    }
}
Yara
fuente
3

Esta solución se aplica en algunos casos, si es posible:

Si la página de contenido del iframe usa un subdominio de la página que contiene el iframe, la cookie ya no está bloqueada.

maravilla de los ojos
fuente
Esta es información útil, justo lo que estaba buscando. Si bien estoy seguro de que la mayoría de las personas no pueden cambiar los dominios, eso es lo que voy a hacer. Haga que el sitio en el que estoy incrustando cree un subdominio <mycompany>. <theircompany> .com que se asigne a mi IP y un VHost de mi lado para ese dominio y use esa URL en el iFrame. Complicado, pero debe ser a prueba de balas.
Elocution Safari
1
Esto puede complicarse si está utilizando https con el subdominio, ya que el servidor del subdominio necesitará un certificado SSL para que coincida.
Roger Halliburton
1

Google realmente dejó al gato fuera de la bolsa en este caso. Lo usaron durante un tiempo para acceder a las cookies de seguimiento. Fue corregido casi de inmediato por Apple = \

publicación original del Wall Street Journal

Colin Godsey
fuente
Sé lo de Google, pero no he visto nada acerca de que Apple realmente "arregle" esto (y rompa la mitad de Internet). ¿Tienes algún detalle al respecto?
mscha 05 de
1

Aquí hay un código que uso. Descubrí que si configuro cualquier cookie de mi sitio, las cookies funcionan mágicamente en el iframe a partir de ese momento.

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();
    }
Tom Kincaid
fuente
1

Una versión ligeramente más simple en PHP de lo que otros han publicado:

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();
}
Charlie Schliesser
fuente
1

He encontrado la respuesta perfecta a esto, todo gracias a un tipo llamado Allan que merece todo el crédito aquí. ( http://www.allannienhuis.com/archives/2013/11/03/blocked-3rd-party-session-cookies-in-iframes/ )

Su solución es simple y fácil de entender.

En el servidor de contenido de iframe (dominio 2), agregue un archivo llamado opensession.php en el nivel de dominio raíz que contenga:

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

Ahora en el sitio web de nivel superior que contiene el iframe (dominio1), la llamada a la página que contiene el iframe debería verse así:

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

¡Y eso es! Simples :)

La razón por la que esto funciona es porque está dirigiendo el navegador a una URL de un tercero y, por lo tanto, le dice que confíe en él antes de mostrar contenido de él dentro del iframe.

usuario1351772
fuente
0

Utilicé el truco de Whiteagle modificado (agregué el parámetrofirmado_request al enlace) y funcionó bien para un safari, pero IE actualiza constantemente la página en ese caso. Entonces, mi solución para safari e Internet Explorer es:

$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'];
}
cotko
fuente
0

También he estado sufriendo este problema, pero finalmente obtuve la solución. Inicialmente, cargue directamente la URL del iframe en el navegador como una pequeña ventana emergente y luego solo acceda a los valores de la sesión dentro del iframe.

Karthik Keyan
fuente
-2

Decidí deshacerme de la $_SESSIONvariable todos juntos y escribí un contenedor alrededor de memcache para imitar la sesión.

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

Caso de uso: en el momento en que un usuario aterriza en la aplicación, almacena la solicitud firmada utilizando Session_manager y, dado que está en la caché, puedes acceder a ella desde cualquier página en adelante.

Nota: Esto no funcionará cuando navegue de forma privada en Safari ya que session_id se restablece cada vez que la página se recarga. (Estúpido Safari)

Manpreet Sethi
fuente
-9

Puede resolver este problema agregando el encabezado como política p3p ... Tuve el mismo problema en safari, así que después de agregar el encabezado en la parte superior de los archivos, resolvió mi problema.

<?php
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
?>
Madan
fuente
¿Estás seguro de que (todavía) funciona con la última versión de Safari? Hemos tenido encabezados P3P durante años, para IE, pero Safari todavía está roto.
mscha
2
Intente borrar todas sus cookies y pruebe nuevamente. El problema no se muestra si su navegador ya tiene cookies para su sitio iframed.
rmarscher
Hmmm, tampoco puedo hacer que funcionen los encabezados P3P. ¡Aún funcionan en IE!
Seth Brown
2
Esto solía funcionar. Pero para la versión más reciente de Safari no lo hace. Borre su caché e inténtelo de nuevo ....
chantheman
2
Quiero decir que esta solución funciona. asegúrese de ELIMINAR TODAS las cookies en safari. Y luego intenta esto.
dnuske