• Articolo

Il presente articolo è stato tradotto automaticamente.

Sicurezza

Accesso ai servizi online con il Windows Runtime e OAuth

Tim Kulp

Scarica il codice di esempio

Una volta, ai tempi del Web 1.0, siti Web erano silos di contenuto da leggere e nulla più.Come Web 2.0 ronzavano in negozi di sviluppo, siti Web è diventato servizi online con API utilizzate dagli sviluppatori per mescolare e abbinare i componenti, i dati e funzionalità.Ora, mashup consentono agli sviluppatori di accedere alle librerie di contenuti ricche senza l'overhead della custodia dei dati nelle loro sale server.

Con il Windows Runtime (WinRT), è possibile portare la potenza dei mashup per il vostro prossimo app Store di Windows.Se siete gestione dati con XmlHttpRequest (XHR) o l'autenticazione con un servizio remoto con la classe WebAuthenticationBroker, libreria Windows per JavaScript (WinJS) e il Runtime di Windows fare schiacciare servizi online con la tua applicazione facile.

Contoso Photo Finish

In questo articolo ho intenzione di costruire un mashup chiamato Contoso Photo Finish.Lascia i corridori track loro km e postare una foto di loro corre.Molti corridori come condividere informazioni come la distanza e la posizione di loro corre sui social network.Contoso Photo Finish consente agli utenti di dire ai loro amici di loro corre con commenti e immagini su Facebook.Questa app si connetterà a due diversi servizi:

  • Windows SkyDrive per recuperare una foto da corsa
  • Facebook per postare le foto per i loro amici visualizzare

Contoso Photo Finish combineranno questi servizi per fornire un'esperienza collegata per l'utente.Questo articolo presuppone che hai Visual Studio 2012 aperto con JavaScript | Windows Store | App modello pronto iniziare la codifica per vuoto.

Transenne mashup: Autenticazione e autorizzazione

Se un app (Web o Windows Store) vuole pubblicare contenuti a Facebook, il primo ostacolo da superare è l'autenticazione.Facebook ha bisogno di sapere chi si connette ad esso.Quando gli utenti tentano di accedere a apps, affermano un'identità (solitamente sotto forma di un nome utente) e una credenziale (ad esempio una password, token dispositivo biometrico di sicurezza e così via) per dimostrare che essi dovrebbero avere accesso all'identità richiesto.L'autenticazione è il processo di convalida di identità di un utente attraverso una credenziale.

Dopo l'autenticazione dell'utente, il mashup è un'altra sfida: determinare cosa può fare l'utente nel sistema.Autorizzazione è il processo di permettere o negare un'identità sta tentando di eseguire azioni basate su qualche appartenenza al ruolo di attributo o di sicurezza.Ad esempio, in Twitter mia identità non è consentito eliminare tutti i tweets di tutti gli utenti.Sto torizzata per eseguire quell'azione, perché io non sono un membro del ruolo di sicurezza con il permesso di farlo.Insieme, l'autenticazione e l'autorizzazione (A & A) rappresentano la domanda: Utente, chi sei e cosa si può fare?

Mashups amplificare queste sfide perché lo sviluppatore costruendo il mashup non ha accesso a dove sono memorizzati le identità, le credenziali e i ruoli di protezione (spesso definito come un archivio di credenziali).Quindi se non posso verificare chi è chi e che cosa possono fare, come posso costruire un mashup per applicazioni come Facebook?OAuth per il salvataggio!

OAuth: L'accesso alle risorse, non Apps

OAuth affronta la sfida di A & A per mashups.Immaginate che app X vuole accedere ai contenuti da Y servizio Online.Anziché l'autenticazione utente per App X, autenticazione dell'utente a Online servizio Y perché le credenziali dell'utente sono memorizzate nell'archivio credenziali Online servizio di Y.L'utente quindi permessi X App per accedere alle risorse specificate da Y servizio on-line per un tempo limitato.L'autorizzazione per accedere alle risorse Online servizio Y viene restituito al App X come un access token (a volte indicato semplicemente come un "token").

