O truque de iframe de cookies de terceiros do Safari não está mais funcionando?

137

Portanto, esta é a décima terceira vingança da pergunta "como faço para que os cookies de terceiros funcionem no Safari", mas estou perguntando novamente porque acho que o campo de jogo mudou, talvez depois de fevereiro de 2012. Um dos truques padrão para obter terceiros Os cookies de terceiros no Safari foram os seguintes: use javascript para POST em um iframe oculto. Isso costumava induzir o Safari a pensar que o usuário havia interagido com o conteúdo de terceiros e, portanto, permitir a configuração de cookies.

Acho que essa brecha foi fechada na sequência do escândalo moderado em que foi revelado que o Google estava usando esse truque com seus anúncios. No mínimo, ao usar esse truque, fui completamente incapaz de definir cookies no Safari. Descobri algumas postagens aleatórias na Internet que afirmavam que a Apple estava trabalhando para fechar a brecha, mas não encontrei nenhuma palavra oficial.

Como alternativa, tentei redesenhar o principal quadro de terceiros para que você precisasse clicar em um botão antes do conteúdo carregar, mas mesmo esse nível de interação direta não era suficiente para derreter o coração frio do Safari.

Alguém sabe ao certo se o Safari realmente fechou essa brecha? Em caso afirmativo, existem outras soluções alternativas (além da inclusão manual de um ID de sessão em cada solicitação)?

javascript  facebook  iframe  safari 
— gs hurley
fonte
21
Usar um iframe de terceiros que precise de cookies certamente não é, por definição, um ataque de segurança! Executamos uma loja virtual usada em um iframe em vários domínios diferentes e temos todos os tipos de problemas com o Safari ultimamente. Por isso, também estou muito interessado na resposta a essa pergunta (legítima).
— mscha
14
Quase todo mundo que cria aplicativos do Facebook tem esse problema com o Safari. Os aplicativos do Facebook são executados em um iframe e, por definição, todos são de terceiros. É por isso que o suporte a aplicativos Safari no Facebook é um pouco irregular: você não pode usar cookies.
— gs Hurley
Não consigo reproduzir esse problema no safari 5.1.7. Ele aceita o cookie do meu aplicativo do facebook iframe com a configuração padrão "sem cookies de terceiros". No entanto, o Chrome 19.0.1084.46 com a mesma configuração bloqueia o cookie.
— Evgeny Shadchnev
4
O Chrome 19 ou superior com a opção "Bloquear cookies e dados do site" não padrão (felizmente) marcada é / ainda mais difícil / do que a configuração padrão "Bloquear cookies de terceiros e anunciantes" do Safari. No chrome, mesmo se você visitar o domínio de terceiros e definir cookies, eles não serão transmitidos ao iframe. O usuário deve realmente adicionar uma "exceção" ao seu domínio nas configurações de segurança do Chrome.
— Aaron Gibralter
O que você quer dizer com fevereiro de 2012? Existe uma mudança técnica no Safari ou uma mudança na lei?
— líquido

Respostas:

51

Só queria deixar aqui uma solução de trabalho simples que não exija interação do usuário .

Como afirmei em um post que fiz :

Basicamente, tudo o que você precisa fazer é carregar sua página em top.location, criar a sessão e redirecioná-la de volta ao facebook.

Adicione esse código na parte superior index.phpe defina $page_urlo URL final da guia / aplicativo do aplicativo e você verá que o aplicativo funcionará sem problemas.

<?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: Isso foi feito para o facebook, mas na verdade funcionaria em qualquer outra situação semelhante.

Edit 20-Dec-2012 - Manutenção da solicitação assinada:

O código acima não mantém os dados de postagem das solicitações, e você perderia o request_request, se o seu aplicativo se basear na solicitação assinada, sinta-se à vontade para tentar o seguinte código:

Nota: Isso ainda está sendo testado corretamente e pode ser menos estável que a primeira versão. Use por sua conta e risco / Feedback é apreciado.

(Obrigado a CBroe por me indicar a direção certa aqui, permitindo melhorar a solução)

// 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
fonte
Obrigado, funciona como um encanto e é tão fácil de implementar em aplicativos existentes :-)
— SamiSalami
Então este basicamente funciona com alguns redirecionamentos, certo?
— Aaron Gibralter
1
@hugoderhungrige de nada, acabei de adicionar uma nova versão, fique à vontade para conferir se precisar manter a solicitação assinada em seus aplicativos.
— Diogo Raminhos
1
@CBroe Muito obrigado por apontar isso! Você estava certo, funciona, já que pela segunda solicitação o usuário já iniciou uma sessão! Eu acho que "o pior cego é aquele que não quer ver".
— Diogo Raminhos
1
@Whiteagle Você pode fornecer um caso de teste demonstrando 1 e 2?
— Gajus
35

