本文章是由機器翻譯。

技術最前線

基本的 Facebook 程式設計：驗證和更新

Dino Esposito

下載代碼示例

Facebook 是一個豐富和複雜的軟體平臺，其中公開向開發一個複雜和多方面的發展框架­opers。首先，"Facebook 程式設計"的含義可能並不清楚。有本質上是兩種類型的應用程式有關的 Facebook。一種類型包括生存和繁榮在 Facebook 環境內的應用程式。這些應用程式是本質上是豐富的網頁在 Facebook 中載入畫布頁和承載為主的網站。若要使用該應用程式，使用者需要導航到 Facebook 網站並登錄到他們自己的帳戶。這些應用程式可以執行他們自己的邏輯 — —­無論您可以表示從內使用 JavaScript 或其他 Web 程式設計技術的 Web 頁面 — — 並可以訪問 Facebook 如朋友、 新聞、 媒體和更多的好東西。若要開始對這種形式的程式設計，只是轉到"Facebook.com 上的應用程式"頁 bit.ly/f5hERV。

Facebook 程式設計的另一種方法涉及到將一些核心 Facebook 功能集成到現有的應用程式，如 Web 網站、 手機應用程式 （例如，Android、 iOS 或 Windows Phone） 或桌面應用程式。

在這篇文章我專注于這方面的 Facebook 程式設計和討論如何使用 Facebook C# API 來驗證使用者身份並代表當前登錄的使用者以程式設計方式發佈。

嵌入的 Like 按鈕

當它來到 Facebook 和 Twitter 等熱門社交網路時，與外部應用程式集成的第一級是使用特設的按鈕，"喜歡"的頁或談論它。幾乎沒有任何程式設計是必需的 ； 它是純粹的 Web 頁中插入一些特設的標記。

所以最簡單的方法，使您的 Web 網站更受歡迎，是在新的 iframe 中嵌入的 Facebook 類似按鈕，以便訪問這個頁面的任何使用者可以立即在 Facebook 上喜歡它。這裡是您需要的最小標記：

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

你替換的頁面的 URL，喜歡 XXX。 此外，可能要添加的 CSS 樣式有點到 iframe 元素，使其更好地與頁面的其餘部分合併。 [圖 1] 顯示最終的結果。

圖 1 的 Facebook 類似按鈕

Like 按鈕是最簡單 （和最受歡迎） 的 Facebook 社會外掛程式程式。 大多數情況下，您可以在您的網頁通過幀或特設的標記集成外掛程式。 某些外掛程式需要 Facebook JavaScript SDK，和一些只工作如果您有自訂的 Facebook 頁面。 我將討論腳本 Facebook 在以後的專欄中。

超出使用社會的外掛程式，整合 Facebook 中的應用程式 （和不只是 Web 網站） 的手段，要能夠執行兩個主要任務：讓使用者驗證自身身份與您的應用程式使用他們的 Facebook 帳戶，和使應用程式發佈到特定使用者的 Facebook 牆上。 讓我們開始與使用者身份驗證。

OAuth 和單一的身份驗證模組的舊夢

使用者身份驗證是任何重大的 Web 網站的核心功能。 十年前，相比傳統的 ASP ASP.NET 的暢銷點之一是時間的促進發展的一個身份驗證層中通常所需的一小部分的高度可重用的成員資格系統的可用性。

這些天，但是，有一個自訂身份驗證層是一個誘人的選項。 通過實施特設身份驗證層，開發人員使自己負責安全地存儲密碼和管理數以千計的帳戶或更多的費用。 對於使用者來說，這意味著又一次的使用者名/密碼對，要記住。

年前，微軟護照的倡議是一種聰明但可能太早的企圖，使使用者的生活更容易，當他們跨幾個相關網站移動。 護照背後的想法是使用者只需要成功登錄一次，來自由地流覽所有的相關網站。

與舊版本的 ASP.NET 捆綁在一起，護照 API 是現在正式去了。 然而，它設計來解決，這個問題目前仍然存在。