Nel Web tradizionale A & A modelli, due partecipanti lavorano insieme per determinare l'accesso di un utente: l'applicazione e l'utente (o il server e client).In OAuth viene introdotto un terzo partecipante: il server di risorsa.Server risorsa sono i terzi che hanno una risorsa (ad esempio una foto) memorizzata sul server che un client deve accedere.In Contoso Photo Finish, Facebook è un server di risorsa.La risorsa che Contoso Photo Finish vuole accedere è stato dell'utente, al fine di inviare un messaggio.

OAuth Clients e i processi di autenticazione

Ci sono due tipi di client in OAuth, e quale tipo di utilizzo è deciso dal livello del cliente di fiducia.Riservate ai clienti possono proteggere le proprie credenziali e sono pensati per ambienti altamente attendibili.Esempi di client riservate sono applicazioni Web lato server dove il segreto del client può essere mantenuto in un ambiente controllato e sicuro.Riservate ai clienti utilizzano il processo di autorizzazione codice per ottenere un token di protezione fornendo il segreto del client al server di risorse come un mezzo per l'autenticazione del client.

Clienti pubblici non possono proteggere le proprie credenziali perché corrono in un ambiente ostile.Clienti pubblici esempio sarebbe applicazioni user-agent (cioè, JavaScript Web apps) o applicazioni native (ad esempio Windows Store apps).Public client utilizzano il processo di "implicita concessione" per ottenere un token di protezione perché il segreto di client non può essere immagazzinato in modo sicuro all'interno di un ambiente ostile che è fuori dal controllo dello sviluppatore.

Windows Store apps può essere configurato per utilizzare sia implicita concessione o autorizzazione codice processi per OAuth (si può leggere di più sui processi codice impliciti concessione e l'autorizzazione a bit.ly/yQjyQZ).È una best practice di sicurezza utilizzare implicita concessione qualsiasi momento che un'app è fuori controllo dello sviluppatore.

In Figura 1 esaminare un'implicita concessione processo dove il client avvia la conversazione cercando di determinare l'identità di un utente con il server di risorsa.

Windows Store App Implicit Grant ConversationFigura 1 App Store Windows implicita concessione conversazione

La procedura illustrata Figura 1 sono spiegati qui:

  1. L'app Store Windows deve eseguire alcune funzionalità che richiede l'accesso all'API di Facebook.
  2. L'utente si connette al server di risorse tramite un URI che include informazioni sul app Store di Windows tenta di accedere all'API di Facebook.Questo è di solito sotto forma di un codice di identificazione app ID o client.L'utente fornisce un nome utente e password per accedere a Facebook.
  3. Supponendo che successo login, Facebook offre l'app Store di Windows con un token di accesso.
  4. L'app Store di Windows può ora fornire l'utente con dati dall'API di Facebook utilizzando il token di accesso fornito da Facebook per ottenere il feed dell'utente, post immagini e così via.

Facendo questa conversazione accadere è sorprendentemente facile attraverso il nuovo spazio dei nomi Windows.Security.Authentication.Web.

WebAuthenticationBroker

In Windows Store apps il WebAuthenticationBroker classe (bit.ly/RW8czT) è il componente che comunicano con il server di risorse, fornirà i controlli login e rispondere a un accesso riuscito, tutto senza bisogno di app Store Windows sapere nulla circa le credenziali dell'utente.Per l'applicazione di esempio, Contoso Photo Finish ha bisogno di pubblicare le immagini su Facebook.Questo richiede all'utente di autenticarsi su Facebook e ricevono un token di accesso.

Aggiungere un nuovo controllo pagina al progetto Contoso Photo Finish chiamato input.html.Per impostazione predefinita, Visual Studio fornisce un sacco di markup per te.Sostituire "<p> contenuto goes here. </p>" nella sezione contenuto principale con il seguente pulsante:

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

Questo è il pulsante che l'utente sarà fare clic per aggiungere una corsa al fotofinish. Ora aprite input. js e aggiungere la seguente funzione:

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
}

