Примітка iframe для файлів cookie третьої сторони вже не працює?

137

Таким чином, це вже помста про питання "як я можу отримати сторонні файли cookie для роботи в Safari", але я запитую ще раз, тому що я думаю, що ігрове поле змінилося, можливо, після лютого 2012 року. Один із стандартних прийомів отримати 3-е місце Файли cookie партії в Safari були наступні: використовуйте javascript для POST до прихованого iframe. Це (раніше) підманювало Safari думати, що користувач взаємодіяв із стороннім вмістом, і тоді дозволяв встановлювати файли cookie.

Я думаю, що ця лазівка була закрита внаслідок м'якого скандалу, коли було виявлено, що Google використовує цей трюк у своїх рекламах. Принаймні, використовуючи цей трюк, я зовсім не зміг встановити файли cookie в Safari. Я виявив кілька випадкових публікацій в Інтернеті, які стверджували, що Apple працює над закриттям лазівки, але я не знайшов жодного офіційного слова.

Як резерв я навіть спробував переробити основний кадр сторонньої сторони, так що вам довелося натиснути кнопку, перш ніж вміст завантажиться, але навіть такого рівня прямої взаємодії було недостатньо, щоб розтопити холодне серце Сафарі.

Так хтось знає напевно, чи Сафарі справді закрив цю лазівку? Якщо так, чи існують інші способи вирішення (крім того, щоб вручну включати ідентифікатор сеансу в кожен запит)?

— gs hurley
джерело

21

Використання стороннього iframe, який потребує файлів cookie, звичайно, не є визначенням атаки безпеки! Ми запускаємо веб-магазин, який використовується в iframe на безлічі різних доменів, і з Safari є всілякі проблеми з пізнім часом, тому мене також дуже цікавить відповідь на це (законне) питання.

— mscha

14

Практично всі проблеми, які створюють програми Facebook, мають цю проблему із Safari. Програми Facebook запускаються у рамці iframe та за визначенням, усі надходять від третіх сторін. Ось чому підтримка Safari у додатках Facebook дещо помітна: ви не можете використовувати файли cookie.

— gs hurley

Я не можу відтворити цю проблему на сафарі 5.1.7. Він приймає файли cookie з моєї програми facebook iframe з типовим налаштуванням "без сторонніх файлів cookie". Однак Chrome 19.0.1084.46 з тим же налаштуванням блокує файл cookie.

— Євген Шадчнєв

4

Chrome 19+ із встановленою опцією "Блокувати сторонні файли cookie та дані веб-сайтів" (за щасливе значення) є / навіть суворішою /, ніж за замовчуванням "Заблокувати файли cookie від сторонніх та рекламодавців" за замовчуванням Safari. У хромі, навіть якщо ви відвідаєте домен сторонньої сторони та встановили файли cookie, вони не будуть передані до iframe. Користувач повинен фактично додати "виняток" для вашого домену в її налаштуваннях безпеки Chrome.

— Аарон Гібралтер

Що ви маєте на увазі під лютим 2012 року? Чи є технічна зміна Safari чи зміна закону?

— ліквід

51

Просто хотів залишити тут просте робоче рішення, яке не потребує взаємодії з користувачем .

Як я вже заявив у своєму дописі, я зробив :

В основному все, що вам потрібно зробити, це завантажити свою сторінку в top.location, створити сеанс і перенаправити його назад у facebook.

Додайте цей код у верхній частині index.phpта встановіть $page_urlна останню вкладку / URL-адресу програми, і ви побачите, що ваша програма працюватиме без проблем.

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

Примітка. Це було зроблено для facebook, але воно фактично спрацювало б у будь-яких інших подібних ситуаціях.

Редагувати 20 грудня 2012 року - підтримка підписаного запиту:

Вищевказаний код не підтримує запити, що надсилають дані, і ви втратите подпис подписи, якщо ваша програма спирається на підписаний запит, не соромтеся спробувати наступний код:

Примітка. Це все ще перевіряється належним чином і може бути менш стабільним, ніж перша версія. Використовуйте на свій страх і ризик / Зворотній зв'язок цінується.

