Отправка объекта Facebook через открытый граф не работает, но затем работает после тестирования URL-адреса в отладчике объекта Facebook?

Я хочу, чтобы пользователь моего веб-приложения мог отправлять несколько объектов на свою временную шкалу с одной страницы (главная_страница).

У меня уже сохранен токен доступа пользователя.

Теги на странице, которую я пытаюсь отправить, url - page_url:

<meta property="fb:app_id"      content="my_app_id" /> 
<meta property="og:type"        content="my_namespace:my_object" /> 
<meta property="og:title"       content="some string" /> 
<meta property="og:description" content="some other string" /> 
<meta property="og:image"       content="some_image_url" />
<meta property="og:locale"      content="en_US" />
<meta property="og:url"         content="page_url" />

Код Rails для отправки URL-адреса, вызванного с главной страницы:

begin
    fb_post = RestClient.post 'https://graph.facebook.com/me/my_namespace:do', :access_token=>user.get_facebook_auth_token, :my_object=>"page_url"
rescue StandardError => e
    p 'e.response is'
    p e.response
end

Выход

2011-11-02T02:42:14+00:00 app[web.1]: "e.response is"
2011-11-02T02:42:14+00:00 app[web.1]: "{\"error\":{\"message\":\"(#3502) Object at URL page_url has og:type of 'website'. The property 'my_object' requires an object of og:type 'my_namespace:my_object'.\",\"type\":\"OAuthException\"}}"

Самое странное, что после получения этой ошибки, если я протестирую page_url в Отладчике объектов, он проходит без каких-либо ошибок/предупреждений, og:type является правильным типом и заметьте 'website', а затем запустив тот же код Rails, что и выше, будет отлично работать.

Я пробовал это без тега og:url, и то же самое происходит.

UPDATE:

В соответствии с ответом Igy я попытался разделить процесс очистки объекта с процессом создания действия. Итак, перед тем, как действие было отправлено для совершенно нового объекта, я запустил update для объекта с scrape=true.

begin
    p 'doing fb_update'
    fb_update = RestClient.post 'https://graph.facebook.com', :id=>page_url, :scrape => true
    p 'fb_update is'
    p fb_update
rescue StandardError => e
    p 'e.response is'
    p e.response
end

Выход

2011-11-05T13:27:40+00:00 app[web.1]: "doing fb_update"
2011-11-05T13:27:50+00:00 app[web.1]: "fb_update is"
2011-11-05T13:27:50+00:00 app[web.1]: "{\"url\":\page_url,\"type\":\"website\",\"title\":\page_url,\"updated_time\":\"2011-11-05T13:27:50+0000\",\"id\":\id_here}"

Нечетным является то, что тип website, а заголовок - это URL-адрес страницы. Опять же, я проверил как в HTML, так и в отладчике Facebook, и тип и название в них верны.

Ответы

Ответ 1

Я столкнулся с той же проблемой.

только. Мне удалось успешно опубликовать действия для настраиваемых типов объектов, которые я определил, чтобы вручную проверить URL-адрес объекта с помощью "Отладчик объектов" , а затем опубликуйте действие над этим объектом через мое приложение.

Даже используя API-интерфейс linter, который предлагает Facebook здесь - дает мне ошибку.

curl -X POST \
     -F "id=my_custom_object_url" \
     -F "scrape=true" \
     "https://graph.facebook.com"

Только инструмент отладчика, похоже, действительно очищает страницу.

Обратите внимание, что у меня не было этой проблемы при использовании заданного типа объекта, такого как "веб-сайт":

<meta property="og:type" content="website" />

По какой-то причине эта проблема только влияет на пользовательские типы объектов.

ОБНОВЛЕНИЕ (С РЕШЕНИЕМ):

Я, наконец, понял это. Проблема на самом деле возникла из-за неспособности моего приложения обрабатывать два одновременных HTTP-запроса. (FYI: я использую Heroku для развертывания моего приложения Rails.) Когда вы отправляете запрос API Facebook на публикацию действия по URL-адресу объекта (запрос №1), Facebook немедленно попытается очистить указанный URL-адрес объекта ( запрос № 2), и в зависимости от того, что он умеет успешно очищать, он возвращает ответ на исходный запрос. Если я буду запускать запрос № 1 синхронно, это свяжет мой веб-процесс на Heroku, что делает невозможным одновременное обращение к запросу приложения 2. Другими словами, Facebook не может успешно получить доступ к URL-адресу объекта, который необходимо очистить; вместо этого он возвращает некоторые значения по умолчанию, включая тип объекта "веб-сайт". Интересно, что это произошло, даже когда я выпустил несколько веб-процессов на Heroku. Приложение было намерено использовать один и тот же веб-процесс для обработки обоих запросов.

Я решил проблему, обратившись ко всем запросам API Facebook в качестве фоновых заданий (используя delayed_job). На Heroku это требует подготовки по крайней мере одного веб-процесса и одного рабочего процесса. Если вы можете это сделать, выполнение запросов API в фоновом режиме - это хорошая идея, так как она не привязывает ваш сайт к пользователям, заставляя их ждать несколько секунд, прежде чем они смогут что-либо сделать.

Кстати, я рекомендую запустить два фоновых задания. Первый должен просто очистить URL-адрес объекта POSTING, чтобы: https://graph.facebook.com?id= {object_url} & scrape = true

Как только первое задание успешно завершено, запустите другое фоновое задание, чтобы выполнить POST действие на временной шкале: https://graph.facebook.com/me/ {app_namespace}: {action_name}? access_token = {user_access_token}

БОЛЬШЕ ПОСЛЕДНИЕ ОБНОВЛЕНИЯ:

В соответствии с предложением в комментариях использование Unicorn также будет делать трюк без необходимости delayed_job. Узнайте больше здесь, если вы используете Heroku:
http://blog.railsonfire.com/2012/05/06/Unicorn-on-Heroku.html

Ответ 2

Документы создания объекта говорят, что он должен очистить объект при первом создании против него действия, а также сказать

На некоторых платформах хостинга и разработки, где вы создаете объект и публикуете в Facebook одновременно, вы можете получить сообщение об ошибке, говорящее, что объект не существует. Это связано с состоянием гонки, которое существует в некоторых системах.

Мы рекомендуем вам (a) проверить, что объект реплицирован, прежде чем отправлять сообщение или (b) ввести небольшую задержку для учета задержки репликации (например, 15-30 секунд).

Исходя из этого, я думаю, вам нужно добавить &scrape=true к первоначальному вызову, чтобы принудительно выполнить немедленную очистку, а затем попытаться создать действие позже. (Я считаю, что сообщение об ошибке, которое вы получаете, вероятно, связано с тем, что страница еще не была кэширована/очищена.)

Ответ 3

Из того, что я видел, Страница отладки Facebook является лучшим (и, для большинства практических целей, только) способом принудительного Facebook кэширует данные страницы OpenGraph для обновления. В противном случае вы потратите до недели, ожидая свою кэшированную информацию о страницах, которые они уже очистили.

В принципе, вы должны

  • Перепишите ваши страницы, чтобы действовать по вашему желанию.
  • Передайте соответствующие URL-адреса на страницу отладчика (чтобы убедиться, что они проверяют, и, чтобы обновить кеши), а затем
  • Разрешить страницы для обслуживания "нормально", чтобы увидеть ваши изменения в действии.

Могут быть другие способы заставить тайники Facebook истечь; см. fooobar.com/info/215623/... для некоторых возможных решений. Я еще не пробовал их, но они могут быть полезны.