Este artigo foi traduzido por máquina.

Cutting Edge

Programação essencial para o Facebook: Autenticação e atualizações

Dino Esposito

Baixar o código de exemplo

Facebook é uma plataforma de software rico e complexo, que apresenta um quadro de desenvolvimento de sofisticados e multifacetados devel­desenvolvedores. Em primeiro lugar, o significado de "Programação de Facebook" pode não ser claro. Existem basicamente dois tipos de aplicativos relacionados ao Facebook. Um tipo é composto por aplicativos que vivem e prosperam no ambiente do Facebook. Esses aplicativos são essencialmente ricas páginas carregadas no Facebook páginas de lona e hospedado no site principal. Para usar o app, os usuários precisam navegar até o site do Facebook e entrar na sua própria conta. Esses aplicativos podem implementar sua própria lógica —­tudo o que você pode expressar de dentro de uma página da Web usando JavaScript ou outras tecnologias de programação Web — e pode ter acesso ao Facebook guloseimas como amigos, feeds de notícias, mídia e muito mais. Para começar sobre esta forma de programação, basta ir para a página de "Apps em Facebook.com" em bit.ly/f5hERV.

Outra abordagem para Facebook programação envolve integrar algumas funcionalidades do Facebook de núcleo em aplicativos existentes, tais como Web sites, aplicativos móveis (por exemplo, Android, iOS ou Windows Phone) ou aplicações desktop.

Neste artigo vou focar este aspecto da programação do Facebook e discutir como usar a API do Facebook C# para autenticar usuários e postar, programaticamente, em nome do usuário conectado no momento.

Incorporar o botão Like

Quando se trata de redes sociais populares como o Facebook e o Twitter, o primeiro nível de integração com aplicativos externos é através do uso de botões ad hoc a "gostar" da página ou tweet sobre ele. Quase nenhuma programação é necessário; é puramente uma questão de inserir alguma marcação ad hoc em páginas da Web.

Assim é a maneira mais simples para tornar seu site mais popular para incorporar o botão Like do Facebook em um iframe de novo para que qualquer usuário visitar a página pode imediatamente como ele no Facebook. Aqui é a marcação mínima que você precisa:

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

Você substituir o XXX com a URL da página a gostar. Além disso, você pode querer adicionar um pouco de estilo CSS para o elemento iframe para torná-lo melhor fundir-se com o resto da página. A Figura 1 mostra o resultado final.

Figura 1 o botão Like do Facebook

O botão Like é o mais simples e mais popular do Facebook social plug-ins. Na maioria das vezes, você pode integrar plug-ins em páginas da Web através de quadros ou marcação ad hoc. Alguns plug-ins exigem o Facebook JavaScript SDK, e alguns só funcionam se você tiver personalizadas páginas de Facebook. Falarei sobre Facebook script em uma coluna futura.

Além da utilização de plug-ins sociais, integrando meios Facebook Apps (e não apenas sites da Web), sendo capaz de executar duas tarefas principais: permitir que os usuários se autenticar com seu aplicativo usando sua conta do Facebook e habilitar o app afixar nas paredes de Facebook de determinados usuários. Vamos começar com a autenticação do usuário.

OAuth e o velho sonho de um único módulo de autenticação

Autenticação de usuário é uma função de núcleo de praticamente qualquer site significativa. Uma década atrás, um dos pontos mais vendidos do ASP.NET em comparação com o ASP clássico foi a disponibilidade de um sistema de associação altamente reutilizável que facilitou o desenvolvimento de uma camada de autenticação em uma fração do tempo normalmente necessário.

Nos dias de hoje, no entanto, com uma camada de autenticação personalizado é uma opção atraente. Ao implementar uma camada de autenticação ad hoc, desenvolvedores fazem-se responsável por armazenar com segurança as senhas e os custos do gerenciamento de milhares de contas, ou mais. Para os usuários, isso significa que mais um par de nome de usuário/senha lembrar.

