Segurança

  • Artigo

Serviços de Acesso Online com o Tempo de Execução do Windows e OAuth

Tim Kulp

Baixar o código de exemplo

Era uma vez, na época da Web 1.0, em que os sites eram silos de conteúdo a serem lidos, e nada mais. Depois que a Web 2.0 entrou nas oficinas de desenvolvimento, os sites se tornaram serviços online com APIs usadas pelos desenvolvedores para combinar e compatibilizar componentes, dados e funcionalidade. Agora, os mashups permitem que os desenvolvedores acessem bibliotecas ricas em conteúdo sem a sobrecarga de hospedar os dados nas suas salas de servidores.

Com o WinRT (Tempo de Execução do Windows), você pode trazer o poder dos mashups para seu próximo aplicativo da Windows Store. Esteja você gerenciando os dados com XHR (XmlHttpRequest) ou autenticando-se em um serviço remoto com a classe WebAuthenticationBroker, a WinJS (Biblioteca do Windows para JavaScript) e o Tempo de Execução do Windows facilitam a combinação de serviços online com seu aplicativo.

Contoso Photo Finish

Neste artigo, vou criar um mashup chamado Contoso Photo Finish. Ele permite que corredores acompanhem suas milhas e postem uma foto de suas corridas. Muitos corredores gostam de compartilhar informações, como distância e local de suas corridas, em redes sociais. O Contoso Photo Finish permite que os usuários contem a seus amigos sobre suas corridas com comentários e fotos no Facebook. Esse aplicativo se conectará a dois serviços diferentes:

  • Windows SkyDrive para recuperar uma foto do corredor
  • Facebook para postar a imagem para que os amigos vejam

O Contoso Photo Finish combinará esses serviços para fornecer uma experiência conectada ao usuário. Este artigo supõe que você tenha o Visual Studio 2012 aberto com o JavaScript | Windows Store | modelo Aplicativo em Branco pronto para você iniciar a criação de códigos.

Dificuldades do mashup: autorização e autenticação

Se um aplicativo (Web ou Windows Store) desejar postar conteúdo no Facebook, o primeiro obstáculo a ser superado é a autenticação. O Facebook precisa saber quem está se conectando a ele. Quando os usuários tentam fazer logon nos aplicativos, eles reivindicam uma identidade (geralmente na forma de um nome de usuário) e uma credencial (como senha, token de segurança, dispositivo biométrico, etc.) para provar que eles têm acesso à identidade solicitada. A autenticação é o processo de validar a identidade de um usuário por meio de uma credencial.

Após a autenticação do usuário, o mashup tem outro desafio: determinar o que o usuário pode fazer no sistema. A autorização é o processo de permitir ou negar ações que uma identidade está tentando executar com base em algum atributo ou associação de função de segurança. Por exemplo, no Twitter minha identidade não tem permissão para excluir todos os tweets de todos os usuários. Não estou autorizado a executar essa ação porque não sou um membro da função de segurança com permissão para isso. Juntas, A&A (autenticação e autorização) representam a pergunta: Usuário, quem é você e o que você pode fazer?

Os mashups ampliam esses desafios porque o desenvolvedor que está criando o mashup não tem acesso ao local em que as identidades, credenciais e funções de segurança estão armazenadas (muitas vezes conhecido como um repositório de credenciais). Desse modo, se não posso verificar quem é quem e o que eles podem fazer, como posso criar um mashup para aplicativos como o Facebook? O OAuth é a salvação!

OAuth: acessando recursos, não aplicativos

O OAuth soluciona o desafio de A&A para mashups. Imagine que o Aplicativo X deseja acessar conteúdo do Serviço Online Y. Em vez de o usuário se autenticar no Aplicativo X, ele se autentica no Serviço Online Y porque as credenciais do usuário são armazenadas no repositório de credenciais do Serviço Online Y. O usuário então permite que o Aplicativo X acesse recursos especificados do Serviço Online Y por um tempo limitado. A permissão para acessar recursos do Serviço Online Y é retornada ao Aplicativo X como um token de acesso (às vezes, conhecido apenas como um "token").

