Webアプリのユーザーが、1つのページ(main_page)からタイムラインに複数のオブジェクトを投稿できるようにしたいと思います。
ユーザーのアクセストークンはすでに保存されています。
送信しようとしているページのタグ。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" />
Main_pageからトリガーされたURLを送信するRailsコード:
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\"}}"
本当に奇妙なことは、このエラーが発生した後、 Object Debugger でpage_urlをテストすると、エラー/警告なしで合格し、og:type
が正しいタイプであり、'website'
に注意してから同じRails上記のコードを実行すると正常に動作します。
og:url
タグなしで試してみましたが、同じことが起こります。
更新:
Igyの答えに従って、オブジェクトスクレイピングプロセスをアクション作成プロセスから分離してみました。そのため、新しいオブジェクトに対してアクションが送信される前に、オブジェクトに対してscrape=true
を使用して pdate を実行しました。
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デバッガーの両方をチェックしましたが、タイプとタイトルはどちらも正しいです。
私は同じ問題に直面しています。
only方法で、自分が作成したカスタムオブジェクトタイプのアクションを正常に公開できました定義されているのは、最初に Object Debugger を使用してオブジェクトのURLを手動でテストし、次に次にアプリケーションを介してそのオブジェクトに対するアクションを投稿することです。
Facebookが提案しているリンターAPIを使用しても ここ -エラーが発生します。
curl -X POST \
-F "id=my_custom_object_url" \
-F "scrape=true" \
"https://graph.facebook.com"
デバッガツールだけが実際にページを正しくスクレイプしているようです。
「website」などの事前定義されたオブジェクトタイプを使用する場合、この問題は発生しなかったことに注意してください。
<meta property="og:type" content="website" />
この問題は、何らかの理由でカスタムオブジェクトタイプにのみ影響するようです。
更新(ソリューションあり):
私はついにこれを理解しました。この問題は、実際には、アプリケーションが2つの同時HTTP要求を処理できないことから発生しました。 (参考:Herokuを使用してRailsアプリケーションをデプロイしています。)オブジェクトURLでアクションを公開するようにFacebook APIにリクエストすると(リクエスト#1)、Facebookはすぐに指定したオブジェクトURL(リクエスト#2)をスクレイプしようとすると、正常にスクレイプできるものに基づいて、元のリクエストへの応答が返されます。リクエスト#1を同期的に実行していると、Webが拘束されます。 Herokuで処理するため、アプリケーションがリクエスト#2を同時に処理できなくなります。つまり、Facebookはスクレイプする必要のあるオブジェクトURLに正常にアクセスできず、代わりに、オブジェクトを含むいくつかのデフォルト値を返します。 「website」と入力します。興味深いことに、これはHerokuで複数のWebプロセスを起動した場合でも発生しました。アプリケーションは、同じWebプロセスを使用して両方のリクエストを処理することを目的としていました。
すべてのFacebookAPIリクエストをバックグラウンドジョブとして処理することで問題を解決しました( delayed_job を使用)。 Herokuでは、これには少なくとも1つのWebプロセスと1つのワーカープロセスを起動する必要があります。それができれば、APIリクエストをバックグラウンドで実行することをお勧めします。これは、ユーザーのWebサイトを拘束せず、ユーザーが何かを実行できるようになるまで数秒待つためです。
ちなみに、2つのバックグラウンドジョブを実行することをお勧めします。最初のものは、POSTしてオブジェクトのURLをスクレイプする必要があります: 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
オブジェクト作成ドキュメント オブジェクトに対してアクションを最初に作成するときに、オブジェクトをスクレイプする必要があると言いますが、
オブジェクトの作成とFacebookへの公開を同時に行う一部のホスティングおよび開発プラットフォームでは、オブジェクトが存在しないというエラーが表示される場合があります。これは、一部のシステムに存在する競合状態が原因です。
(a)アクションを投稿する前にオブジェクトが複製されていることを確認するか、(b)複製の遅延(15〜30秒など)を考慮してわずかな遅延を導入することをお勧めします。
それに基づいて、すぐにスクレイプを強制するために最初の呼び出しに&scrape=true
を追加し、しばらくしてからアクションを作成する必要があると思います。 (表示されるエラーメッセージは、ページがまだキャッシュ/スクレイピングされていないことが原因である可能性があります。)
私が見たところ、 Facebook Debugger Page は、Facebookのキャッシュを強制するための最良の(そして、ほとんどの実用的な目的では、only)方法です。更新するページのOpenGraph情報を指定します。それ以外の場合は、最大1週間、すでにスクレイピングしたページに関するキャッシュ情報を待つことになります。
基本的に、あなたはすべきです
Facebookのキャッシュを強制的に期限切れにする他の方法があるかもしれません。いくつかの可能な解決策については、 このStackoverflowページ を参照してください。まだ試していませんが、役に立つかもしれません。