Anos atrás, a iniciativa da Microsoft Passport foi uma tentativa inteligente mas provavelmente muito cedo para facilitar a vida dos usuários quando eles se mudaram em alguns sites relacionados. A idéia por trás do passaporte foi que os usuários só precisava de um único logon bem-sucedido para navegar livremente por todos os sites associados.

Junto com versões anteriores do ASP.NET, a API de passaporte é agora oficialmente ido. O problema que ele foi concebido para resolver, no entanto, ainda está presente.

Hoje, OpenID (openid.net) é uma ótima opção para sites que precisam autenticar seus usuários, mas quero acusá-los de ainda outro conjunto de credenciais. OpenID é um single sign-on (SSO) protocolo que seu site usa para se conectar a um provedor de serviços de terceiros que irá gerenciar a autenticação para você. Um site habilitado para OpenID gerencia apenas o início e o fim da tarefa de autenticação. Ele redireciona o usuário para o provedor de OpenID configurado e obtém informações de identidade quando tudo aconteceu.

Enquanto o OpenID é um chavão popular, outro está sendo discutido ainda mais: OAuth (oauth.net). Qual é a diferença?

OpenID é exclusivamente um protocolo SSO. Um provedor de OpenID, apenas gerencia as identidades de usuários cadastrados. Mas precisam de redes sociais como Twitter e Facebook mais. Um app pode simplesmente querer permitir que os usuários autenticar via Facebook. Outro pode querer autenticar via Facebook, mas também colocar a parede do usuário. Ainda um outro app pode querer ler a linha de tempo do usuário e atividade recente. Em cima de tudo, não há autenticação (que pode ser gerenciada através do protocolo OpenID), mas o mesmo usuário pode conceder permissões diferentes para diferentes aplicações. E este é um aspecto que OpenID não foi projetado para manipular.

OAuth é um protocolo que Twitter e Facebook usam para lidar com a autenticação e autorização. Um provedor de OAuth simplesmente não retorna informações de identidade. Ele pede o usuário permissões que ele deseja conceder ao aplicativo e, em seguida, empacota tudo, credenciais e permissões, em um token de acesso. O aplicativo cliente passará, em seguida, o token de acesso para executar qualquer operação permitida em nome do usuário. Uma das vantagens do OAuth (e OpenID, também) é que o provedor nunca divulga as credenciais do usuário para o aplicativo. Além disso, quando é usado o OAuth, o usuário final pode revogar permissões para qualquer aplicativo a qualquer momento. Assim, por exemplo, imagine que em algum momento você autentica com app XYZ usando o Twitter (ou Facebook) e conceder permissão de XYZ para publicar em seu nome. Você pode revogar essa permissão a qualquer momento, basta ir à sua página de perfil do Twitter (ou Facebook). Observe que o token de acesso retornado pelo protocolo OAuth é específico do aplicativo e do usuário. O usuário precisará fazer logon várias apps se pretende operar em vários aplicativos baseados em OAuth. O OAuth é um protocolo baseado em HTTP para autenticar usuários. Você muitas vezes não tem que escrever solicitações HTTP manualmente, mesmo que você poderia (por exemplo, para aprender como as coisas funcionam "nos bastidores"). No Microsoft .NET Framework, você pode usar bibliotecas de uso gerais como DotNetOpenAuth (dotnetopenauth. NET) ou pegar estruturas prontas para uma rede social específica como TweetSharp para o Twitter e o Facebook C# SDK para Facebook.

Quando se trata de autenticação, dê uma olhada no serviço de controle de acesso do Windows Azure. Isso pode atuar como um provedor de identidade federada e pode traduzir vários mapeamentos de provedor de identidade. Ele pode hospedar OAuth e tokens baseados em Security Assertion Markup Language do Active Directory. Também é construído para trabalhar com o Facebook e a nova classe ClaimsPrincipal no .NET Framework.

Autenticação de usuários via Facebook