(Дякую CBroe за те, що я вказував мене в правильному напрямку, що дозволяє покращити рішення)

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

— Діого Рамінхос
джерело

Дякую, працює як шарм і його так легко реалізувати в існуючих додатках :-)

— SamiSalami

Отже, ця в основному працює з парою переадресацій, правда?

— Аарон Гібралтер

1

@hugoderhungrige ласкаво просимо, я щойно додав нову версію, сміливо перевіряйте, чи потрібно підтримувати підписаний запит у своїх додатках.

— Діого Рамінхос

1

@CBroe Дякую дуже за вказівку на це! Ви мали рацію, це працює, оскільки за другим запитом користувач вже розпочав сеанс! Я здогадуюсь, що "найгірший сліпий - той, хто не хоче бачити".

— Діого Рамінхос

1

@Whiteagle Чи можете ви надати тестовий випадок із демонстрацією 1 і 2?

— Гаджус

35

Ви сказали, що бажаєте, щоб ваші користувачі натискали кнопку до завантаження вмісту. Моє рішення полягало в тому, щоб кнопка відкрила нове вікно браузера. У цьому вікні встановлено файл cookie для мого домену, оновить відкривач і потім закриється.

Отже, ваш основний сценарій може виглядати так:

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

Тоді safari_cookie_fix.php виглядає так:

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

— кресляри
джерело

Я думав про щось подібне. Працює бездоганно. Я завантажую його разом із діалоговим вікном дозволу. Дякую!

— vwoelm

Здається, що це також працює в налаштуваннях Safari, і що, як тільки загальновідомо, буде застосовано так само, як і інші "рішення". Я взагалі шукаю інше рішення, оскільки стає очевидним, що сторонні файли cookie зараз є дияволом, навіть якщо вони використовуються відповідними способами.

— LocalPCGuy

1

Це рішення спрацювало для мене, проте чи потрібне спливаюче вікно? Чи можете ви перенаправити iframe на сторінку сафарі, встановити файл cookie, а потім повернутись до гри із заголовками переадресації? Або вам потрібне спливаюче вікно, щоб користувач мав певну форму прямого контакту з сервером?

— Ентоні Гастінгс

це добре спрацювало; на щастя, натискання кнопки, щоб ініціалізувати це, не було великою справою в моєму додатку.

— маленький

@LocalPCGuy Я не дуже впевнений, що він буде застосований, як і інші рішення, оскільки він вимагає, щоб користувач фактично натискав / взаємодів зі сторінкою, щоб спливаюче вікно не було заблоковано. Це рішення, розроблене Safari, здається, працює добре: рекламодавці не зможуть таємно встановлювати міждоменні файли cookie, а вбудовані додатки потребують взаємодії користувача перед тим, як мати змогу встановити файл cookie.

— Аарон Гібральтер

15

Я обдурив Сафарі .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>

І це перестало працювати і на мене. Усі мої програми втрачають сеанс в Safari і перенаправляються з Facebook. Оскільки я поспішаю виправити ці програми, я зараз шукаю рішення. Я буду тримати вас у курсі.

Редагувати (2012-04-06): Мабуть, Apple "виправила" це 5.1.4. Я впевнений, що це реакція на Google-річ: "Існувала проблема при застосуванні її політики щодо файлів cookie. Сторонні веб-сайти можуть встановлювати файли cookie, якщо для параметра" Блокувати куки "в Safari встановлено стандартне значення" Від третіх сторін та рекламодавців ". Http://support.apple.com/kb/HT5190

— vwoelm
джерело

1

Мабуть, Apple "зафіксувала" це 5.1.4. Я впевнений, що це реакція на Google-річ: "Існувала проблема при застосуванні її політики щодо файлів cookie. Сторонні веб-сайти можуть встановлювати файли cookie, якщо для параметра" Блокувати куки "в Safari було встановлено значення за замовчуванням" від третіх осіб і рекламодавців ». support.apple.com/kb/HT5190

— vwoelm

1

