Медленная загрузка приложения холста facebook при нажатии на ссылки (если целевая вершина)

Ситуация: я разрабатываю приложение для холста facebook. Facebook отправляет моему серверу POST-запрос с signed_request каждый раз, когда отображается страница. Внутри моего приложения у меня есть все мои ссылки с target="_top", потому что если я этого не сделаю, facebook отправит мой сервер общий GET без подписанного запроса. Поэтому я не могу проверить информацию о пользователе.

Проблема: это слишком медленно! даже если я тестирую его локально, каждый щелчок, который я нажимаю, занимает 1 секунду для рендеринга, и мой холст становится полностью белым, а затем отображается информация. Это будет плохой пользовательский интерфейс.

Мои тесты: если я удалю target=_top и укажу href всех моих ссылок на свой сервер без app.facebook.com/whatever, он загружается очень быстро.

Мои сомнения: есть ли какие-либо проблемы с безопасностью? Если я укажу все ссылки на свой сервер (без apps.facebook.com) я не смогу проверить подписанный запрос, я проверю его только на главной странице..

Любой совет? любой учебник? Есть ли у меня какое-то непонимание этого? (Это мое первое приложение для Facebook)


person JDL    schedule 21.03.2012    source источник


Ответы (2)


Вы прочитали руководство по аутентификации на стороне сервера? Ты делаешь это неправильно.

Как только пользователи попадут в ваше приложение, вы должны держать все ссылки в одном фрейме, загрузка всего окна вместе с facebook совершенно излишня.

Что ты должен делать:

Когда вы получите POST с подписанным запросом, расшифруйте его и проверьте, аутентифицирован ли пользователь, если он сохраняет данные (токен и т. д.) где-то (сеанс, БД, кеш). Если он не аутентифицирован, отправьте его в диалоговое окно аутентификации, как указано в руководстве, когда он вернется, обменяйте полученный код (в GET) на токен (также показанный в руководстве), а затем перенаправьте его на http (s): //apps.facebook.com/YOUR_APP, и вы будете отправлены с аутентифицированным подписанным запросом, сохраните его и т. д..

Поскольку вы сохраняете данные, в каждом запросе, который не является POST или не включает signed_request, проверяйте свой выбор сохранения для данных и используйте его.

Должно быть только два раза, когда facebook отправляет вам запрос, один раз это POST, когда ваш холст загружается, второй раз, когда пользователь возвращается из диалогового окна аутентификации, в котором вы либо получаете параметр code или ошибка, если пользователь отказался от аутентификации. Другие запросы должны поступать из вашего приложения (внутри iframe) на серверы приложений.

person Nitzan Tomer    schedule 21.03.2012
comment
Привет, Низан, искренне, я прочитал много документов, но ни одного о ссылках между страницами внутри iframe (даже нет четкого примера). Я использую fandjango + facetools. Я читал документы, и в примере с facetools они поставили target=_top во всех ссылках приложения... оно тоже работает медленно. (И это отличается от того, что вы говорите) Сомнение: http(s)://apps.facebook.com/ВАШЕ_ПРИЛОЖЕНИЕ -> сервер/основная/ другие страницы: сервер/основная/опросы/ сервер/основная/опросы/1/ результаты/ Я проверяю signed_request и делаю всю логику, которую вы говорите, в server/main/ Что произойдет, если я перейду прямо на: apps.facebook.com/ВАШЕ_ПРИЛОЖЕНИЕ/polls/ - person JDL; 22.03.2012
comment
Я не знаком ни с fandjango, ни с facetools, но когда внутри iframe ваше приложение должно работать как обычно, без взаимодействия с родительским фреймом facebook, единственным способом взаимодействия с facebook является использование js sdk или вызовы API на стороне сервера. - person Nitzan Tomer; 22.03.2012

JDL,

Я полагаю, что вы запрашиваете API графа при каждом запросе (и именно поэтому вам всегда нужен signed_request). Это правильно?

Графический API довольно медленный (~ 1 секунда на запрос), и его следует использовать только при необходимости. Например, когда вы впервые получаете access_token, вы должны сохранить его в своем сеансе и запросить API графа, чтобы получить соответствующую информацию о пользователе facebook. Но тогда вы должны поместить необходимую информацию об этом пользователе в свой сеанс и обновить ее (используя API графа) только тогда, когда токен доступа signed_request отличается от того, который вы сохранили в своем сеансе.

Поведение добавления _top к цели ваших ссылок нормально и является хорошей практикой на холсте facebook.

person barbolo    schedule 21.03.2012
comment
Привет, барболо, я запрашиваю график только в первый раз, когда пользователь попадает на мой холст (основная информация о пользователе на данный момент, в будущем она изменится, я попрошу больше вещей) Я использую приложение, которое абстрагирует меня от всего этого. Основная проблема в том, что когда я ставлю target=_top, весь фейсбук перезагружается, а это требует времени. У меня много ссылок в моем приложении (много), НО, если я использую обычные ссылки, они работают очень быстро (я все еще могу получить доступ к signed_request и информации о пользователе в файле cookie). Обязательно ли делать target=_top? Есть ли проблема с безопасностью, если я обрабатываю только подписанный_запрос POST в доступе к основному холсту? - person JDL; 22.03.2012
comment
Хорошо, теперь стало понятнее. Поведение, которое вы наблюдаете, совершенно нормально. Вы можете проверить несколько других приложений, которые работают точно так же (протестируйте, например, Торговый центр от Payvment). Основная проблема неиспользования target=_top заключается в том, что пользователь не сможет использовать кнопку возврата браузера или скопировать текущий URL-адрес навигации. Если это не проблема для вас, вы можете не использовать target=_top - person barbolo; 22.03.2012
comment
Привет Барболо! Спасибо за Ваш ответ. Ну... преимущества с точки зрения скорости намного больше, чем кнопка «Назад» + URL-адрес, поэтому я буду использовать внутренние ссылки iframe. Еще раз Спасибо! - person JDL; 22.03.2012