今天，OpenID (openid.net） 的 Web 網站，需要對其使用者進行身份驗證，但不是很好的選擇想要另一個組的憑據與尚未向他們收取。 OpenID 是一個單一登入 (SSO) 協定，您的網站使用連接到一個協力廠商服務提供程式將管理您的身份驗證。 啟用 OpenID 的網站管理只有開頭和結尾的驗證任務。 它將使用者重定向到已配置的 OpenID 提供和獲取標識資訊，回來時一切都發生了。

OpenID 是一個時髦，而另一個甚至更正在討論：OAuth (oauth.net)。 差別是什麼？

OpenID 是專門 SSO 協定。 OpenID 提供程式只管理註冊使用者的身份。 但 Twitter 和 Facebook 等社交網路需要更多。 一個應用程式可能只是想讓使用者通過 Facebook 進行身份驗證。 另一個可能想要通過 Facebook 進行身份驗證，但還發佈到使用者的牆。 然而另一個應用程式可能需要閱讀使用者的時間表和最近的活動。 最主要的有身份驗證 （這可以通過 OpenID 協定管理），但同一使用者可能授予不同的許可權對不同的應用程式。 這是一個方面，OpenID 不設計給處理。

OAuth 是 Twitter 和 Facebook 使用處理身份驗證和授權的協定。 OAuth 供應商不只是返回標識資訊。 它要求使用者的許可權，他想要向應用程式授予和一切、 憑據和成一個訪問權杖的許可權，然後打包。 用戶端應用程式然後將把執行任何允許的操作代表使用者的訪問權杖。 OAuth （和 OpenID，以及） 的好處之一是提供程式永遠不會洩漏到 app 的使用者憑據。 此外，當使用 OAuth 時，最終使用者將可以撤銷許可權到任何應用程式在任何時間。 因此，例如，想像一下有些時候您進行身份驗證與 app XYZ 使用 Twitter （或 Facebook） 和授予 XYZ 的許可權，若要以您的名義發佈。 您可以通過簡單地轉到您的 Twitter （或 Facebook） 設定檔頁面面吊銷此許可權的任何時候。 請注意返回的 OAuth 協定的訪問權杖是特定于應用程式和使用者。 使用者將需要登錄到多個應用程式如果他打算在多個基於 OAuth 的應用程式上操作。 OAuth 是一種基於 HTTP 的使用者進行身份驗證協定。 您通常不必寫入 HTTP 要求手動，即使你可以 （例如，要瞭解的東西"下井蓋"的工作方式）。 在 Microsoft.NET 框架中，您可以使用通用的庫，如 DotNetOpenAuth （dotnetopenauth。 淨） 或撿現成的框架，對於一個特定的社會網路，例如 TweetSharp，Twitter 和 Facebook C# SDK。

當到身份驗證時，看一看 Windows Azure 存取控制服務。 這可以作為聯合的身份提供程式，可以轉換多個識別提供程式映射。 它可以承載 OAuth 和從 Active Directory 基於安全斷言標記語言的權杖。 也是建立與 Facebook 和.NET 框架中的新的 ClaimsPrincipal 類。

通過 Facebook 的使用者進行身份驗證

讓我們與基本 ASP.NET MVC 網站啟動並使用 NuGet 插上 Facebook C# SDK （見圖 2）。 ASP.NET MVC 示例網站與一個全新的身份驗證控制器富含三種方法，我命名為 FacebookLogin、 FacebookAuthenticated 和登出。 前兩種方法表示的兩個步驟的 OAuth 互動 ； 登出方法只是日誌主機應用程式使用者。 請注意，登出行動不應該從 Facebook 使用者登錄。 OAuth 和 Facebook C# SDK 只管理身份驗證邏輯 — — 通過 cookie 保持身份驗證資訊仍是由 ASP.NET MVC 網站。

圖 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>

圖 3 按鈕來觸發 Facebook 身份驗證過程

在標準 ASP.NET MVC 網站中，此標記屬於 _logOnPartial.cshtml 頁。 讓我們看一看，身份驗證控制器。

FacebookLogin 行動中 — — 是任意的名稱 — — 您需要做幾件事情。 第一，你安排的 URL，在一次調用從 OAuth 提供程式，將會導致您的應用程式，以完成該身份驗證步驟。 在我正考慮的應用程式範例中，URL 將指向的 Auth 控制器上的 FacebookAuthenticated 行動。 您可以使用方便的 UriBuilder 類的這種工作：

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

第二件事要做 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 登錄參數

Parameter	說明
client_id	Facebook 的應用程式作為使用者 app 和 Facebook 網站之間的代理 ID。 當您註冊您的 Facebook 應用程式時，您會得到這唯一的字串。
redirect_uri	要返回到完整的身份驗證 URL （例如，攫取的身份資訊和創建身份驗證 cookie）。
response_type	這可以是"象徵性的"或"代碼"，它是指 Facebook 如何返回後成功的身份驗證的訪問權杖。 對於網站來說，它應該是"代碼"，這樣可以確保訪問權杖 — — 一塊敏感的資訊 — — 不追加到 URL。
範圍	指示要為使用者請求的附加許可權。 Scope 參數為空，當應用程式具有存取權限使用者的基本資訊，如名稱、 圖片和性別。 通過此參數，您可以請求的電子郵件地址，以及要能發帖子的發佈流。 完整的許可權清單是可用在 bit.ly/NCcAgf。

要通過 Facebook （或 Twitter） 的使用者進行身份驗證，您需要先註冊一個 Facebook （或 Twitter） 的應用程式和為該函數獲取一些唯一的代碼。 要註冊新的 Facebook 應用程式，請轉到 bit.ly/mRw8BK。 Facebook 後的 app 的成功創建，給你一個應用程式 ID 字串和在中所示的頁面中顯示 app 秘密字串圖 5。

圖 5 註冊新的 Facebook 應用程式

執行從一個 Web 網站或任何其他類型的使用者應用程式內的 Facebook 操作所需的應用程式 ID 和 app 的秘密。 這是常見的包裝應用程式佈建檔中存儲的應用程式 ID 和 app 的秘密：

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

Facebook 登錄 URL 沒有它可以對使用者進行認證。 尤其是，如果使用者當前登錄到 Facebook，請求權杖是編寫並立即送往指定的返回 URL — — 在這種情況下，這是 FacebookAuthenticated 行動。 如果沒有使用者當前登錄這台機器，Facebook 將顯示一個經典的登錄頁。 在這樣做的時候，它還列出了該應用程式正在請求的許可權。 以最小許可權關切的電子郵件地址和顯示名稱。 然而，他們可能包括代表使用者張貼或訪問到的媒體流、 朋友、 時間軸和更多的許可權。 明確請使用者批准或拒絕這些許可權。 完全許可權參考資訊可在 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 和嘗試的用戶端身份驗證，然後得到一個短命的標記，在兩個小時後過期。 您可以通過特定的終結點第二次調用擴展此持續時間為 60 天。 在任何情況下，一旦訪問權杖已過期，使用者需要再次進行身份驗證並重新獲取有效的訪問權杖。 這裡是編碼的一個好方法：

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

整個故事是次在 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 或持久性存儲區的訪問權杖字串必須從您在何處保存它，檢索。 如果您丟失的訪問權杖，然後開機自檢操作成功的使用者需要登出並重新登錄。 如果你打算執行任務針對 Facebook，生存瀏覽器重新開機的方式存儲的訪問權杖是關鍵。 圖 7 顯示了應用程式範例發送一條消息，並正確地更新該使用者的牆的。

張貼在牆上的圖 7

下一步的打算：Windows Presentation Foundation

概括地說，Facebook 公開了相當豐富的 API，通過該開發人員可以將集成 Facebook 的內容和邏輯與他們自己的應用程式。 Facebook app 是 Facebook 的邊界內生活的當然嵌入應用程式，但是他們也是經典的 Web 或桌面應用程式外部生活。 在本專欄中我用 Facebook C# SDK 來執行兩個簡單但很常見操作：使用她的 Facebook 帳戶和使用網站的頁面發送到當前使用者的隔離牆將 Web 網站的使用者進行身份驗證。 在下一列中，我展開的 Facebook 使用的 Api 集，然後討論如何實現從 Windows 的演示文稿基礎應用程式內的相同操作。

Dino Esposito   "構建移動解決方案的企業"（微軟出版社，2012年） 的作者是和"程式設計 ASP.NET MVC 3"（微軟出版社，2011年） 和合著者的"Microsoft.NET：構建企業應用程式"（微軟出版社，2008年）。 埃斯波西托在義大利的基礎，是經常在世界各地的行業活動中發表演講。 跟隨他在 Twitter 上 twitter.com/despos。

由於以下的技術專家對本文的審閱： 斯科特 · 登斯莫爾