• [アーティクル]

この記事は機械翻訳されたものです。

Cutting Edge

Facebook プログラミングの基本: 認証とアップデート (機械翻訳)

Dino Esposito

コード サンプルのダウンロード

Dino EspositoFacebook は度で多面的な開発フレームワーク devel を公開されて、豊かで複雑なソフトウェア プラットフォーム­が開きます。 最初は、「Facebook のプログラミング」の意味は明確かもしれない。 Facebook に関係するアプリの基本的に 2 種類があります。 1 つのタイプが住んでいるし、Facebook の環境で繁栄するアプリがあります。 これらのアプリは、Facebook で読み込まれる豊富なウェブページは本質的にページ キャンバスし、メインのサイトでホストされているです。 アプリを使用するには、ユーザーが Facebook のサイトに移動し、自分のアカウントにログインする必要があります。 これらのアプリは、独自のロジックを実装できます —­何でもあなたから JavaScript または他の Web プログラミング テクノロジを使用して Web ページ内で表現できる — と Facebook のグッズ フレンド、ニュースフィード、メディアなどにアクセスできます。 このプログラミングのフォームで開始するには、単に"Facebook.com 上アプリ"ページで行く bit.ly/f5hERV。

Facebook プログラミング別アプローチには、いくつかのコア Facebook の機能は、Web サイト、携帯アプリ （アンドロイド、iOS または Windows Phone など) やデスクトップ アプリケーションなどの既存のアプリケーションに統合することが含まれます。

この記事ではこの Facebook のプログラミングの側面に焦点をし Facebook c# API を使用してユーザーを認証し、プログラムを使用して現在ログインしているユーザーに代わってを投稿する方法について説明します。

Like ボタンを埋め込む

人気のソーシャル ネットワーク Facebook や Twitter などに関しては、最初のレベルの外部アプリケーションとの統合」ページまたはそれについてのつぶやきのようにするには"ad hoc のボタンを使用してです。 ほとんどすべてのプログラミングは不要です。 いくつかのアドホックのマークアップは、Web ページに挿入する純粋なです。

だからあなたの Web サイトがより普及したようにする最も簡単な方法は Facebook のようなボタン、新しい iframe の埋め込みページを訪れるすべてのユーザーはすぐに Facebook にそれを好むことです。 必要な最小限のマークアップはここにあります。

<iframe src="http://www.facebook.com/plugins/like.php?href=XXX">
</iframe>

あなたのようにページの URL に XXX を置き換えます。 さらに、それより良いページの残りの部分をマージするには、iframe 要素に CSS スタイルのビットを追加したいと思うかもしれない。 図 1 は最終結果を示しています。

The Facebook Like Button
図 1 Facebook のようなボタン

Like ボタンは最も単純な （と最も人気のある） Facebook ソーシャル プラグインのです。 ほとんどの時間、フレームまたはアドホック マークアップを介して Web ページでプラグインを統合できます。 いくつかのプラグインは Facebook JavaScript SDK を必要とする、カスタムの Facebook のページがある場合のみいくつかの作業します。 今後のコラムでスクリプティング Facebook を説明します。

社会のプラグインを使用して超えて、Facebook アプリで （と Web サイトだけでなく） という 2 つのメイン タスクを実行することができる統合。ユーザーは自分自身自分の Facebook のアカウントを使用してアプリケーションを認証し、特定のユーザーの Facebook の壁に投稿するアプリを有効にできます。 ユーザー認証を始めましょう。

OAuth と単一の認証モジュールの古い夢

ユーザー認証は、ちょうど約あらゆる重要な Web サイトのコア機能です。 10 年前、1 つのベストセラーのポイント従来の ASP と比較して ASP.NET の認証層に通常要する時間の割合の開発を容易に高い再メンバーシップ システムの可用性だった。

これらの日、ただし、カスタム認証層を有するに魅力的なオプションです。 アドホック認証レイヤーを実装することで、開発者自身アカウント以上の何千もの管理コストと安全にパスワードを格納するための責任を作る。 ユーザーは、それを覚えてまだ別のユーザー名/パスワードのペアを意味します。