Você disse que queria que seus usuários clicassem em um botão antes que o conteúdo fosse carregado. Minha solução foi abrir um botão em uma nova janela do navegador. Essa janela define um cookie para o meu domínio, atualiza o abridor e depois fecha.

Portanto, seu script principal pode se parecer com:

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

Então safari_cookie_fix.php se parece com:

<?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
fonte
Eu estava pensando em algo assim. Funciona perfeitamente. Eu o carrego junto com a caixa de diálogo de permissão. Obrigado!
— vwoelm
Parece que isso também está funcionando nas configurações do Safari, e que, uma vez que o conhecimento comum seja interrompido, assim como as outras "soluções". Estou procurando uma solução completamente diferente, porque está se tornando bastante óbvio que os cookies de terceiros agora são o diabo, mesmo quando usados ​​de maneiras apropriadas.
— LocalPCGuy
1
Esta solução funcionou para mim, no entanto, o pop-up é necessário? Você poderia redirecionar seu iframe para a página do safari, definir o cookie e redirecionar novamente para o jogo com os cabeçalhos de redirecionamento? Ou você precisa do pop-up para que o usuário tenha alguma forma de contato direto com o servidor?
— Anthony Hastings
isso funcionou bem; felizmente, apertar um botão para inicializar isso não era grande coisa no meu aplicativo.
— Littlered
@LocalPCGuy Não tenho tanta certeza de que ele será desviado como outras soluções, pois exige que o usuário realmente clique / interaja com a página para que o pop-up não seja bloqueado. Essa solução criada pelo Safari parece funcionar bem: os anunciantes não poderão definir secretamente cookies entre domínios, e os aplicativos incorporados exigirão que o usuário interaja antes de poder definir um cookie.
— Aaron Gibralter
15

Enganei o Safari com um .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 também parou de funcionar para mim. Todos os meus aplicativos estão perdendo a sessão no Safari e redirecionando para fora do Facebook. Como estou com pressa de corrigir esses aplicativos, atualmente estou procurando uma solução. Vou mantê-lo informado.

Edit (06/04/2012): Aparentemente, a Apple "corrigiu" o 5.1.4. Tenho certeza de que esta é a reação à coisa do Google: "Havia um problema na imposição de sua política de cookies. Sites de terceiros poderiam definir cookies se a preferência" Bloquear cookies "no Safari estivesse definida como a configuração padrão de" De terceiros e anunciantes ". Http://support.apple.com/kb/HT5190

— vwoelm
fonte
1
Aparentemente, a Apple "consertou" com 5.1.4. Tenho certeza de que esta é a reação à coisa do Google: "Havia um problema na imposição de sua política de cookies. Sites de terceiros poderiam definir cookies se a preferência" Bloquear cookies "no Safari estivesse definida como a configuração padrão de" De terceiros e anunciantes ". Support.apple.com/kb/HT5190
— vwoelm 5/04/12
1
Acho que esse comentário de vwoelm é o mais próximo da resposta que eu estava procurando. Antes de mais, queria confirmar que a Apple fechou definitivamente a brecha e que a referência ao artigo de suporte da Apple é exatamente isso. A segunda parte da minha pergunta ainda é pertinente. Quais são as opções para soluções alternativas. Claramente, podemos codificar IDs de sessão como parâmetros GET / POST, mas quais são as outras opções. O armazenamento local funciona nesse contexto? Cookies em Flash?
— gs Hurley
@ vwoelm: essa é realmente a resposta que eu estava procurando (mas não esperando). Se você colocar isso em uma resposta em vez de um comentário, eu atribuirei a você a recompensa.
— mscha
3
@gshurley Acho que enviar ids de sessão através de parâmetros GET / POST é a única opção. É inseguro, mas, novamente, o Facebook nos obriga a servir aplicativos de tela sem SSL de qualquer maneira. E além do que você realmente ganha ao invadir um aplicativo do Facebook, haha? Estamos à mercê da Apple e eles estão atualmente no modo cruel.
— precisa saber é o seguinte
14