Тому я вважаю, що цей коментар vwoelm є найближчим до відповіді, яку я шукав. Перш за все, я хотів підтвердити, що Apple остаточно закрила лазівку і посилання на статтю підтримки Apple - це саме те. Друга частина мого питання хоч і стосується. Назвіть діапазон варіантів обходу. Зрозуміло, що ми можемо кодувати ідентифікатори сеансу як параметри GET / POST, але які інші варіанти. Чи працює місцеве зберігання в цьому контексті? Flash cookies?

— gs hurley

@vwoelm: це справді відповідь, яку я шукав (але не сподівався). Якщо ви поставите це у відповіді замість коментаря, я призначу вам нагороду.

— mscha

3

@gshurley Я думаю, що надсилання ідентифікаторів сеансу через параметри GET / POST - єдиний варіант. Це небезпечно, але потім Facebook знову змушує нас обслуговувати полотні програми без SSL. І крім того, що ви насправді отримуєте, зламавши додаток Facebook ха-ха? Ми перебуваємо на волі Apple, і вони зараз перебувають у жорстокому режимі.

— hekevintran

14

У контролері Ruby on Rails ви можете використовувати:

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

— поштовх
джерело

Чи є подібна проблема із сеансами в сафарі?

— Рейки початківця

ви можете замінити set_your_return_url на request.env ['HTTP_REFERER'], оскільки ми знаходимось у рамці iframe :-D

— Люк Бойсай

Я спробував це рішення, і єдине питання полягає в тому, що я не можу повернутися до URL-адреси батьківського iframe. Чи існує метод Rails для отримання URL-адреси батьківського iframe? дякую

— idejuan

Ми зайняли час, але нарешті я зрозумів, що найпростіший спосіб (TMO) - просто додати його як параметр рядка запиту до URL-адреса перенаправлення програми rails. Мило і чисто.

— guyaloni

1

Ця відповідь створює відкритий переспрямовувач, що є загальною проблемою безпеки. Небезпечний код є redirect_to params[:return_to]. Цей парам потрібно перевірити у списку безпечних місць, на який слід переадресувати. Дивіться owasp.org/index.php/…

— філаї

13

Для моєї конкретної ситуації я вирішив проблему, використовуючи window.postMessage () та усунувши будь-яку взаємодію з користувачем. Зауважте, що це буде працювати лише в тому випадку, якщо ви зможете якось виконати js у батьківському вікні. Або, включивши js від вашого домену, або якщо у вас є прямий доступ до джерела.

У iframe (domain-b) я перевіряю наявність файлу cookie і якщо він не встановлений, надішлете postMessage батькові (domain-a). Наприклад;

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

Потім у батьківському вікні (domain-a) прослухайте подію.

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;
    }
}

Нарешті, на вашому сервері (http://www.domain-b.com/safari/cookiefix) ви встановлюєте файл cookie та переспрямовуєте туди, звідки прийшов користувач. Нижче наведено приклад використання 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/");
    }

}

— Френк
джерело

Ви не отримуєте синтаксичну помилку під час свого дзвінка на постМессаж?

— akousmata

Потрібно додати другий параметр, "*"щоб PostMessageвиправити синтаксичну помилку

— Майкл Болдрі

Хотілося б, щоб я міг дати цю відповідь більшою мірою. Це найпростіший і правильний спосіб реально вирішити цю проблему. Дякуємо, що опублікували це!

— AaronP

9

У мене була така ж проблема, і сьогодні я знайшов виправлення, яке добре працює для мене. Якщо агент користувача не містить, Safariа файли cookie не встановлені, я переспрямовую його на діалог 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 } ?>

Після аутентифікації та запиту дозволів діалоговий вікно OAuth перенаправить на мій URI в верхньому місці. Тому налаштування файлів cookie можливо. Для всіх наших програм на полотнах і вкладках сторінки я вже включив такий сценарій:

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

Таким чином, користувач буде перенаправлений знову на вкладку сторінки Facebook з уже встановленим файлом cookie, і підписаний запит буде розміщений знову.