年前に、Microsoft パスポート イニシアチブ彼らはいくつかの関連するサイト間で移動するときのユーザーの生活を楽にスマートが、おそらくあまりにも早い試みだった。 パスポートの後ろの考えは、ユーザーがちょうど自由にすべての関連付けのサイトを介して移動する単一の成功したログオン必要があった。

旧バージョンの ASP.NET とバンドルされて、パスポート API 今は公式に行った。 ただし、それを解決するには、考案された問題はまだ存在です。

今日では、OpenID (openid.net） 偉大なオプションは、ユーザー認証しますが、ないする必要がある Web サイトのそれらはまだと別の資格情報のセットを充電したいです。 OpenID は、あなたのサイトを使用してあなたのための認証を管理するサード パーティのサービス プロバイダーに接続するシングル サインオン (SSO) プロトコルです。 OpenID 対応サイトには、先頭と末尾の認証タスクのみを管理します。 ユーザー構成された OpenID プロバイダーにリダイレクトし、戻ってすべてが起こったときに id 情報を取得します。

OpenID 人気の流行語ですが、もう 1 つはさらに議論されています。OAuth (oauth.net)。 違いは何ですか？

OpenID は、排他的な SSO のプロトコルです。 OpenID プロバイダーには、登録済みユーザーの id のみを管理します。 しかし、Twitter や Facebook などのソーシャル ネットワーク以上必要があります。 1 つのアプリは、単に Facebook 経由で認証ユーザーできるようにする可能性があります。 別の Facebook 経由での認証が、またユーザーのウォールへの投稿する必要があります。 まだ別のアプリは、ユーザーのタイムラインと最近の活動を読みたいでしょう。 すべての上に （これは OpenID プロトコル経由で管理できる) 認証ですが、同じユーザーが異なるアプリケーションに異なるアクセス許可を与えることができます。 そしてこれは OpenID に設計されていない側面ですハンドルします。

OAuth は、さえずりと Facebook を使用して認証と承認を処理するプロトコルです。 OAuth プロバイダーは単に id 情報を返しません。 それは彼がアプリケーションに付与したい、その後すべての資格情報とアクセス許可は、アクセス トークンにパッケージ アクセス許可ユーザーを求めます。 クライアント アプリケーションは、ユーザーに代わって任意の許可されている操作を実行するアクセス トークンを通ります。 1 つの利点の OAuth （と OpenID 同様） プロバイダーがアプリケーションへのユーザーの資格情報は開示することです。 さらに、OAuth を使用すると、エンド ユーザーは任意のアプリケーションにアクセス許可をいつでも取り消すことができます。 だから、例えば、いくつかの時点でアプリケーション XYZ を認証することを想像する Twitter (または Facebook) を使用して、お客様に代わってポストに XYZ のアクセス許可を付与します。 Twitter (または Facebook) プロフィール ページを単に行くことによって、このいつでも許可を取り消すことができます。 OAuth プロトコルによって返されるアクセス トークンがアプリケーションとユーザー固有であることに注意してください。 ユーザーは、彼は上の複数の OAuth ベースのアプリを営もうとする、複数のアプリケーションにログインする必要があります。 OAuth は、ユーザーの認証は、HTTP ベースのプロトコルです。 (たとえば、「カバーの下に」物事の仕組みを学ぶ） ことができるにもかかわらずしばしば HTTP 要求を手動で記述する必要はありません。 Microsoft .NET Framework では、DotNetOpenAuth (dotnetopenauth。 などの汎用のライブラリを使用できます。 net) または Twitter と Facebook の Facebook c# SDK の TweetSharp など、特定の社会的ネットワークのための既製のフレームワークを拾います。

認証に関しては、Windows Azure アクセス管理サービスをご覧ください。 これは、フェデレーション id プロバイダーとして機能できますが、複数の id プロバイダーのマッピングを翻訳することができます。 それは、OAuth およびセキュリティ アサーション マークアップ言語ベースのトークンから Active Directory をホストできます。 それも Facebook と新しい ClaimsPrincipal クラス、.NET Framework で動作するように構築されています。

Facebook を介してユーザーを認証します。

基本的な ASP.NET MVC サイトを開始させて、NuGet Facebook c# SDK でプラグインを使用 (を参照してください図 2)。 ASP.NET MVC のサンプル サイトにまったく新しい認証コント ローラーを私は FacebookLogin、FacebookAuthenticated およびログオフという 3 つの方法で濃縮されています。 最初の 2 つの方法は OAuth の相互作用の 2 つの手順を表す; Logoff メソッドは、ちょうどホスト アプリケーションからユーザーをログオフします。 Facebook からのユーザー ログオンするログオフ操作が想定されていないことに注意してください。 OAuth と Facebook c# SDK のみ認証ロジックを管理 — クッキーを介して認証情報の永続化は、ASP.NET MVC サイトまでまだです。

Referencing the Facebook C# SDK via NuGet
図 2 NuGet を介して Facebook c# SDK を参照します。

サイトのホームページへのリンク、ユーザー ログインにしたいとクリックを提供します （を参照してください図 3)。 リンクは、単に FacebookLogin アクション コント ローラーで認証を指すアンカー イメージ (またはテキスト) にすることができます。