No seu controlador Ruby on Rails, você pode 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
fonte
Existe um problema semelhante com as sessões no safari?
— Rails iniciante
você pode substituir set_your_return_url para request.env ['HTTP_REFERER'], pois estamos dentro de um iframe :-D
— Luc Boissaye
Eu tentei esta solução e o único problema é que não consigo retornar ao URL iframe pai. Existe um método no Rails para obter o URL do iframe pai? obrigado
— idejuan
Levei um tempo, mas finalmente descobri que a maneira mais fácil (TMO) é simplesmente adicioná-lo como um parâmetro de cadeia de consulta ao URL de redirecionamento do aplicativo rails. Wasy e limpo.
— guyaloni 21/07
1
Esta resposta cria um redirecionador aberto, que é um problema de segurança comum. O código perigoso é redirect_to params[:return_to]. Esse parâmetro precisa ser verificado em uma lista de desbloqueio de locais seguros para o qual redirecionar. Veja owasp.org/index.php/…
— phylae
13

Para minha situação específica, resolvi o problema usando window.postMessage () e eliminando qualquer interação do usuário. Observe que isso só funcionará se você puder executar de alguma forma js na janela pai. Isso inclui js do seu domínio ou se você tem acesso direto à fonte.

No iframe (domínio-b), verifico a presença de um cookie e, se não estiver definido, enviarei um postMessage para o pai (domínio-a). Por exemplo;

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

Em seguida, na janela pai (domínio-a), ouça o 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, no seu servidor (http://www.domain-b.com/safari/cookiefix), você define o cookie e redireciona de volta para a origem do usuário. O exemplo abaixo está usando o 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/");
    }

}
— Frank
fonte
Você não está recebendo um erro de sintaxe com sua chamada para postMessage?
— Akousmata
Necessidade de adicionar um segundo parâmetro "*"para PostMessagecorrigir o erro de sintaxe
— Michael Baldry
Gostaria de poder dar a esta resposta mais votos positivos. É a maneira mais simples e correta de realmente resolver esse problema. Obrigado por publicá-lo!
— AaronP
9

Eu tive o mesmo problema e hoje encontrei uma correção que funciona bem para mim. Se o agente do usuário contiver Safarie nenhum cookie estiver definido, redirecionarei o usuário para o 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 } ?>

Após a autenticação e a solicitação de permissões, o Diálogo OAuth será redirecionado para meu URI no local superior. Portanto, é possível definir cookies. Para todos os nossos aplicativos de tela e guia de página, já incluí o seguinte script:

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

Portanto, o usuário será redirecionado novamente para a guia da página do Facebook com um cookie válido já definido e a solicitação assinada será publicada novamente.

— Sascha Galley
fonte
Bom trabalho nisso. Atualizei a verificação do agente do usuário para garantir que o Chrome também não estivesse no agente do usuário, pois o Chrome também possui o Safari na cadeia do agente do usuário. Redirecionar para a página do seu domínio, definir os cookies / sessão inicial necessários e depois redirecionar para o aplicativo em apps.facebook.com funcionou como um encanto. Parece bobagem, mas funciona bem. Obrigado Sascha pela dica!
— 5133 Mike
7

Finalmente, optei por uma solução semelhante à que Sascha forneceu, mas com alguns ajustes, já que estou configurando os cookies explicitamente no 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>';

O que isso faz é verificar se o cookie está disponível quando o navegador é um safari. Na próxima etapa, estamos no domínio do aplicativo, ou seja, o URI fornecido como URL_WHERE_APP_IS_LOCATED acima.

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

}

Portanto, depois de redirecionar para o domínio do aplicativo, um cookie é definido explicitamente e eu redireciono o usuário para o processo de autorização.

No meu caso (como estou usando o CakePHP, mas deve funcionar bem com qualquer outra estrutura MVC), estou chamando a ação de login novamente, onde a autorização do FB é executada outra vez e, desta vez, é bem-sucedida devido ao cookie existente.

Depois de ter autorizado o aplicativo uma vez, não tive mais problemas ao usar o aplicativo com o Safari (5.1.6)

Espero que ajude alguém.

— Marcel Kalveram
fonte
1
isso funcionou para mim !! obrigado!! .. eu estava tendo esse problema com o Safari 5.1.7 .... agora está resolvido!
— Khalizar
5

Eu tive esse problema em dispositivos executando iOS. Fiz uma loja que pode ser incorporada em um site normal usando um iframe. De alguma forma, em cada carregamento de página, o usuário recebe um novo ID da sessão, resultando em usuários presos na metade do processo, porque alguns valores não estavam presentes na sessão.

Tentei algumas das soluções fornecidas nesta página, mas os pop-ups não funcionam muito bem em um iPad e eu precisava da solução mais transparente.

Eu o resolvi usando um redirecionamento. O site que incorpora meu site deve primeiro redirecionar o usuário ao meu site, para que os principais quadro contenha o URL do meu site, onde defino um cookie e redireciono o usuário para a página apropriada no site que incorpora meu site, que é passado através do URL.

Exemplo de código PHP

O site remoto redireciona o usuário para

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;