Questo codice stabilisce le variabili che verranno utilizzate nell'authen­richiesta tication. La prima variabile è l'URL del servizio Facebook OAuth. ID client è l'identificatore di app di Facebook consente di identificare Contoso Photo Finish come l'app con cui interagisce l'API di Facebook. Un identificatore di questo è normalmente assegnato un app quando è stato registrato con il server di risorsa. Alcuni server di risorse consultare gli identificatori come client id, id di app o solo id. Quale id da utilizzare sarà trovato nella documentazione delle API del server resource.

Il parametro redirectUrl determina l'app dove andrà dopo che l'utente si autentica e approva l'accesso dell'applicazione alle risorse specificate. In questo caso il redirectUrl è impostata su uno standard di Facebook che è disponibile per tutte le API di Facebook apps. Alcuni servizi richiedono URI del app Store di Windows per essere identificato con il server di risorse quando l'applicazione viene registrato. URI dell'app può essere trovato utilizzando il metodo getCurrentApplicationCallbackUri del broker autenticazione Web. Ciò restituirà il contesto locale di app URI (inizia con "ms-app: / /"). Alcuni server di risorsa non supporta ms-app: / / come un protocollo valido per un redirectUrl, nel quale caso si dovrebbe verificare per un indirizzo di redirezione predefinito come ciò che Facebook offre.

Successivamente, il callbackUri è definito. Questo è l'indirizzo che informa il broker di autenticazione Web quando l'autenticazione è completo e restituisce il controllo al app Store di Windows. Il broker mai in realtà va a questo URL; esso semplicemente orologi per il server di risorsa di chiamare per questa pagina e quindi restituisce il callbackUri con qualsiasi query string o hash parametri che sono stati aggiunti. In questo caso, il parametro hash "access_token" fornirà Contoso Photo Finish il token necessario per interagire con le API.

La classe WebAuthenticationBroker utilizza il metodo authenticateAsync per connettersi e completare il processo di autenticazione con il server di risorsa. Quando viene chiamato authenticateAsync, l'app si apre un pop-up che visualizza la schermata di login del server risorsa, come mostrato Figura 2. Una volta che l'autenticazione è completo o il callbackUri viene rilevato, il pop-up si chiuderà.

Resource Server’s Login Pop-up from authenticateAsync
Login popup figura 2 Resource Server da authenticateAsync

Un vantaggio chiave di utilizzare questo pop-up è che l'app Store Windows mai gestisce o ha bisogno di conoscere le credenziali dell'utente per la gestione di risorse. Tutte le app sa è il token di accesso che viene restituito dal server di risorse. Questa separazione mantiene la risorsa le credenziali del server isolate da app, che evita il rischio per la sicurezza dell'app memorizzare le credenziali. In cima ai vantaggi di sicurezza, lo sviluppatore non ha codice nulla per ottenere questa interfaccia; è costruito al metodo authenticateAsync. Quando gli sviluppatori di chiamano il metodo, l'interfaccia viene con esso.

Ora, torniamo al codice. Sostituire il commento "broker di autenticazione Web andrà qui" con il seguente codice:

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

Il metodo authenticateAsync accetta tre parametri (il terzo è opzionale):

  1. WebAuthenticationOptions: Questo è usato per fornire istruzioni al broker l'autenticazione Web su come eseguire il rendering della finestra di dialogo autenticazione o i dati da restituire nella risposta. Nell'esempio precedente, l'applicazione utilizza "nessuno" per mostrare un'implementazione comune che non passa opzioni al broker utilizzando un'installazione predefinita.
  2. requestUri: Questo è il punto di ingresso di login per il server di risorsa. In questo caso, Contoso Photo Finish si connette al servizio OAuth di Facebook. RequestUri deve essere tramite una connessione protetta utilizzando il protocollo HTTPS.
  3. callbackUri: Questa è la pagina che, quando vi si accede, restituisce il controllo indietro al broker l'autenticazione Web come descritto in precedenza. Questo argomento è facoltativo, ma se il server di risorse non può (o non) reindirizza a ms-app: / /, questo parametro è come l'app sfuggiranno controllo del server resource. Ad esempio, nel codice precedente quando https://www.facebook.com/connect/login\_success.html si accede dopo un accesso riuscito, il broker di autenticazione Web prenderà il controllo dell'app dal server risorsa chiudendo la finestra di dialogo di autenticazione e il successo della promessa di elaborazione. CallbackUri non deve essere nella pagina successiva immediata; potrebbe essere dopo una procedura guidata o un altro processo che deve avvenire sul sito del server di risorse. Questo URI normalmente sarà lo stesso come il redirectUrl ma fornisce la flessibilità per estendere il processo di autenticazione, se necessario.

