Победа за мной!
Существует почти полностью документированы функция Facebook борьбы с IFrame сессий, что я нашел смутное упоминание в моих исследованиях. Эта страница не объясняет это хорошо , однако, и только через несколько часов , наблюдая различные сеансовых ключей в моем IFRAME я смог выяснить , что происходит.
Раньше мой IFrame приложение получало обычный круг fb_whateverпараметров , когда произошла начальная загрузка IFrame. Так что в моем приложении, я делал это на каждом запросе:
if (isset($_REQUEST['fb_sig_session_key'])) {
$_SESSION['fb_sig_session_key'] = $_REQUEST['fb_sig_session_key'];
}
if (! empty($_SESSION['fb_sig_session_key'])) $this->facebook->api_client->session_key = $_SESSION['fb_sig_session_key'];
Этот код будет получать fb_sig_session_keyна начальной загрузке приложения, и я бы с короткозамкнутым его прочь в местную $_SESSIONдля использования с API. Сохранение его в локальной сессии необходимо, потому что fb_sig_session_keyникогда не будет принят снова , если вы не загрузите все приложения IFRAME.
Поэтому проблемы, возникающие при этом ключ сеанса истек час или чуть позже.
Посмотрев на туманную ссылку на странице , я начал исследовать все $_REQUESTпеременный я получаю. Оказывается , что даже на внутренней ссылке внутри вашего Iframe приложения, Facebook изменяет запрос , чтобы пройти по некоторым параметрам. По какой - то причине, они имеют совершенно иной, но и правильный ключ сеанса , который поставляется вместе с каждым запросом IFrame!
Этот параметр называется после ключа апи Facebook Application. Так что, если ваш ключ API приложения является «XYZ123», каждый запрос внутри фрейма получает параметр с именем xyz123_session_key(как и несколько других, как xyz123_expiresи xyz123_user).
После просмотра связанного времени истечения срока для основной сессии (оригинал fb_sig_session_key) и этих IFrame только сессий ( xyz123_session_key), свет в конце туннеля появился: Функция Iframe только ключ сеанса истечение времени на самом деле обновляется периодически . Я не определили , когда и как (я предполагаю , что это пинг Ajax в какой - то момент), но , тем не менее, это освежает.
Я ждал оригинальной fb_sig_session_keyсессия истечет, и конечно друг-связанных страницы в моем приложении начали кашлять ошибки. В этот момент, я переключил свой локально сохраненный ключ сеанса новый IFrame-только xyz123_session_key, и проблема была решена. Эта сессия работает точно так же , как оригинал!
Итак, мой окончательный код исправления для хранения ключа сеанса локально следующим образом:
$iframeSessionKeyName = $CONFIG['facebook']['apiKey'] . '_session_key';
if (isset($_REQUEST[$iframeSessionKeyName])) {
$_SESSION['fb_sig_session_key'] = $_REQUEST[$iframeSessionKeyName];
}
else if (isset($_REQUEST['fb_sig_session_key'])) {
$_SESSION['fb_sig_session_key'] = $_REQUEST['fb_sig_session_key'];
}
if (! empty($_SESSION['fb_sig_session_key'])) $this->facebook->api_client->session_key = $_SESSION['fb_sig_session_key'];
Это дает предпочтение ключ «IFrame-только».
Edit: Мое первоначальное предположение о том , что ключ «IFrame только» был обновлен с помощью какого - то метода Ajax не так, оказывается, эти значения устанавливаются в печенье с помощью Facebook. Это приводит к некоторым проблемам междоменных при использовании этих куков. Настройка политики P3P печенья облегчит это с большинством браузеров, кроме Safari. Там до сих пор нет хорошей работы вокруг Safari.