Nos modelos tradicionais de A&A da Web, dois participantes trabalham juntos para determinar o acesso de um usuário: o aplicativo e o usuário (ou o servidor e o cliente). No OAuth, um terceiro participante é introduzido: o servidor de recursos. Os servidores de recursos são os terceiros que têm um recurso (como uma foto) armazenado no servidor que um cliente precisa acessar. No Contoso Photo Finish, o Facebook é um servidor de recursos. O recurso que o Contoso Photo Finish deseja acessar é o status do usuário para postar uma mensagem.

Os clientes do OAuth e seus processos de autenticação

Há dois tipos de clientes no OAuth; e qual tipo usar é decidido pelo nível de confiança do cliente. Os clientes confidenciais podem manter suas credenciais protegidas e destinadas a ambientes altamente confiáveis. Os exemplos de clientes confidenciais são aplicativos Web do servidor onde o segredo do cliente pode ser mantido em um ambiente seguro e controlado. Os clientes confidenciais usam o processo Código de Autorização para obter um token de segurança fornecendo o segredo do cliente ao servidor de recursos como um meio de autenticar o cliente.

Os clientes públicos não podem manter suas credenciais protegidas porque eles são executados em um ambiente hostil. Um exemplo de clientes públicos são os aplicativos agente do usuário (isto é, aplicativos Web JavaScript) ou aplicativos nativos (como aplicativos da Windows Store). Os clientes públicos usam o processo "concessão implícita" para obter um token de segurança, pois o segredo do cliente não pode ser armazenado de maneira segura em um ambiente hostil que está fora do controle do desenvolvedor.

Os aplicativos da Windows Store podem ser configurados para usar o processo de concessão implícita ou código de autorização para o OAuth (você pode ler mais sobre processos de concessão implícita e código de autorização em bit.ly/yQjyQZ). É uma prática recomendada de segurança usar a concessão implícita sempre que um aplicativo estiver fora do controle do desenvolvedor.

Na Figura 1, examino um processo de concessão implícita onde o cliente inicia a conversa tentando determinar a identidade de um usuário com o servidor de recursos.


Figura 1 Conversa de concessão implícita de um aplicativo da Windows Store

As etapas ilustradas na Figura 1 são explicadas aqui:

  1. O aplicativo da Windows Store precisa executar alguma funcionalidade que exige acesso à API do Facebook.
  2. O usuário se conecta ao servidor de recursos por meio de um URI que inclui informações sobre o aplicativo da Windows Store que está tentando acessar a API do Facebook. Geralmente, isso está na forma de uma ID de aplicativo ou de um código de ID. O usuário fornece um nome de usuário e uma senha para fazer logon no Facebook.
  3. Supondo o logon bem-sucedido, o Facebook fornece ao aplicativo da Windows Store um token de acesso.
  4. O aplicativo da Windows Store agora pode fornecer ao usuário dados da API do Facebook usando o token de acesso fornecido pelo Facebook para obter o feed do usuário, postar imagens, etc.

Fazer essa conversa acontecer é surpreendentemente fácil por meio do novo namespace Windows.Security.Authentication.Web.

WebAuthenticationBroker

Nos aplicativos da Windows Store, a classe WebAuthenticationBroker (bit.ly/RW8czT) é o componente que vai se comunicar com o servidor de recursos, fornecer os controles de logon e responder a um logon bem-sucedido, tudo sem precisar que o aplicativo da Windows Store saiba nada sobre as credenciais do usuário. Para o aplicativo de exemplo, o Contoso Photo Finish precisa postar imagens no Facebook. Isso exige que o usuário se autentique no Facebook e receba um token de acesso.

Adicione um novo controle de página ao projeto Contoso Photo Finish chamado input.html. Por padrão, o Visual Studio fornece muitas marcações para você. Substitua "<p>Content goes here.</p>" na seção Conteúdo principal pelo seguinte botão:

 

<input type="button" id="btnAddRun" value="Add Run" />

Esse é o botão em que o usuário clicará para adicionar uma execução ao Photo Finish. Agora abra input.js e adicione a seguinte função:

function btnAddRun_Click(e) {   var facebookOauthUrl = "https://www.facebook.com/dialog/oauth";   var facebookClientId = "[YOUR CLIENT ID]";   var redirectUrl = "https://www.facebook.com/connect/login_success.html";   var requestUri = Windows.Foundation.Uri(facebookOauthUrl +     "?client_id=" + facebookClientId +     "&redirect_uri=" + encodeURIComponent(redirectUrl) +     "&response_type=" +     "token&scope=read_stream,publish_actions&display=popup");   var callbackUri = Windows.Foundation.Uri(redirectUrl);   // Web authentication broker will go here }

Esse código estabelece as variáveis que serão usadas na solicitação de autenticação. A primeira variável é a URL do serviço OAuth do Facebook. A ID do Cliente é o identificador de aplicativo usado pelo Facebook para identificar o Contoso Photo Finish como o aplicativo com o qual a API do Facebook interagirá. Um identificador como esse geralmente é atribuído a um aplicativo quando ele é registrado com o servidor de recursos. Alguns servidores de recursos referem-se à identificadores como id do cliente, id do aplicativo ou apenas id. Qual id usar será encontrada na documentação da API do servidor de recursos.

O parâmetro redirectUrl determina para onde o aplicativo irá depois que o usuário se autentica e aprova o acesso do aplicativo para recursos especificados. Nesse caso, redirectUrl é definido como um padrão do Facebook que está disponível para todos os aplicativos de API do Facebook. Alguns serviços exigem que o URI do aplicativo da Windows Store seja identificado com o servidor de recursos quando o aplicativo é registrado. O URI do aplicativo pode ser encontrado usando o método getCurrentApplicationCallbackUri do agente de autenticação da Web. Isso retornará o URI do contexto local do aplicativo (começando com "ms-app://"). Alguns servidores de recursos não oferecem suporte a ms-app:// como um protocolo válido para um redirectUrl, caso em que você deve buscar um endereço de redirecionamento padrão como o fornecido pelo Facebook.

Em seguida, o callbackUri é definido. Esse é o endereço que informa o agente de autenticação da Web quando a autenticação é concluída e retorna o controle de volta ao aplicativo da Windows Store. O agente nunca acessa de fato essa URL, ele simplesmente observa o servidor de recursos para chamar por essa página e retornar o callbackUri com alguma cadeia de caracteres de consulta ou parâmetros hash que foram acrescentados. Nesse caso, o parâmetro hash "access_token" fornecerá ao Contoso Photo Finish o token necessário para interagir com a API.

A classe WebAuthenticationBroker usa o método authenticateAsync para se conectar ao processo de autenticação, e concluí-lo, com o servidor de recursos. Quando authenticateAsync é chamado, o aplicativo abre um pop-up que exibe a tela de logon do servidor de recursos, conforme mostrado na Figura 2. Assim que a autenticação for concluída ou o callbackUri for encontrado, o pop-up será fechado.


Figura 2 Pop-up de logon do servidor de recursos de authenticateAsync

A principal vantagem de usar esse pop-up é que o aplicativo da Windows Store nunca identifica nem precisa conhecer as credenciais do usuário para o gerenciador de recursos. Tudo o que o aplicativo sabe é o token de acesso retornado pelo servidor de recursos. Essa separação mantém as credenciais do servidor de recursos isoladas do aplicativo, o que evita o risco à segurança do aplicativo que está armazenando as credenciais. Além dos benefícios de segurança, o desenvolvedor não precisa codificar nada para obter essa interface; ela é integrada ao método authenticateAsync. Quando os desenvolvedores chamam o método, a interface vem com ele.

Agora, voltemos ao código. Substitua o comentário "Web authentication broker will go here" pelo seguinte código:

 

Windows.Security.Authentication.Web.WebAuthenticationBroker.   authenticateAsync(Windows.Security.Authentication.Web.   WebAuthenticationOptions.none, requestUri, callbackUri) .done(   function (result) {     // Check the response status here                    },   function (ex) {     Log(ex);   } );

O método authenticateAsync usa três parâmetros (o terceiro é opcional):

  1. WebAuthenticationOptions: usado para fornecer instruções ao agente de autenticação da Web sobre como renderizar a caixa de diálogo de autenticação ou quais dados retornar na resposta. No exemplo anterior, o aplicativo usa "nenhum" para mostrar uma implementação comum que não passa nenhuma opção ao agente usando uma configuração padrão.
  2. requestUri: esse é o ponto de entrada de logon para o servidor de recursos. Nesse caso, Contoso Photo Finish está se conectando ao serviço OAuth do Facebook. RequestUri deve estar sobre uma conexão protegida usando o protocolo HTTPS.
  3. callbackUri: essa é a página que, quando navegada, retorna o controle de volta ao agente de autenticação da Web, conforme descrito anteriormente. Esse argumento é opcional, mas se o servidor de recursos não puder (ou não quiser) redirecionar para ms-app://, esse parâmetro será como o aplicativo escapará do controle do servidor de recursos. Por exemplo, no código anterior, quando a navegação é feita em https://www.facebook.com/connect/login\_success.html após um logon bem-sucedido, o agente de autenticação da Web tomará o controle do aplicativo do servidor de recursos fechando a caixa de diálogo de autenticação e processando o sucesso da promessa. CallbackUri não precisa estar na próxima página seguinte; ele pode estar após um assistente ou algum outro processo que deve ocorrer no site do servidor de recursos. Geralmente, esse URI será o mesmo que o redirectUrl, mas fornece a flexibilidade para estender o processo de autenticação, se necessário.

Se o agente de autenticação da Web se conectar ao servidor de recursos, a promessa foi bem-sucedida. A detecção do resultado do processo de autenticação é feita por meio da propriedade ResponseStatus do objeto WebAuthenticationResult. No código anterior, o argumento do resultado é um objeto WebAuthenticationResult com três propriedades: Response Data (dados do servidor de recursos), ResponseErrorDetail (se algo der errado, o que foi?) e ResponseStatus (qual é o status da autenticação?). Substitua o comentário "Check the response status here" pelo código mostrado na Figura 3.

Figura 3 Trabalhando com o resultado do processo de autenticação

 

switch (result.responseStatus) {   case Windows.Security.Authentication.Web.WebAuthenticationStatus.success:     var fragment = Windows.Foundation.Uri(result.responseData).fragment;     if (fragment.indexOf("#access_token=") != -1) {       var token = fragment.substring(         new String("#access_token=").length,         fragment.indexOf("&expires_in="));       // Add API calls here     }     break;   case Windows.Security.Authentication.Web.WebAuthenticationStatus.userCancel:     Log(window.toStaticHTML(result.responseData));     Display("User cancelled the authentication to Facebook.");     break;   case Windows.Security.Authentication.Web.WebAuthenticationStatus.errorHttp:     Log(window.toStaticHTML(result.responseData));     Display("An error occurred while communicating with Facebook.");     break; }

No código da Figura 3, cada status é verificado, com o método Log gravando as informações do servidor de recursos e o método Display informando o usuário o que ocorreu. Para mensagens de erro, lembre-se de exibir mensagens amigáveis ao usuário para melhorar a usabilidade e reduzir a exposição acidental das informações confidenciais de uma mensagem de erro gerada pelo sistema. Se a autenticação for bem-sucedida, o fragmento do URI retornado do Facebook será analisado e armazenado na variável do token para ser usado na chamada de API (consulte a seção "Obtendo e postando informações via XHR" para obter detalhes de implementação).                

Com a função btnAddRun_Click concluída, conecte-a ao objeto btnAddRun na função WinJS.UI.Pages.define { ready }:

var btnAddRun = document.getElementById("btnAddRun"); if (null != btnAddRun)   btnAddRun.addEventListener("click", btnAddRun_Click, false);

Nesse ponto, o aplicativo tem um token de acesso mostrando que o usuário foi autenticado no servidor de recursos. Na última seção, o aplicativo executará comandos de API para enviar dados, mas primeiro o aplicativo precisa de algo para enviar ao Facebook.

Criando a imagem

O Windows 8 fornece vários contratos que permitem aos aplicativos conversar entre si, como pesquisa, compartilhamento e seletor de arquivos. Esses contratos podem tornar qualquer aplicativo em um mashup com apenas algumas linhas de código. O Contoso Photo Finish vai aproveitar o poder do contrato do seletor de arquivos para encontrar uma imagem para a execução do usuário.

Uma das muitas coisas que amo no meu Windows Phone é a integração com o SkyDrive. Posso carregar minhas fotos instantaneamente para armazenamento na nuvem, de modo que na próxima vez que meu telefone quebrar (o que é frequente), minhas imagens estarão esperando por mim online. O aplicativo SkyDrive para Windows 8 fornece dados no seletor de arquivos, marcando a seleção de arquivos na minha conta do SkyDrive, tão simples quanto selecioná-los na biblioteca de imagens. A próxima parte do mashup Contoso Photo Finish consumirá dados do aplicativo SkyDrive por meio do seletor de arquivos. Para fazer isso, input.html precisa de algumas. . . entradas.

Substitua o botão btnAddRun pelo código mostrado na Figura 4. Esse código inclui os campos de entrada para o usuário fornecer conteúdo para Contoso Photo Finish. O botão btnSelectPhoto usará o seletor de arquivos para selecionar qual arquivo do sistema usar. Adicione uma nova função para input.js que será o manipulador de cliques para btnSelectPhoto:

function btnSelectPhoto_Click(e) {   var imgSelectedPhoto = document.getElementById("imgSelectedPhoto");   var filePicker = new Windows.Storage.Pickers.FileOpenPicker();   filePicker.fileTypeFilter.replaceAll([".jpg", ".jpeg", ".png"]);   filePicker.suggestedStartLocation =     Windows.Storage.Pickers.PickerLocationId.picturesLibrary;   filePicker.viewMode = Windows.Storage.Pickers.PickerViewMode.thumbnail;   // Pick file here }

Figura 4 Campos de entrada para fornecer conteúdo para o aplicativo

<p>   <label>Distance</label>   <input type="number" min="0" max="15" id="txtDistance"     required /> miles </p> <p>   <label>Comment</label>   <input type="text" min="0" max="15" id="txtComment" /> </p> <p>   <label>Photo</label>   <input id="btnSelectPhoto" value="Select Photo" type="button" />   <img src="" id="imgSelectedPhoto" alt="Selected Photo" /> </p> <p>   <input type="button" id="btnAddRun" value="Add Run" /> </p>

A função começa configurando a variável imgSelectedPhoto, que será usada para exibir a foto selecionada ao usuário. Em seguida, o código cria um objeto seletor de arquivos. O objeto seletor de arquivos permite que Contoso Photo Finish escolha arquivos ou pastas (nesse caso, apenas arquivos) no sistema ou em outros aplicativos que participam do contrato do seletor de arquivos para abrir e interagir com eles no aplicativo. Ao usar o filtro de tipo de arquivo, o código limita quais extensões de arquivo podem ser acessadas pelo seletor de arquivos. O aplicativo pode apenas carregar imagens no Facebook (por design), de modo que limitar o seletor de arquivos a trabalhar apenas com tipos de arquivo de imagens especificados impede que o usuário selecione arquivos que tenham extensões inválidas que não atendam à funcionalidade desejada. Além disso, devido ao foco do aplicativo em imagens, o local inicial do seletor de arquivos é definido para a biblioteca de imagens. O local pode ser uma variedade de locais padrão (como biblioteca de músicas, biblioteca de documentos, grupo doméstico, etc.), mas ao lidar com imagens, a biblioteca de imagens é um ponto inicial de senso comum. A última configuração para o seletor de arquivos é definir o viewMode para miniatura. Isso exibe uma visualização do arquivo e é ideal para a seleção de imagem.

Com as opções definidas, é hora de selecionar o arquivo a ser usado para a execução. Em primeiro lugar, adicione essas duas declarações de variável diretamente abaixo da instrução "use strict".

var selectedPhotoStream = null; var selectedPhotoFile = null;

Isso manterá o arquivo e os valores de fluxo para a função btnAddRun_Click quando os dados forem carregados no Facebook. Agora substitua o comentário "Pick file here" pelo código mostrado na Figura 5.

Figura 5 Selecionando um arquivo

filePicker.pickSingleFileAsync().then(   function (storageFile) {     if (storageFile) {       selectedPhotoFile = storageFile;       selectedPhotoFile.openAsync(         Windows.Storage.FileAccessMode.read).then(         function (stream) {           selectedPhotoStream = stream;         document.getElementById("imgSelectedPhoto").src =           URL.createObjectURL(selectedPhotoFile);       },       function (ex) {         Log(ex);         Display("An error has occurred while reading the file.");       });         }     else {       Display("File was not selected");     }   });

A Figura 5 parece um monte de código, mas ela se reduz a três ações:

  1. Selecione o arquivo que o aplicativo estará usando por meio do seletor de arquivos (pickSingleFileAsync).
  2. Abra o fluxo de arquivo a ser lido (openAsync).
  3. Armazene o fluxo e o arquivo em variáveis para uso posterior.

Todos os códigos são padrão para trabalhar com arquivos e fluxos, com apenas uma exceção: URL.createObjectURL usa um objeto e cria uma URL para o objeto a ser exibido por meio de um objeto de imagem. O método createObjectURL trabalha com muitos tipos de objeto, incluindo Stream, StorageItem e MediaCapture. Em geral, ele é usado para exibir conteúdo de mídia (imagem, áudio ou vídeo) em uma aplicativo da Windows Store. Ao usar o createObjectURL, você deve se lembrar de que quando tiver acabado de usar a URL, é preciso descartá-la por meio do método URL.revokeObjectURL. Isso garantirá excelente uso de memória e impedirá que o aplicativo da Windows Store fique lotado com muitas URLs temporárias. Para obter mais informações sobre createObjectURL, verifique a documentação do MSDN em bit.ly/XdhzOm.

Por fim, associe o evento btnSelectPhoto_Click ao objeto btnSelectPhoto. Adicione o seguinte código na função WinJS.UI.Pages.define { ready }:

var btnSelectPhoto = document.getElementById("btnSelectPhoto"); if (null != btnSelectPhoto)   btnSelectPhoto.addEventListener(     "click", btnSelectPhoto_Click, false);

Nesse ponto, o Contoso Photo Finish tem conteúdo para postar e eu tenho o mecanismo para me autenticar no Facebook para postagem. Agora o aplicativo só precisa interagir com a API e lançar o conteúdo online.

Gerando e postando informações via XHR

Lembra-se de quando o AJAX era novo e emocionante? O XHR entrou em cena no Internet Explorer 5.5 e fez com que os desenvolvedores da Web começassem a repensar como os aplicativos Web estavam sendo criados. O tempo passou e o AJAX cresceu com muitas bibliotecas diferentes (como jQuery) em uma solução fácil de entender e (o mais importante) fácil de implementar. O WinJS.xhr continua essa tradição com uma API simples para obter e postar dados nos serviços online.

Retorne à função btnAddRun_Click e substitua o comentário "Add API calls here" pelo código mostrado na Figura 6.

Figura 6 Gerando um objeto Blob de selectedPhotoStream

var fileBlob = MSApp.createBlobFromRandomAccessStream(   selectedPhotoFile.contentType,   selectedPhotoStream); var message = "I just ran " + document.getElementById(   "txtDistance").value + " miles with PhotoFinish! " +    document.getElementById("txtComment").value; var data = new FormData(); data.append("source", fileBlob); data.append("filename", selectedPhotoFile.name); data.append("access_token", token); data.append("message", window.toStaticHTML(message)); WinJS.xhr({   type: "POST",   url: "https://graph.facebook.com/me/photos",   data: data, }).then(   function (photoid_response) {     ProcessResponse(photoid_response);   },   function (ex) {     Display("An error occurred while posting the photo.");     Log(ex);   });

Antigamente, o aplicativo armazenava StorageFile e Stream nas variáveis selectedPhotoFile e selectedPhotoStream. MSApp.createBlobFromRandomAccessStream usa selectedPhotoStream e gera um objeto Blob (bit.ly/Stfu9z) que o aplicativo, posteriormente, passará para o Facebook como um parâmetro POST. Esse é um recurso útil para converter objetos do WinRT em um formato que possa ser transferido via HTTP.

Em seguida, o código usa o objeto FormData (novo no HTML5) para criar os parâmetros que serão enviados no HTTP POST. FormData é um objeto do par chave/valor com apenas um método: append. Usando o método append, os desenvolvedores podem criar campos de formulário dinamicamente e enviá-los com um POST como se o evento submit do formulário fosse chamado. FormData também fornece os parâmetros como se pertencessem a um formulário com codificação de dados pelo formulário/partes múltiplas. Isso permite aos desenvolvedores postar qualquer tipo de entrada (incluindo arquivos) no servidor de destino.

Observe que na chamada do método FormData.append uso toStatic­HTML (bit.ly/ZRKBka) para garantir que o conteúdo da mensagem esteja seguro para entrega. Usar toStaticHTML removerá todos os atributos de evento ou conteúdo de script da variável de mensagem antes de adicioná-la ao objeto FormData. Embora eu imagine que o Facebook tenha boas medidas de segurança contra ataques (entre outros) de script entre sites, como um desenvolvedor de mashup, desejo fornecer conteúdo limpo aos meus aplicativos de mesmo tipo. A Internet é um lugar grande, por isso precisamos olhar uns pelos outros.

O restante do bloco de códigos é a chamada WinJS.xhr. Nesse período, o código usa mais alguns atributos de XHR, incluindo:

  • type: define o método HTTP a ser usado. Por padrão, type é definido como GET. Esse código usa POST porque o aplicativo está enviando conteúdo à API do Facebook.
  • data: consiste em parâmetros a serem transmitidos com o POST.

Quando a promessa é retornada no método bem-sucedido, Contoso Photo Finish processa a ID da foto para recuperação posterior. Se ocorrer um erro, a mensagem de erro padrão será exibida e a exceção será registrada em log.

WinJS.xhr é bem parecido com outros wrappers do XHR. Se estiver familiarizado com as bibliotecas do JavaScript, como jQuery, você poderá selecionar WinJS.xhr com facilidade. Uma pegadinha que você pode encontrar é que, diferentemente do XHR, não há opção de tempo limite no método WinJS.xhr. A configuração do tempo limite pode ser feita encapsulando a chamada WinJS.xhr com um método WinJS.Promise.timeout (bit.ly/Qgtx7a). Ao adicionar o código a seguir ao início da chamada WinJS.xhr, defina um tempo limite de 10 segundos para o POST:

WinJS.Promise.timeout(1000, WinJS.xhr({ ... });

Se a promessa WinJS.xhr não for concluída em 10 segundos, o tempo limite se esgotará e a promessa será manipulada por meio da função de erro da promessa do tempo limite.

Primeiras etapas para combinar seu aplicativo

Neste artigo, examinei a autenticação, obtendo arquivos e enviando dados com WinJS e o Tempo de Execução do Windows. Essas habilidades básicas podem ser criadas no design de aplicativos da Windows Store que são limitadas somente pela sua imaginação e pelas chaves do desenvolvedor. Aproveite o material deste artigo e explore seu serviço online favorito. Usando WinJS.xhr, seu aplicativo da Windows Store pode interagir com as incontáveis APIs disponíveis online. Com o agente de autenticação da Web, seu aplicativo não pode conectar usuários às respectivas personalidades online, ao conteúdo e às comunidades usando OAuth ou OpenID. WinJS e o Tempo de Execução do Windows fornecem todas as ferramentas para criar com facilidade um aplicativo que é maior que a soma de seus serviços online.

Tim Kulp lidera a equipe de desenvolvimento da FrontierMEDEX, em Baltimore. Você pode encontrar Kulp em seu blog, em seccode.blogspot.com ou no Twitter, em Twitter.com/seccode, onde ele fala sobre códigos, segurança e o cenário gastronômico de Baltimore.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Sunil Gottumukkala e Jeremy Viegas