Se il broker di autenticazione Web si connette al server di risorse, la promessa ha esito positivo. Rilevando il risultato del processo di autenticazione viene eseguita tramite la proprietà ResponseStatus dell'oggetto WebAuthenticationResult. Nel codice precedente, l'argomento di risultato è un oggetto WebAuthenticationResult con tre proprietà: Risposta (dati dal server di risorse), ResponseErrorDetail (se qualcosa è andato storto, che cosa era?) e ResponseStatus (Qual è lo stato dell'autenticazione?). Sostituire il commento "Verificare lo stato della risposta" con il codice mostrato Figura 3.

Figura 3 lavorando con il risultato del processo di autenticazione

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

Nella Figura 3 codice, ogni stato viene controllato, con il metodo Log registrazione le informazioni dal server di risorse e il metodo di visualizzazione che dice all'utente cosa si è verificato. Messaggi di errore, ricordati di visualizzare i messaggi di facile utilizzo per migliorare l'usabilità e ridurre l'esposizione accidentale di informazioni riservate da un messaggio di errore generato dal sistema. Se l'autenticazione ha esito positivo, il frammento URI restituito da Facebook è analizzato e memorizzato nella variabile token per uso nella chiamata API (vedi guida "e" invio informazioni via XHR sezione per i dettagli di implementazione).

Con la funzione di btnAddRun_Click completa, connettersi all'oggetto nella funzione {pronta} WinJS.UI.Pages.define btnAddRun:

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

A questo punto l'app ha un token di accesso, mostrando che l'utente è autenticato al server di risorse. Nell'ultima sezione l'applicazione eseguirà i comandi API per inviare i dati, ma prima l'app ha bisogno di qualcosa per inviare a Facebook.

Acquisizione dell'immagine

Windows 8 fornisce una varietà di contratti che consentono applicazioni a parlare con a vicenda, come la ricerca, selezione e Condividi e file. Questi contratti possono trasformare qualsiasi applicazione in un mashup con poche righe di codice. Contoso Photo Finish è andando a sfruttare la potenza del contratto di selezione file per trovare un'immagine di esecuzione dell'utente.

Una delle tante cose che amo di mio Windows Phone è l'integrazione con SkyDrive. Io posso caricare le mie foto istantaneamente allo storage nel cloud così la prossima volta che rompo il mio telefono (che è spesso), mie immagini sono in attesa per me on-line. L'app di SkyDrive per Windows 8 fornisce i dati per la selezione di file, rendendo la selezione dei file dal mio account SkyDrive semplice come selezionandoli dalla libreria foto. La parte successiva del mashup Contoso Photo Finish consumerà dati da app SkyDrive attraverso la finestra di selezione file. Per fare questo, input.html alcuni, deve pure. . . ingressi.

Sostituire il pulsante di btnAddRun con il codice mostrato Figura 4. Questo codice include i campi di input per l'utente di fornire i contenuti per Contoso Photo Finish. Il pulsante btnSelectPhoto utilizzerà la finestra di selezione file per selezionare quale file system da utilizzare. Aggiungere una nuova funzione a input. js che sarà il gestore click per 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 campi di Input per fornire contenuti per l'App

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

La funzione inizia impostando la variabile imgSelectedPhoto, che verrà utilizzata per visualizzare la foto selezionata per l'utente. Successivamente, il codice crea un oggetto di selezione file. Oggetto di selezione file permette Contoso Photo Finish per scegliere file o cartelle (in questo caso solo files) del sistema o in altre applicazioni che partecipano al contratto di selezione file per aprire e interagire all'interno della app. Utilizzando il filtro tipo di file, il codice limiti quali estensioni di file sono accessibili per la finestra di selezione file. L'app può caricare solo immagini di Facebook (di progettazione), così limitante la selezione di file per funzionare solo con tipi di file immagine specificato impedisce l'utente selezionando i file che hanno estensioni non valide che non soddisfano la funzionalità desiderata. Inoltre, a causa della messa a fuoco di app su immagini, posizione iniziale di selezione del file è impostata sulla libreria foto. Questo potrebbe essere una varietà di posizioni predefinite (come la libreria musicale, raccolta documenti, gruppo home e così via), ma quando si tratta di immagini, la libreria di foto è un punto di partenza del senso comune. L'ultima impostazione per la selezione di file è possibile impostare la viewMode su anteprima. Questo consente di visualizzare un'anteprima del file ed è ideale per la selezione di immagini.

Con il set di opzioni, è il momento di selezionare il file da utilizzare per l'esecuzione. In primo luogo, aggiungere queste due dichiarazioni di variabili direttamente sotto l'istruzione "use strict":

var selectedPhotoStream = null;
var selectedPhotoFile = null;

Quando i dati vengono caricati su Facebook, questi terrà i valori file e stream per la funzione btnAddRun_Click. Ora sostituire il commento "Pick file qui" con il codice mostrato Figura 5.

Figura 5 raccogliendo un File

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

Figura 5 appare come un sacco di codice, ma esso si riduce a tre azioni:

  1. Selezionare il file che verrà utilizzato l'app tramite la finestra di selezione file (pickSingleFileAsync).
  2. Aprire il flusso di file per essere letto (openAsync).
  3. Memorizzare il flusso e il file nelle variabili per un uso successivo.

Tutto il codice è standard per lavorare con file e flussi con una sola eccezione: URL.createObjectURL prende un oggetto e costruisce un URL per l'oggetto da visualizzare tramite un oggetto image. Il metodo createObjectURL funziona con molti tipi di oggetto Stream, StorageItem e MediaCapture. In generale esso viene utilizzata per visualizzare contenuti multimediali (immagini, audio o video) in un app Store di Windows. Una cosa da tenere a mente quando si utilizza createObjectURL è che quando hai finito utilizzando l'URL, assicurarsi di disporre di esso attraverso il metodo URL.revokeObjectURL. Questo garantirà utilizzo ottimale della memoria e impedire che l'app Store Windows impantanarsi con troppi URL temporaneo. Per ulteriori informazioni su createObjectURL, consultare la documentazione MSDN a bit.ly/XdhzOm.

Infine, associare l'evento btnSelectPhoto_Click con l'oggetto btnSelectPhoto. Aggiungere il seguente codice nella funzione {pronta} WinJS.UI.Pages.define:

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

A questo punto, Contoso Photo Finish ha contenuto al post e ho il meccanismo di autenticazione a Facebook per la pubblicazione. Ora l'app ha solo bisogno di interagire con le API e gettare il contenuto online.

Ricevendo ed inviando informazioni tramite XHR

Ricordate quando AJAX era nuovo ed eccitante? XHR è venuto scena in Internet Explorer 5.5 e fatto gli sviluppatori Web iniziano a ripensare come Web apps sono stati fatti. Il tempo passava e AJAX è cresciuto con molte diverse librerie (come ad esempio jQuery) in una soluzione facile da implementare (più importante) e facile da capire. WinJS.xhr continua questa tradizione con una semplice API per ottenere e pubblicare dati ai servizi online.

Restituire alla funzione btnAddRun_Click e sostituire il commento "Aggiungi API chiama qui" con il codice mostrato Figura 6.

Figura 6 generazione di un oggetto Blob da 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);
  });