— Саша Галлей
джерело

Велика робота над цим. Я оновив перевірку користувацького агента, щоб переконатися, що Chrome також не був у користувальницькому агенті, оскільки Chrome має Safari і в рядку користувацького агента. Перенаправлення на сторінку вашого домену, встановлення необхідних файлів cookie / запуску сеансу, а потім переадресація назад на ваш додаток на apps.facebook.com працювали як принадність. Здається, нерозумно, але добре працює. Дякую Саші за пораду!

— Майк

7

Нарешті я пішов на подібне рішення до того, яке надав Саша, однак з невеликим коригуванням, оскільки я чітко встановлюю файли cookie у 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>';

Для цього потрібно перевірити, чи cookie доступний, коли веб-переглядач є сафарі. На наступному кроці ми знаходимось у домені програми, а саме URI, наданому як URL_WHERE_APP_IS_LOCATED вище.

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

}

Тож після перенаправлення до домену програми чітко встановлюється файл cookie, і я перенаправляю користувача до процесу авторизації.

У моєму випадку (оскільки я використовую CakePHP, але він повинен добре працювати з будь-якою іншою рамкою MVC) я викликаю вхід знову, коли авторизація FB виконується в інший раз, і на цей раз це вдається завдяки існуючому файлу cookie.

Після авторизації програми один раз у мене більше не було проблем із використанням програми Safari (5.1.6)

Сподіваюся, що це може допомогти будь-кому.

— Марсель Кальверам
джерело

1

це працювало для мене !! Дякую!! .. У мене була ця проблема з Safari 5.1.7 .... тепер це вирішено!

— Халізар

5

У мене була ця проблема на пристроях під керуванням iOS. Я зробив магазин, який можна вставити на звичайний веб-сайт за допомогою iframe. Так чи інакше, на кожному завантаженні сторінки користувач отримував новий сесійний режим, в результаті чого користувачі затримувались на півдорозі, оскільки в сеансі деяких значень не було.

Я спробував деякі рішення, наведені на цій сторінці, але спливаючі вікна не дуже добре працюють на iPad, і мені потрібно було найпрозоріше рішення.

Я вирішив це за допомогою переадресації. Веб-сайт, який вбудовує мій сайт, повинен спочатку переспрямувати користувача на мій сайт, тому верхній кадр містить URL-адресу на мій сайт, де я встановлюю файл cookie та перенаправляю користувача на належну сторінку на веб-сайті, яка вбудовує мій сайт, що передається через URL-адресу.

Приклад PHP-коду

Віддалений веб-сайт перенаправляє користувача на

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;

Користувач опиняється там, http://www.domain.com/shop/frameде вбудований мій сайт, зберігаючи сеанси як слід та харчуючись файлами cookie.

Сподіваюся, що це комусь допоможе.

— ar34z
джерело

3

Дозвольте мені поділитися своїм виправленням у ASP.NET MVC 4. Основна ідея, як у правильній відповіді на PHP. Наступний код доданий у головному макеті в заголовку біля розділу сценаріїв:

@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

Це рішення застосовується в деяких випадках - якщо можливо:

Якщо на сторінці вмісту iframe використовується субдомен сторінки, що містить iframe, файл cookie більше не блокується.

— око-диво
джерело

Це корисна інформація - саме те, що я шукав. Хоча я впевнений, що більшість людей не можуть змінювати домени навколо, це я і буду робити. Запропонуйте веб-сайту, який я вбудовую, створити піддомен <mycompany>. <theircompany> .com, який відображає мій IP та VHost на моєму боці для цього домену та використовувати цю URL-адресу в iFrame. Складний, але має бути куленепроникним.

— Elocution Safari

1

Це може ускладнитися, якщо ви використовуєте https з піддоменом, оскільки серверу субдомена потрібен сертифікат SSL для відповідності.

— Роджер Халлібуртон

1

Google насправді випустив кішку з сумки на цьому. Вони деякий час використовували його для доступу до файлів cookie відстеження. Це було виправлено майже відразу Apple = \