O usuário termina http://www.domain.com/shop/frameonde meu site está incorporado, armazenando as sessões como deveria e comendo biscoitos.

Espero que isso ajude alguém.

— ar34z
fonte
3

Deixe-me compartilhar minha correção no ASP.NET MVC 4. A idéia principal, como na resposta correta para PHP. O próximo código adicionado na seção Layout principal no cabeçalho próximo à seção 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
fonte
3

Esta solução se aplica em alguns casos - se possível:

Se a página de conteúdo do iframe usar um subdomínio da página que contém o iframe, o cookie não será mais bloqueado.

— maravilha
fonte
Esta é uma informação útil - exatamente o que eu estava procurando. Embora tenha certeza de que a maioria das pessoas não pode mudar de domínio, é isso que vou fazer. Faça com que o site que eu estou incorporando crie um subdomínio <mycompany>. <theircompany> .com que mapeie para meu IP e um VHost do meu lado para esse domínio e use essa URL no iFrame. Complicado, mas deve ser à prova de balas.
— Elocution Safari
1
Isso pode ser complicado se você estiver usando https com o subdomínio, pois o servidor do subdomínio precisará de um certificado SSL para corresponder.
— Roger Halliburton
1

Google realmente deixou o gato fora do saco neste. Eles estavam usando por um tempo para acessar os cookies de rastreamento. Foi corrigido quase imediatamente pela Apple = \

postagem original no Wall Street Journal

— Colin Godsey
fonte
Eu sei sobre a coisa do Google, mas não vi nada sobre a Apple realmente “consertando” isso (e quebrando metade da Internet). Você tem algum detalhe disso?
— mscha
1

Aqui está um código que eu uso. Descobri que, se eu definir algum cookie no meu site, os cookies funcionarão magicamente no iframe a partir de então.

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
fonte
1

Uma versão um pouco mais simplificada em PHP do que outros publicaram:

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
fonte
1

Eu encontrei a resposta perfeita para isso, tudo graças a um cara chamado Allan que merece todo o crédito aqui. ( http://www.allannienhuis.com/archives/2013/11/03/blocked-3rd-party-session-cookies-in-iframes/ )

Sua solução é simples e fácil de entender.

No servidor de conteúdo iframe (domínio 2), adicione um arquivo chamado startupession.php no nível do domínio raiz que contém:

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

Agora, no site de nível superior que contém o iframe (domínio1), a chamada para a página que contém o iframe deve se parecer com:

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

E é isso! Simples :)

O motivo disso funciona é porque você está direcionando o navegador para um URL de terceiros e solicitando que ele confie antes de mostrar o conteúdo dentro do iframe.

— user1351772
fonte
0

Usei o modificado Whiteagle modificado (adicionado parâmetro de assinatura_request ao link) e funcionou bem no safari, mas o IE está atualizando constantemente a página nesse caso. Portanto, minha solução para o safari e o 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'];
}
— cotko
fonte
0

Eu também estou sofrendo com esse problema, mas finalmente consegui a solução. Inicialmente, carregue diretamente o URL do iframe no navegador como um pequeno pop-up e acesse apenas os valores da sessão dentro do iframe.

— Karthik Keyan
fonte
-2

Decidi me livrar da $_SESSIONvariável todos juntos e escrevi um wrapper em torno do memcache para imitar a sessão.

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

Caso de uso: no momento em que um usuário acessa o aplicativo, armazena a solicitação assinada usando o Session_manager e, como está no cache, você pode acessá-lo em qualquer página a partir de agora.

Nota: Isso não funcionará ao navegar em particular no Safari, pois o session_id é redefinido sempre que a página é recarregada. (Safari estúpido)

— Manpreet Sethi
fonte
-9

Você pode resolver esse problema adicionando cabeçalho como política p3p .. eu tive o mesmo problema no safari, portanto, depois de adicionar cabeçalho no topo dos arquivos, resolvi o meu problema.

<?php
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
?>
— Madan
fonte
Tem certeza de que isso (ainda) funciona com a versão mais recente do Safari? Temos cabeçalhos P3P há anos, para o IE, mas o Safari ainda está quebrado.
— mscha
2
Tente limpar todos os seus cookies e teste novamente. O problema não aparece se o seu navegador já tiver cookies para o site iframed.
— rmarscher
Hummm, também não consigo fazer com que os cabeçalhos P3P funcionem. Eles ainda trabalham no IE!
— Seth Brown
2
Isso costumava funcionar. Mas para a versão mais recente do Safari, não. Limpe o cache e tente novamente ....
— chantheman
2
Eu quero afirmar que esta solução funciona. certifique-se de excluir todos os cookies no safari. E então tente isso.
— dnuske
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.