De overwinning is van mij!
Er is een bijna geheel zonder papieren Facebook-functie te maken met iframe sessies, dat vond ik een vage verwijzing naar in mijn onderzoek. Deze pagina maakt het niet goed echter, en pas na enkele uren van het kijken naar de verschillende sessie sleutels in mijn iframe echt uitleggen was ik in staat om erachter te komen wat er gaande was.
Voorheen mijn iframe app ontving de gebruikelijke ronde van fb_whateverparameters wanneer de initiële belasting iframe plaatsgevonden. Dus in mijn aanvraag, ik was om dit te doen op elk verzoek:
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'];
Deze code zou ontvangen de fb_sig_session_keyop de eerste app te laden, en ik zou het eekhoorn weg naar een lokale $_SESSIONvoor gebruik met de API. Op te slaan in de lokale zitting is nodig, want fb_sig_session_keynooit wordt doorgegeven weer, tenzij u de volledige app iframe herladen.
Dus de problemen opgetreden bij deze sessie sleutel een uur of zo later verstreken.
Na het kijken naar de vage verwijzing pagina , ben ik begonnen met het onderzoeken van alle $_REQUESTvariabelen die ik kreeg. Het blijkt dat zelfs op een interne link in uw iframe app, Facebook wijzigt het verzoek om langs een aantal parameters. Om een of andere reden, ze hebben een heel andere, maar ook geldig sessie sleutel die wordt geleverd samen met elke iframe aanvraag!
Deze parameter is vernoemd naar uw Facebook applicatie API Key. Dus als uw aanvraag API-sleutel is "xyz123", elk verzoek in uw iframe krijgt een parameter met de naam xyz123_session_key(evenals een paar anderen, zoals xyz123_expiresen xyz123_user).
Na het bekijken van de bijbehorende vervaltijd voor de belangrijkste sessie (het origineel fb_sig_session_key) en dit iframe-only sessie ( xyz123_session_key), het licht aan het eind van de tunnel verscheen: de iframe-only sessie sleutel verloop tijd wordt eigenlijk af en toe bijgewerkt . Ik heb niet bepaald wanneer en hoe (ik neem aan dat het een Ajax-ping op een bepaald punt), maar toch, verfrist.
Ik wachtte tot de oorspronkelijke fb_sig_session_keysessie te vervallen, en ja hoor de vriend of gerelateerde pagina's in mijn app begon ophoesten fouten. Op dat punt, schakelde ik mijn lokaal opgeslagen sessie sleutel tot de nieuwe iframe-only xyz123_session_key, en het probleem was opgelost. Dat sessie werkt net zo goed als het origineel!
Dus, mijn laatste code oplossing is om de sessie sleutel lokaal opslaan als volgt:
$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'];
Dit geeft de voorkeur aan de "iframe-only" key.
Edit: Mijn oorspronkelijke veronderstelling dat de "iframe-only" key is bijgewerkt via een soort van Ajax methode was verkeerd, het blijkt deze waarden zijn ingesteld in een cookie door Facebook. Dit leidt tot een aantal cross-domain problemen bij het gebruik van deze cookies. Een instelling P3P cookie-beleid zal dit verlichten met de meeste browsers, behalve Safari. Er is nog steeds geen goed werk rond voor Safari.