<a href="/Auth/Logon" >
  <img src="@Url.Content("~/Content/Images/loginfb.png")"  
    style="border:0" alt="Sign in with FB" />
</a>

The Button to Trigger the Facebook Authentication Process
図 3 Facebook の認証プロセスをトリガーするボタン

標準の ASP.NET MVC サイトでは、このマークアップは、_logOnPartial.cshtml ページに属しています。 それなら、ぜひこの認証のコント ローラーがあてみましょう。

FacebookLogin アクションで — 名前は任意です-物事のカップルを行う必要があります。 最初に、あなたは、一度、OAuth プロバイダーから呼び出される認証手順を完了するためにあなたのアプリを引き起こす URL を手配します。 私が考えているサンプル アプリケーションでは、URL は Auth コント ローラー上の FacebookAuthenticated アクションをポイントします。 仕事のこのような便利な UriBuilder クラスを使用できます。

var uri = new UriBuilder(Request.Url)
  {
    Path = Url.Action("FacebookAuthenticated", "Auth")
  };

2 番目の FacebookLogin アクションでやるべきことは、Facebook の URL をログインを手配です。 Facebook c# SDK を使用する場合は、必要なコードは次のここです。

var client = new FacebookClient();
var appId = ConfigurationManager.AppSettings["fb_key"];
var returnUri = uri.Uri.AbsoluteUri;
var fbLoginUri = client.GetLoginUrl(new
  {
    client_id = appId,
    redirect_uri = returnUri,
    response_type = "code",
    scope = "email"
  });

GetLoginUrl メソッドに渡すパラメーターは、URL を準備するため。 図 4 パラメーターの詳細について説明します。 アクションは、返されるログイン URL にユーザーをリダイレクトすることにより FacebookLogin を終了します。

図 4 ログイン パラメーター

[パラメーター] 説明
client_id ユーザー アプリケーションと Facebook のサイト間のプロキシとして動作するアプリの Facebook の ID です。 あなたの Facebook アプリを登録するときにこの一意の文字列を得る。
redirect_uri 認証の完了を返す URL (id 情報をつかむし、認証 cookie を作成するなど)。
response_type これは、「トークン」または「コード」をすることができますや Facebook が認証が成功した後、アクセス トークンを返す方法を指します。 このアクセス トークンを保障するので Web サイトでは、それ「コード」をする必要があります — 情報の機密部分 — を URL に追加されません。
スコープ ユーザーに要求する追加のアクセス許可を示します。 スコープ パラメーターが空白の場合は、アプリケーションにアクセスするユーザーの名前、画像、性別などの基本情報があります。 このパラメーターを通じて、投稿できるようにする出版のストリームと同様に電子メール アドレスを要求できます。 アクセス許可の完全なリストで入手可能です bit.ly/NCcAgf。