In precedenza, l'app memorizzato il StorageFile e il flusso nelle variabili selectedPhotoFile e selectedPhotoStream. MSApp.createBlobFromRandomAccessStream prende il selectedPhotoStream e genera un oggetto Blob (bit.ly/Stfu9z) che l'app più tardi passerà a Facebook come un parametro POST. Questa è una caratteristica utile per la conversione di WinRT oggetti in un formato che può essere trasferito via HTTP.

Successivamente, il codice utilizza l'oggetto FormData (nuovo per HTML5) per creare i parametri che verranno inviati nel POST HTTP. FormData è un oggetto di coppia chiave/valore con un solo metodo: Append. Utilizzando il metodo append, gli sviluppatori possono costruire campi modulo dinamicamente e li presenta con un POST, come se il modulo Invia evento fu chiamato. FormData fornisce anche i parametri come se appartenessero a un form con codifica multipart/form-data. Questo permette agli sviluppatori di inviare qualsiasi tipo di input (inclusi file) al server di destinazione.

Si noti che nella chiamata al metodo FormData.append che uso toStatic­HTML (bit.ly/ZRKBka) per garantire che il contenuto del messaggio è sicuro per la consegna. Utilizzando toStaticHTML rimuoverà eventuali attributi eventi o script contenuto della variabile messaggio prima di aggiungerla all'oggetto FormData. Mentre immagino che Facebook è buono per prevenire il cross-site scripting attacchi (tra gli altri), come uno sviluppatore di mashup, desidera fornire contenuto pulita al mio collega apps. Internet è un posto grande, quindi abbiamo tutti bisogno di guardare fuori per l'altro.