Vamos começar com um site ASP.NET MVC básico e usar o NuGet para ligar no Facebook C# SDK (ver Figura 2). O site de exemplo de ASP.NET MVC é enriquecido com um controlador de autenticação novinho em folha com três métodos, que chamei de FacebookLogin, FacebookAuthenticated e Logoff. Os dois primeiros métodos representam as duas etapas de uma interação de OAuth; o método de Logoff apenas registra o usuário fora do aplicativo host. Note-se que a ação de Logoff não é suposto fazer logon o usuário fora do Facebook. OAuth e o SDK C# Facebook apenas gerenciar a lógica de autenticação — informações de autenticação persistentes através de cookies são ainda até o site do ASP.NET MVC.

Figura 2 referenciando o Facebook c# SDK via NuGet

Página inicial do site fornece um link para o usuário clicar quando ela quer entrar (ver Figura 3). O link pode ser simplesmente uma âncora para uma imagem (ou texto) que aponta para a ação de FacebookLogin no controlador de autenticação:

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

Figura 3 o botão para disparar o processo de autenticação do Facebook

Em um site padrão do ASP.NET MVC, essa marcação pertence à página _logOnPartial.cshtml. Vamos ter um olhar para o controlador de autenticação.

Na ação FacebookLogin — o nome é arbitrário — você precisa fazer algumas coisas. Primeiro, você arranjar o URL que, uma vez chamado do provedor de OAuth, fará com que seu aplicativo para completar a etapa de autenticação. No aplicativo de exemplo que estou pensando, a URL apontará para a ação de FacebookAuthenticated no controlador Auth. Você pode usar a classe UriBuilder útil para este tipo de trabalho:

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

A segunda coisa a fazer na FacebookLogin ação é organizar a URL do Facebook para login. Se você usa o Facebook C# SDK, aqui está o código que você precisa:

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"
  });

Os parâmetros que você passa para o método de GetLoginUrl ajudam a preparar o URL. Figura 4 descreve os parâmetros mais detalhadamente. A ação termina de FacebookLogin, redirecionando o usuário para a URL de login retornado.

Parâmetros de logon de Figura 4

Para autenticar um usuário via Facebook (ou Twitter), você precisa registrar um app de Facebook (ou Twitter) primeiro e obter alguns códigos únicos para essa função. Para registar um novo app de Facebook, vá a bit.ly/mRw8BK. Após a criação bem-sucedida do app, Facebook dá-lhe uma sequência de identificação da app e uma cadeia de caracteres secreta app exibido na página mostrada na Figura 5.

Figura 5, registrando um novo App de Facebook

O ID de aplicativo e o segredo de app são necessário para executar operações do Facebook de dentro de um Web site ou qualquer outro tipo de aplicativo de usuário. É comum para armazenar o ID de aplicativo e o segredo do app no arquivo de configuração do aplicativo wrapper:

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

A URL de login do Facebook faz o possível para autenticar o usuário. Em particular, se o usuário está atualmente conectado ao Facebook, uma ficha de pedido é preparada e enviada imediatamente para a URL de retorno especificada — nesse caso, essa é a ação de FacebookAuthenticated. Se nenhum usuário está logado na máquina, o Facebook exibe uma página de logon clássico. Ao fazê-lo, ele também lista as permissões que o aplicativo está solicitando. No mínimo, permissões dizem respeito a endereços de e-mail e nome para exibição. No entanto, eles podem incluir permissão para postar em nome do usuário ou o acesso a transmitir de mídia, amigos, linha do tempo e muito mais. O usuário é solicitado expressamente para aprovar ou negar essas permissões. Informações de referência de permissões completas podem ser encontradas em bit.ly/P86tTC.

Finalizando o processo de autenticação