Facebook (や Twitter） を介してユーザーを認証するには、まず Facebook （または Twitter） アプリを登録し、その関数のいくつかのユニークなコードを取得する必要があります。 新しい Facebook アプリを登録するに行く bit.ly/mRw8BK。 アプリが正常に作成すると、Facebook あなたはアプリの ID 文字列とされているページの表示アプリの秘密文字列を与える図 5。

Registering a New Facebook App
図 5 新しい Facebook アプリを登録します。

アプリケーション ID およびアプリケーションの秘密は、Web サイトまたは他の種類のユーザー アプリケーション内から Facebook の操作を実行する必要があります。 アプリケーション ID およびアプリケーション シークレット ラッパー アプリケーションの構成ファイルを格納するが一般的です：

<appSettings>
  <add key="fb_key" value="xxxxxxxxxxxx"/>
  <add key="fb_secret" value="yyyyyyyyyyyyyyyyyyyyy"/>
</appSettings>

Facebook のログイン URL は、それがユーザーを認証することができますか。 特に、ユーザーが Facebook に現在ログオンしている場合は、リクエスト トークン準備されすぐに指定した戻り先 URL に送信 — この場合は、この FacebookAuthenticated アクションです。 マシンに現在にログオンあるユーザーがいない場合は、Facebook は、クラシック ログイン ページが表示されます。 そうすること、それはまた app を要求するアクセス許可を一覧表示します。 少なくとも権限は懸念を電子メール アドレスと表示名。 しかし、彼らは、ユーザーに代わってポストまたはメディア ストリーム、友人、タイムラインにアクセスする権限などがあります。 ユーザーは、明示的承認またはこれらのアクセス許可を拒否する要求です。 完全なアクセス許可のリファレンス情報で見つけることができます bit.ly/P86tTC。

認証プロセスを確定

認証を完了するには、要求し、アクセス トークンを解析するように必要図 6。 メソッド ParseOAuth­CallbackUrl では、Facebook からアクセス コードを取得することができます。 このコードは Facebook のアカウントを制御するのに十分ではない; それはアクセス トークンを交換する必要があります。 OAuth プロトコルによると、これは別のステップと別の HTTP 要求が必要です。 あなたの Web サイトは、特定のユーザーと特定の Facebook アプリのアクセス トークンを保持すると、明示的に与えられているユーザーの Facebook のアカウントのアクセス許可の制御を得る。 最低限、最初と最後の名前など、ユーザーに関する情報を取得し、許可された場合、電子メール アドレスには、権限のあります。

図 6 認証を確定

public ActionResult FacebookAuthenticated(String returnUrl)
{
  // Prepare the return URL
  var returnUri = new UriBuilder(Request.Url) {
    Path = Url.Action("FacebookAuthenticated", "Auth")
  };
 
  // Parse response to get the access code
  var client = new FacebookClient();
  var oauthResult = client.ParseOAuthCallbackUrl(Request.Url);
 
  // Exchange the code for the access token   
  dynamic result = client.Get("/oauth/access_token",
    new {
      client_id = ConfigurationManager.AppSettings["fb_key"],
      client_secret = ConfigurationManager.AppSettings["fb_secret"],
      redirect_uri = returnUri.Uri.AbsoluteUri,
      code = oauthResult.Code
    });
 
    // Saves the token to a cookie for further access
    var token = result.access_token;
    FbHelpers.AccessTokenSave(Response, token);
 
    // Grab identity information using the access token
    dynamic user = client.Get("/me",
      new {
        fields = "first_name,last_name,email",
          access_token = token
      });
 
    // Create the ASP.NET authentication cookie
    var userName = String.Format("{0} {1}",
      user.first_name, user.last_name);
  FormsAuthentication.SetAuthCookie(userName, false);
 
  // Back home
  return Redirect(returnUrl ?? "
/");
}

あなたの唯一の目的は Facebook を介してユーザーを認証する場合、標準の ASP.NET の認証 cookie を作成して完了です。 あなたのアプリケーションがもっとやりたい場合 (たとえば、ユーザーに代わって投稿) 認証 cookie と同じ有効期間提供できるようにアクセス トークンを格納する必要があります。 アクセス トークンは、データベースまたは cookie に保存できます。 いっそのこと、カスタム プリンシパルを作成し、ASP.NET の認証 cookie 内の余分なユーザー データとしてアクセス トークンを格納できます。 私のサンプル アプリケーションでは、私だけは、FbHelpers クラスによって管理される追加の cookie を作成しています (詳細は付属のソース コードを参照)。

しかし、アクセス トークンがいくつかの有効期限の規則の対象であることに注意してください。 サーバー側コード (つまりはユーザーを Facebook のサイトには、ここで説明したように認証を送信) を使用して認証する場合、あなたは 60 日間続きます長期トークンを得る。 JavaScript SDK を使用してクライアント側の認証を試みる場合は、あなたは 2 時間後に期限が切れる短命トークンを取得します。 この期間が 60 日に 2 番目の呼び出しを特定のエンドポイントのことによって拡張できます。 いずれの場合では、アクセス トークンの有効期限が切れると、ユーザーは再度認証し、有効なアクセス トークンを再取得する必要があります。 ここは、コーディングの良い方法です：

try {
  var client = new FacebookClient(...);
  dynamic result = client.Get("me/friends");
} catch (FacebookOAuthException) {
  // Your access token is invalid or expired.
}

全体の話で well-summarized です bit.ly/Qfeh5s。

ユーザーの壁に掲示

アクセス トークンはユーザー/アプリケーションのペアを保持するとき OAuth シナリオでは、プログラムで任意のユーザーがアプリケーションに権限を与えるインタラクティブ操作実行できます。 ユーザーの壁へのメッセージを投稿するには、次のコードを必要します。

public static void Post(String accessToken, String status)
{
  var client = new FacebookClient(accessToken);
  client.Post("/me/feed", new { message = status });
}

コント ローラー アクション メソッド内からこのヘルパー メソッドを呼び出します。 アクセス トークン文字列それを保存場所からカスタム cookie か、認証 cookie、または永続ストアを取得しなければなりません。 アクセス トークンを紛失した場合、[post 操作が成功するために、ユーザー ログアウトして再度ログインする必要があります。 Facebook に対してタスクを実行する場合、ブラウザーの再起動を存続する方法で、アクセス トークンを格納するキーです。 図 7 、メッセージとユーザーの壁を適切に更新を投稿サンプル アプリケーションを示しています。

Posting to the Wall
図 7 の壁に掲示

次回のトピック:Windows Presentation Foundation

要約すると、Facebook を通じて独自のアプリの開発者は Facebook のコンテンツとロジック統合できますかなり豊富な API を公開します。 Facebook アプリは Facebook の境界内の生活は確かに埋め込まれたアプリですが、彼らも古典的な Web またはデスクトップ アプリケーションの外部での生活します。 このコラムで Facebook c# SDK を 2 つのシンプルだが非常に共通の操作を実行するために使用されます。彼女の Facebook のアカウントを使用してサイトのページを使用して現在のユーザーの壁に投稿する Web サイトのユーザーを認証します。 次回のコラムでは、Facebook Api の使用のセットを展開し、Windows Presentation Foundation アプリケーション内から同じ操作を実現する方法について説明します。

Dino Esposito 「キテクチャ携帯ソリューションは、エンタープライズ」(マイクロソフト プレス、2012年） の著者であると"プログラミング ASP.NET MVC 3"(マイクロソフト プレス、2011年） と共著「Microsoft .NET:Architecting Applications for the Enterprise』(Microsoft Press、2008 年) の共著者でもあります。 Esposito はイタリアに在住し、世界各国で開催される業界のイベントで頻繁に講演しています。 彼を Twitter 上でフォロー twitter.com/despos。

この記事のレビュー、次技術専門家のおかげで： スコット ・ デンスモア