記載されているdocumentationの和訳と、調べていて分かったノウハウを紹介します。we.ドキュメント全体の目次はこちらFacebook関連情報はFacebookページで共有しています。Vol.7で登壇しましたので、発表内容をまとめておきます。話した内容はざっくり以下の3点です。混同してしまうpublish_streamとpublish_actionsパーミッションの違いを、最近の仕様変更をふまえて紹介する認証ダイアログの1ページ目と2ページ目の違いと、先述したパーミッションの扱いの違い実装に落とし込む30分の発表時間に対して若干詰め込みすぎな感じがありましたので、スライドや発表内容から削った部分も補足しつつ3エントリーに分けて紹介します。実装の最初の段階でしか考えないまず現状として、ユーザからのパーミッション取得はアプリのインストール時(利用開始時)の認証ダイアログに頼っている場合が多いと思います。ユーザがログインボタンを押すと以下のようなURLへリダイレクトされ、Facebook認証ダイアログが表示されるような使い方です。&state=SOME_ARBITRARY_BUT_UNIQUE_STRINGユーザがアプリをインストールすればscopeで指定したパーミッションが許可され、その権限に従ってアプリはユーザの代理として情報の読み書きが出来ます。ここでパーミッションを取得する仕組みを作り、あとは機能の実装となる為、認証部分の実装以降はパーミッションの扱いはないがしろになってしまいます。それでも仕様変更は多い後から見返すことは少ないとはいえ、直近数ヶ月だけでも大きめの変更はたくさんあります。(5月廃止の予定が7/5になり、現状10/3に延期されています)offline_access廃止に関してはすでに色々な方が話されているので、ここではpublish_streamとpublish_actionsの変更と認証ダイアログの移行についておさらいします。Graphアクションの実装用に追加されたパーミッションで比較的新しい物です。Graphアクションを投稿することが可能となります。それに対しpublish_streamは昔からある物で、ユーザ自身のウォール、友だちのウォール、グループやイベントへ投稿したりできるほか、コメントに対していいね!できるなど、投稿系で必要とされるパーミッションです。Graphアクションを投稿しようとした場合、publish_streamとpublish_actionsパーミッションの両方を求める必要があったという点です。これらの背景については、publish_streamとpublish_actionsパーミッションの統合というエントリーで紹介しています(統合という表現を選んだのを後悔してます)。以前の仕様の問題点を克服するため、publish_actionsとpublish_streamの位置づけが大きく変わりました。それぞれのパーミッションでできることを一覧にしてみます。publish_actionsの持つ全ての権限を持っています。書き込めるなどの書き込み権限も与えられています。旧仕様に従ってpublish_streamを求めたままになっているアプリでも、大体はpublish_actionsさえ要求すれば事足りるということが分かります。publish_streamを要求しておけばpublish_actionsの権限もカバーできるので楽ですが、友だちのウォールにまで投稿されてしまうかもしれないpublish_streamと、自分のウォールに限定されるpublish_actionsでは、ユーザにとっての不安の度合いは大きく変わるはずです。1部のスパムアプリのせいでFacebookアプリ全部が疑われてしまうと心配するだけでなく、自分たちも必要最小限のパーミッションのみ要求し、ユーザを不安にさせないアプリ作りをすることが必要なんじゃないかと思っています。publish_streamの扱いの違いを紹介します。返され方が変わります動画の削除機能はドキュメントの誤りで、実はサポートされてませんでした。