Кэширование данных OG в отладчике, форсирование og: тип веб-сайта и всплывающее окно авторизации для «Посмотрите, что наш скребок видит для вашего URL-адреса» беды

Question

Имея проблемы с получением временной шкалы. Это проблема двух частей.

Во-первых, существует проблема кеширования частей метатегов OG. Когда отладчик переходит к моему URL-адресу, я знаю, что он правильно его удаляет, потому что og: url, который он плюет обратно, является правильным, что означает, что он был обработан на моем конце (например: я отправляю его в og.php? Og = read & глава = 799, и он вернет права book_id для og: url, что означает, что мой скрипт обработал его). Но вся другая информация, похоже, кэшируется. Я изначально и ошибочно имел fb: app_id и og: site_url для объекта, поэтому я удалил их. На выходе все еще отображаются те, которые имеют существующий site_url, который выдает ошибку. Наличие fb: app_id заставляет og: type 'website', который я установил (правильно) для своего пространства имен и объекта. Когда я пытаюсь выполнить POST-действие, я возвращаю ошибку oAuthException, что тип объекта «og:» недействителен для объекта. Еще раз, это должно быть исправлено, но он сохраняет кеширование старых данных 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 & canvas = 1 & fbconnect = 0 & scope = email% 2Cpublish_stream% 2Cpublish_actions% 2C ';

Answer 1

Я понял. Я думал, что og: url - это URL, который вы хотели, чтобы люди использовали для доступа к правильной странице вашего приложения, например ссылку на действие. Это так, но это не так. Теперь у меня это соответствует OBJECT_URL, который вы отправляете на график.

У меня был другой URL-адрес (ссылка для приложения к приложению), который при перенаправлении не может быть доставлен искателем, поскольку он находится внутри разрешенной стены приложений. Это привело к тому, что веб-сайт og: и данные появлялись в кеше.

Чтобы исправить это, object_url Я отправляю на временную шкалу, а og: url в метатеге - то же самое. Но вы можете выяснить, является ли это поисковой системой или ссылкой действия, ища строку запроса:? Fb_action_ids = SOME_ID, который отправляется из ссылки на временной шкале. Если он содержит это, я пересылаю его на нужную страницу приложения.

Answer 2

У меня возникают схожие проблемы. Он продолжал жаловаться на установку og: site_url, хотя я никогда не устанавливал их. Похоже, что отправленные сообщения об ошибках на самом деле неточны, и проблема заключается не в том, что og: site_url устанавливается, но что og: url отличается от URL-адреса объекта. Иногда неправильное сообщение об ошибке хуже, чем сообщение об ошибке!

Еще один вопрос, почему URL-адрес объекта должен соответствовать текущей странице, которую пользователь увидит. Объект является логическим блоком, но он не обязательно соответствует одной странице, видимой пользователем. Ваш трюк перенаправления может работать, но это не правильный способ сделать что-то. Когда я отправляю действие, связанное с obect, URL-адрес объекта должен использоваться для рисования информации об объекте, но я должен быть в состоянии отправить пользователя в другое место. Если это был намеченный дизайн, я думаю, что это ошибка.