今日のFacebook開発者ブログ
2011年05月15日のFacebook開発者ブログ（http://developers.facebook.com/blog）
コメントボックス内のスレッドからサブスクライブとアンサブスクライブができるようになった。
興味深い議論があったら、subscribe リンクをクリックするだけで、そのスレッドに返事が付いたときに通知がなされるようになる。
Like Story Feedbackがインサイトに追加された。サイトのページに何人が「いいね！」と言い、何人がコメントを付けたかがわかる。
Graph APIと Insights FQLテーブルで、 Sendボタンのアクティビティに関する情報が取得できるようになった。Sendボタンに関しては、ユーザーがSendボタンをみてクリックする、受信者が送られた項目をみてクリックするなど一連のアクションが起きる。各アクションを以下で取得できる。
" domain_widget_send_views
" domain_widget_send_clicks
" domain_widget_send_inbox_views
" domain_widget_send_inbox_clicks
各メトリクスは、アプリで指定されたドメインごとに集計される。アプリのアクセストークンを用いて、Graph APIでインサイトデータを取得するPHPコードのサンプルが示されている。
昨日の、How-To: Handle expired access tokensでは、アクセストークンが無効になったときの対処方法がPHPの場合に具体的に記されている。
本日のFacebook開発者ブログ
Developer Roadmap Update: Moving to OAuth 2.0 + HTTPS
(http://developers.facebook.com/blog/post/497)
http://www.facebook.com/blog.php?post=486790652130では、Facebookユーザーのアカウント設定で
セキュアな接続(https)
利用できる場合は、セキュアな接続でFacebookにアクセスする
というチェックボックスが追加されたが、
今回は開発者アプリでのFacebookアプリのFacebook Integration設定で、
Secure Canvas URLとSecure Tab URLのフィールドが追加された。
このようなFacebookを安全な環境で使用するという試みの一環で、古いFacebook認証システム＆HTTPからOAuth 2.0＆HTTPSへの移行が進められてきた。そして、Facebook開発者ロードマップ（http://developers.facebook.com/roadmap/）が以下のように更新された。
新しいPHP SDKとJavaScript SDK（７月１日）：OAuth 2.0を利用できるように、PHP SDKとJavaScript SDKを更新し、（アクセストークンなしの）新しいクッキーフォーマットを持たせる。JavaScript SDKを直接参照している場合は、その変更は自動的に行われる。
OAuth 2.0への移行（９月１日）：すべてのアプリは、OAuth 2.0へ移行し、暗号化されたアクセストークンを受け取れないといけない。fb_sig パラメータを使用していたCanvasアプリは、code パラメータをセッションキーとセッションの秘密パラメータとして使用するように修正が必要だろう。
signed_request への移行（１０月１日）：すべてのキャンバスアプリはsigned_requestを処理しなければいけない（fb_sig は削除される）。そしてSSL証明書を取得しなければいけない（サンドボックスモードを除く）。これにより、セキュアな接続でFacebookにアクセスするユーザーにさらなる安心を与える。signed_request をデコードするPHPコードのサンプルと、詳細なドキュメントへのリンクがブログで紹介されている。
古いFacebook Connectの認証フロー（login.php）を直接使用している場合は、 OAuth 2.0へ移行する必要がある。JavaScript SDKを直接使用している場合は、自動的に変更される。
Gmailなどについて今日調べたこと
Google はヨーロッパおよびアメリカのセーフ ハーバー プログラム（Safe Harbor Program）に登録しているが、ISMS取得業者と同等に扱うことが可能か？
無料のGmailは、スパム対策とウイルス対策が標準で搭載されている。
Google Apps Premier Edition は、１アカウントあたり年間6000円のコストがかかる。
Google Apps for Businessも同じ値段。というか、Google Apps Premier EditionがGoogle Apps for Businessに名称変更された。
エイリアスを設定することはできるのか。
http://www.google.com/support/a/bin/answer.py?answer=182527
は、ユーザーが別のアドレスでもメールを受け取れるという話で、求めているものとは違う。
postmasterやwebmaster宛のメールを複数のユーザーに割り振りたいという話。
http://www.google.com/support/a/bin/answer.py?hl=ja&answer=167085
グループアドレスを用いることで対処可能なようだ。
http://www.google.com/support/a/bin/answer.py?answer=47283&hl=ja
を見る限り、DNSはGoogleではなく、独自に管理しなければいけないようだ
DNSのホスティングサービス
http://www.kddi.com/business/kddi_dnshosting/index.html（月2940円）
http://domain.nifty.com/domain/dnshos.htm（月額 1,050円/20レコード毎（税込））
http://www.sakura.ad.jp/function/upgrade/nameserver.html（月額 1,050円/10レコード毎（税込））
Web Arena
http://web.arena.ne.jp/suitex/spec/domain/dns.html(1ゾーンにつき初期料金：1,050円、月額料金525円)
標準のDNSサーバ（SuiteX内のホスト限定）は無料
レンタルサーバーWebARENA SuiteX（スイートエックス）：30GBで23,760円/年から
今日のFacebook開発者ブログ
http://developers.facebook.com/blogからの最新情報。
テストユーザーのパスワードをGraph APIを用いてリセットできるようになった。
パスワードはテストユーザーが作成されたときにしか、返されないので、
パスワードを記録するか、必要となるたびにリセットして使用する。
テストユーザーを作成し、パスワードをリセットするPHPコードの例が記されている。
"https://graph.facebook.com/oauth/access_token?" .
"client_id=" . $app_id .
"&client_secret=" . $app_secret .
"&grant_type=client_credentials"
というURLにアクセスすることで、アプリケーションに対するアクセストークンを取得する。
"https://graph.facebook.com/" . $app_id
. "/accounts/test-users?installed=true"
. "&permissions=read_stream&method=post&"
. $app_access_token;
上で取得したアクセストークンを用いて、テストユーザーを作成する。
"https://graph.facebook.com/" . $obj->{'id'}
. "?password=" . $new_password . "&method=post&" . $app_access_token;
$objはテストユーザー作成のレスポンスとして返ってきたJSONをデコードしたもの。
$new_passwordは任意のパスワードを自分で設定することができる。
アプリケーションで作成できるテストユーザーの数も500に増えた。
商品購入の直前などでは、ユーザーにパスワードを再入力させたい時がある。
https://www.facebook.com/dialog/oauthやhttps://graph.facebook.com/oauth/authorize
での認証リクエストに以下のパラメータが追加された。
auth_type:必要となる認証機能を以下のオプションから指定する。
https：セキュアなクッキーの存在を確認し、存在しなければ再認証を要求する
reauthenticate：無条件で再認証を要求する
auth_nonce:リプレー保護を行うために、アプリケーションが指定した英数字のナンスを指定する。このパラメータはオプションであるが、auth_typeにreauthenticateを指定した場合は特に、指定することを推奨する。
フォーム上のボタンを押したときに、再認証のダイアログを出すPHPのサンプルコードが示されている。
Facebookについて今日調べたこと
Platform Updates: Operation Developer Love（http://developers.facebook.com/blog/post/495）では、アプリケーションに与えた許可をGraph APIで取得する例が紹介されていた。
4月26日（日本だと27日？）にFacebook Developer site（http://developers.facebook.com/）を移行したらしいが、そのせいか、5月2日10時ごろ日本からアクセスすると、いつもより遅いように感じた。
http://developers.facebook.com/docs/reference/plugins/like/のFAQより
Facebookは、自サイト内で外部ページがどのように表示されるかを知るために、外部ページの収集を行っている。24時間ごとに収集は行われる。Open Graph ページの管理者がLikeボタンを押したときや、Facebook URL LinterにURLが入力されたときにも収集は行われる。スクライパーのユーザーエージェントは、 "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
Facebookでの国際化
FXBMLでは、'//connect.facebook.net/en_US/all.js';のen_USの部分を書き換える。
iframeでは、src="http://www.facebook.com/plugins/like.php?locale=fr_FR&..."とlocaleパラメータを指定する。
Graph APIによるコメントへのアクセス
コメントの総数などは、https://graph.facebook.com/?ids=http://example.com/
実際のコメントは、https://graph.facebook.com/comments/?ids=http://developers.facebook.com/docs/reference/plugins/comments（デフォルトでは25件ずつ返される）
Facebookなどについて今日調べたこと
http://www.atmarkit.co.jp/fsmart/articles/facebookappli01/01.htmlに書かれている、Facebookのプラットフォームでできること。
・「Facebookページ」という団体／企業／個人のためのプロモーション／交流用ページを作る。
・「ソーシャルプラグイン（Social Plugins）」と呼ばれるガジェット（例：「いいね！」ボタンなど）を配置することで外部のWebサイトをFacebookの一部のようにする。
・外部のアプリで、Facebook Graph APIを使用し、「ソーシャルグラフ（Social Graph）」と呼ばれるFacebookが持っている各種データにアクセスする。各種データとは、Facebook上のアカウントの基本データ（名前、写真、友達リストなど）やプロフィール情報といった固有の情報である。
http://www.atmarkit.co.jp/fsmart/articles/opensocial01/opensocial01_1.htmlによると、
「SNSが場所を提供し、開発者がそのうえにアプリケーションを作って提供する」という分業を最初に始めたのはFacebookである。Facebookは、「SNS利用者」「SNSオーナー」「アプリケーション開発者」の三者のメリットが合致したから成功した。
" SNSサービスのファミレス化（万人が納得するサービスしか提供されない）に飽きてしまう「SNS利用者」
" 利用者のニーズが多様化し過ぎて、対応に困る「SNSオーナー」
多くの利用者がいるのに、サービスを提供できない「アプリケーション開発者」
という問題が、Facebook APIによる、「SNSという場の運営」と「アプリケーション開発」の「分業」で鮮やかに解決された。
" 「SNS利用者」は、多くのアプリケーションを選択し、自分に合ったサービスを利用できるようになった
" 「SNSオーナー」は、外部アプリケーションを受け入れることで、リスクを取らずに多様なサービスをSNS利用者に提供できるようになった
" 「アプリケーション開発者」は、自分たちが得意なアプリケーションを作り（もしくは、あらかじめ作ってあるサービスと連携させ）、多くの「SNS利用者」に対してサービスを提供して収益を上げることができるようになった
各SNSが独自にAPIを提供すると、主なSNSにしか、開発者は対応できない。
そこで、Googleは「Facebook」以外のSNSサイトに、共通APIである「OpenSocial」の採用を働き掛けた、
「アプリケーション開発者」は、1つの共通APIに対応するだけで、OpenSocialに対応したすべてのSNSに対して、アプリケーションを提供する準備が可能となる。
「共通APIに対応するSNS側」にとっては、多くの開発者が作ったアプリケーションが手に入る。
http://www.facebook.com/help/?page=1096にFacebookアプリ開発に関するFAQがまとめられている。