Para finalizar a autenticação, é necessário solicitar e analisar o token de acesso, como mostrado em Figura 6. O método ParseOAuth­CallbackUrl permite que você recuperar o código de acesso do Facebook. Esse código não é suficiente para controlar a conta do Facebook; você precisará trocá-lo por um token de acesso. De acordo com o protocolo OAuth, isso requer um passo e outro pedido HTTP. Uma vez que seu site possui o token de acesso para um determinado usuário e um determinado aplicativo do Facebook, ganha controle da conta do Facebook para as permissões o usuário explicitamente concedido. No mínimo, você tem permissão para recuperar informações sobre o usuário, como nome e sobrenome e, se permitido, endereço de email.

Figura 6 finalizando a autenticação

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 ?? "
/");
}

Se o seu único objectivo é autenticação de usuários através do Facebook, você cria o cookie de autenticação do ASP.NET padrão e pronto. Se seu aplicativo deseja fazer mais (por exemplo, postar em nome do usuário), então você precisa para armazenar o token de acesso que pode ser dado o mesmo tempo de vida como o cookie de autenticação. Você pode salvar o token de acesso a um banco de dados ou em um cookie. Melhor ainda, você pode criar uma entidade personalizada e armazenar o token de acesso como usuário extra dados do cookie de autenticação do ASP.NET. No meu aplicativo de amostra, estou apenas criando um cookie adicional que é gerenciado pela classe FbHelpers (Veja o código-fonte que acompanha para detalhes).

Note, porém, que o token de acesso está sujeito a algumas regras de expiração. Se você autenticar usando o código do lado do servidor (ou seja, enviar a autenticação de usuários com o site do Facebook, como discutido aqui), então você tem um símbolo de vida longa que dura 60 dias. Se você usa o SDK de JavaScript e tente uma autenticação de cliente, então você obter um token de curta duração que expira depois de duas horas. Você pode estender esta duração 60 dias fazendo uma segunda chamada para um ponto de extremidade específico. Em qualquer caso, uma vez que o token de acesso está expirado, os usuários precisam autenticar novamente e readquirir um token de acesso válido. Aqui está uma boa maneira de codificação que:

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

Toda a história é well-summarized em bit.ly/Qfeh5s.

Postando para parede em um usuário

Em um cenário de OAuth, quando você prende o token de acesso para um par usuário/aplicativo, você pode programaticamente executar qualquer das operações interativas para que o usuário permissões para o aplicativo. Para postar uma mensagem a parede do usuário, você precisa o seguinte código:

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

Você chamar esse método auxiliar de dentro de um método de ação do controlador. A sequência de token de acesso deve ser obtida onde quer que você o salvou, se um cookie personalizado, o cookie de autenticação ou um armazenamento persistente. Se você perdeu o token de acesso, então ser bem sucedida a operação post o usuário precisa efetuar logout e login novamente. Se você pretende executar tarefas contra Facebook, armazenar o token de acesso de uma forma que sobrevive a reinicialização do navegador é a chave. Figura 7 mostra o aplicativo de exemplo que envia uma mensagem e a parede do usuário devidamente atualizado.

Figura 7 postando na parede

A seguir: Windows Presentation Foundation

Para resumir, Facebook expõe uma API bastante rico através do qual os desenvolvedores podem integrar Facebook conteúdo e lógica com seus próprios aplicativos. Facebook apps são certamente incorporados apps vivem dentro dos limites do Facebook, mas eles também clássico Web ou aplicações desktop vivem externamente. Nesta coluna, eu usei o Facebook C# SDK para executar duas operações simples, mas bastante comuns: autenticar um usuário de um Web site usando sua conta do Facebook e usando as páginas do site para postar a parede do usuário atual. Na próxima coluna, vou expandir o conjunto de APIs usadas do Facebook e discutir como alcançar as mesmas operações de dentro de um aplicativo Windows Presentation Foundation.

Dino Esposito  é autor de "Arquitetura móvel soluções para a empresa" (Microsoft Press, 2012) e "programação ASP.NET MVC 3" (Microsoft Press, 2011) e co-autor do livro "Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2008). Residente na Itália, Esposito é um palestrante sempre presente em eventos do setor no mundo inteiro. Siga ele no Twitter em Twitter.com /despos..

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Scott Densmore