Il resto del blocco di codice è chiamata WinJS.xhr. Questa volta intorno, il codice utilizza alcuni ulteriori attributi di XHR, tra cui:

  • Tipo: Questo imposta il metodo HTTP da utilizzare. Per impostazione predefinita il tipo è impostato su GET. Questo codice utilizza il POST perché l'app è l'invio di contenuti per l'API di Facebook.
  • dati: Si tratta di parametri da passare con il POST.

Quando la promessa è tornata nel metodo di successo, Contoso Photo Finish processi foto ID per il successivo recupero. Se si verifica un errore, viene visualizzato il messaggio di errore standard e l'eccezione viene registrato.

WinJS.xhr è molto simile a altri wrapper XHR. Se si ha familiarità con le librerie JavaScript come jQuery, sarete in grado di raccogliere facilmente WinJS.xhr. Uno gotcha che potrebbe verificarsi è che, a differenza di XHR, non non c'è nessuna opzione di timeout sul metodo WinJS.xhr. L'impostazione di un timeout è realizzato avvolgendo la chiamata WinJS.xhr con un metodo WinJS.Promise.timeout (bit.ly/Qgtx7a). Aggiungendo il codice seguente all'inizio della chiamata WinJS.xhr, ho impostato un timeout di 10 secondi per il POST:

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

Se la promessa di WinJS.xhr non completa entro 10 secondi, il timeout di volontà promessa ed essere gestita attraverso la funzione di errore di timeout promessa.

Primi passi a schiacciare la tua App

In questo articolo ho esaminato l'autenticazione, ottenere i file e l'invio dei dati con WinJS e il Runtime di Windows. Queste abilità di Fondazione possono essere costruite su Design Store Windows apps che sono limitati solo dalla vostra immaginazione e sviluppatore tasti. Prendere il materiale in questo articolo ed esplorare il vostro servizio online preferito. Utilizzando WinJS.xhr, l'app Store di Windows possono interagire con le innumerevoli API disponibile online. Con il broker di autenticazione Web, il vostro app può connettere gli utenti con le loro personalità online, contenuti e comunità tramite OAuth o OpenID. WinJS e il Runtime di Windows vi darà tutti gli strumenti per creare facilmente un app che è maggiore della somma dei suoi servizi online.

Tim Kulp porta il team di sviluppo presso FrontierMEDEX in Baltimore. È possibile trovare Kulp sul suo blog a seccode.blogspot.com o su Twitter a Twitter.com/seccode, dove si parla di codice, la sicurezza e la scena di foodie Baltimora.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo: Sunil Gottumukkala e Jeremy Viegas