оригінальна публікація журналу Wall Street Journal

— Колін Годсі
джерело

Я знаю про річ Google, але я не бачив нічого про те, щоб Apple насправді «виправляла» це (і зламала половину Інтернету). Чи є у вас якісь деталі щодо цього?

— mscha

1

Ось якийсь код, який я використовую. Я виявив, що якщо я встановив будь-який файл cookie з мого сайту, то файли cookie магічно працюватимуть у iframe відтоді.

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

Трохи спрощена версія в PHP того, що опублікували інші:

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

Я знайшов ідеальну відповідь на це, все завдяки хлопцеві на ім’я Аллан, який заслуговує на всі заслуги тут. ( http://www.allannienhuis.com/archives/2013/11/03/blocked-3rd-party-session-cookies-in-iframes/ )

Його рішення просте і зрозуміле.

На сервері вмісту iframe (домен 2) додайте файл під назвою startsession.php на рівні кореневого домену, який містить:

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

Тепер на веб-сайті верхнього рівня, що містить iframe (domain1), дзвінок на сторінку, що містить iframe, повинен виглядати так:

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

І це все! Simples :)

Причина цього працює в тому, що ви спрямовуєте веб-переглядач до URL-адреси третьої сторони і, таким чином, говорите йому довіряти йому, перш ніж показувати вміст з нього в рамках iframe.

— user1351772
джерело

0

Я використовував модифікований (додав параметр підписаного_потребування до посилання) хитрість Whiteagle, і він спрацював нормально для сафарі, але IE постійно оновлює сторінку в цьому випадку. Тому моє рішення для сафарі та 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

Я також страждав від цієї проблеми, але нарешті отримав рішення. Спочатку завантажуйте URL-адресу iframe в браузер, як невеликий спливаючий вікно, а потім отримуйте доступ лише до значень сеансу всередині iframe.

— Картик Кеян
джерело

-1

Нещодавно я потрапив на те саме питання на Safari. Я вирішив, що я вирішив, базується на API місцевого зберігання HTML5. Використовуючи локальне зберігання, ви можете імітувати файли cookie.

Ось мій запис у блозі з деталями: http://log.scalemotion.com/2012/10/how-to-trick-safari-and-set-3rd-party.html

— Володимир Климонтович
джерело

Знімок із тканини: web.archive.org/web/20121124020234/http://log.scalemotion.com/…

— podvzbzdnul

-2

Я вирішив позбутися $_SESSIONзмінної всі разом і написав обгортку навколо пам’яті, щоб імітувати сеанс.

Перевірте https://github.com/manpreetssethi/utils/blob/master/Session_manager.php

Приклад використання: Щойно користувач прибуває до програми, зберігає підписаний запит за допомогою Session_manager і оскільки він знаходиться в кеші, ви можете отримати доступ до нього на будь-якій сторінці відтепер.

Примітка: Це не буде працювати при приватному перегляді в Safari, оскільки session_id скидається щоразу, коли сторінка перезавантажується. (Дурний сафарі)

— Manpreet Sethi
джерело

-9

Ви можете вирішити цю проблему, додавши заголовок як політику p3p. У сафарі була така сама проблема, тому після додавання заголовка вгорі файлів вирішено мою проблему.

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

— Мадан
джерело

Ви впевнені, що це (досі) працює з останньою версією Safari? Ми вже багато років мали заголовки P3P для IE, але Safari все ще зламаний.

— mscha

2

Спробуйте очистити всі файли cookie та протестуйте ще раз. Проблема не виявляється, якщо у вашому браузері вже є файли cookie для вашого веб-сайту iframed.

— rmarscher

Гммм, я також не можу заставити заголовки P3P працювати. Вони все ще працюють в IE, хоча!

— Сет Браун

2

Це працювало раніше. Але для останньої версії Safari це не так. Очистіть кеш і повторіть спробу ....

— chantheman

2

Я хочу констатувати, що це рішення працює. переконайтесь, що ВИДАЛИТЕ ВСЕ куки на сафарі. А потім спробуйте це.

— dnuske