Кэширование данных OG в отладчике, форсирование веб-сайта og:type и всплывающее окно авторизации для сообщения "Точно посмотрите, что наш скребок видит для вашего URL"
Возникли проблемы с получением Timeline для работы. Это проблема из двух частей.
Во-первых, существует проблема кеширования частей метатегов OG. Когда отладчик переходит на мой URL, я знаю, что он правильно нажимает на него, потому что og:url, который он выдает, верен, что означает, что он был обработан на моем конце (например: я отправляю его на og.php? Og=read&chapter=799, и он вернет правильный book_id для og:url, что означает, что мой скрипт обработал его). Но вся другая информация, похоже, кешируется. У меня изначально и по ошибке были fb:app_id и og: site_url для объекта, поэтому я удалил их. Вывод по-прежнему показывает те, которые имеют существующий site_url, который выдает ошибку. Наличие fb:app_id вызывает тип og: 'website', который я (правильно) установил для своего пространства имен и объекта. Когда я пытаюсь POST выполнить действие, я получаю ошибку oAuthException, что og: тип 'website' недопустим для объекта. Еще раз, это должно быть исправлено, но оно продолжает кэшировать старые данные OG. Я попытался добавить? Fbrefresh=1, но это ничего не сделало.
Другая проблема, возможно связанная... даже если я знаю, что она туда попала, и мой сценарий обработал запрос, Facebook не сообщает об этом. Когда я нажимаю "Посмотрите, что именно наш скребок видит для вашего URL", он показывает URL аутентификации (см. Ниже)! Как будто он никогда не попал туда, и всплыло всплывающее окно, что даже не работает как код для og.php!! Я предполагаю, что они получили это от имени базового домена (exmaple.com), прежде чем пытаться выполнить полный запрос с example.com/og.php.
window.parent.location = 'HTTPS://www.facebook.com/dialog/oauth client_id=164431733642252&redirect_uri= HTTP%3A%2F%2Fapps.facebook.com%2Fexample%2F%3Fpage%3D& состояние =064bd26ff582a9ec7c96729e6b69bbd2& холст =1&fbconnect=0& сфера = электронная почта%2Cpublish_stream%2Cpublish_actions%2C';
2 ответа
Я понял. Я думал, что og:url - это URL, который вы хотите, чтобы люди использовали для перехода на нужную страницу вашего приложения, например, ссылку для действия. Это так, но это не так. Теперь он соответствует OBJECT_URL, который вы отправляете на временную шкалу.
У меня был другой URL (ссылка на приложение), который при перенаправлении не может быть достигнут сканером, поскольку он находится внутри авторизованной стены приложений. Это привело к тому, что веб-сайт og:type и данные выглядели кэшированными.
Чтобы исправить это, object_url, который я публикую на временной шкале, и og:url в метатеге одинаковы. Но вы можете выяснить, является ли это сканер или ссылка действия, найдя строку запроса:? Fb_action_ids=SOME_ID, которая отправляется по ссылке на временной шкале. Если он содержит это, я пересылаю его на нужную оттуда страницу приложения.
У меня с вами похожие проблемы. Он продолжал жаловаться на установку og:site_url, хотя я никогда не устанавливал их. Похоже, что сообщения об ошибках, которые он отправляет, на самом деле неточны, и проблема не в том, что устанавливается og:site_url, а в том, что og: url отличается от URL объекта. Иногда неправильное сообщение об ошибке хуже, чем отсутствие сообщения об ошибке!
Еще один вопрос - почему URL-адрес объекта должен соответствовать живой странице, которую увидит пользователь. Объект - это логическая единица, но он не обязательно соответствует одной видимой пользователю странице. Ваш трюк перенаправления может сработать, но это не правильный способ что-то сделать. Когда я публикую действие, относящееся к объекту, URL-адрес объекта должен использоваться для отображения информации об объекте, но я должен быть в состоянии отправить пользователя куда-то еще. Если это был задуман дизайн, я думаю, что это ошибка.