Scaricare una risorsa web all’interno di una applicazione Windows Phone: occhio alle policy!
Posted by qmatteoq in Windows Phone Tutorials on Friday 01 April 2011 at 11:00 AM
Se siete già pratici del mondo Silverlight sarete già sicuramente a conoscenza di questo fatto, ma se vi siete avvicinati a questo ambiente di sviluppo grazie a Windows Phone potreste trovarvi nella situazione di perdere un sacco di tempo ad affrontare errori che, alla fin fine, non dipendono da voi.
Ma andiamo per gradi: come sapete, Silverlight è una tecnologia client, ovvero le nostre applicazioni girano all’interno del browser, sul nostro computer o sul nostro device ma, al contrario di un’applicazione web, non hanno modo di interfacciarsi direttamente con un server (ad esempio, per eseguire una query su un database). I servizi giocano un ruolo essenziale in questo scenario, dato che tipicamente fanno proprio da ponte tra la parte server della nostra applicazione (ad esempio, il database con i nostri dati) e la parte client (l’interfaccia in Silverlight).
Per motivi di sicurezza, lo stesso principio vale quando vogliamo recuperare una risorsa che sta all’esterno della nostra applicazione (ad esempio, un file XML). Per consentire questi scenari, chi gestisce il server web può concedere ad applicazioni Silverlight esterne di leggere le proprie risorse definendo un file di policy, che specifica a cosa può e a cosa non può accedere la nostra applicazione.
Silverlight è in grado di comprendere due tipologie di file di policy:
- clientaccesspolicy.xml: è il tipo di file nativamente supportato da Silverlight.
- crossdomain.xml: anche Flash è una tecnologia client esattamente come Silverlight e perciò deve sottostare alle stesse regole. Crossdomain.xml è il file di policy nativamente supportato dalla tecnologia Adobe, ma è comprensibile e utilizzabile anche da Silverlight.
Quando un’applicazione Silverlight cerca di accedere ad una risorsa esterna (tecnicamente, si tratta di una chiamata cross domain), va a cercare prima il file clientaccesspolicy.xml nella root del dominio. Se non lo trova, passa a cercare il file crossdomain.xml. Se non trova neanche quello, Silverlight considera il dominio come non abilitato alle chiamate cross domain e quindi restituirà un’eccezione. Tali file vengono cercati, come dicevo poco fa, nella root: se stiamo cercando di accedere ad esempio alla risorsa http://qmatteoq.tostring.it/resources/file.xml, Silverlight cercherà i file http://qmatteoq.tostring.it/clientaccesspolicy.xml e http://qmatteoq.tostring.it/crossdomain.xml.
Vediamo un semplice esempio di file clientaccesspolicy.xml:
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy >
<allow-from http-request-headers="SOAPAction">
<domain uri="http://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Questo file, utilizzando la wildcard *, garantisce alle applicazioni Silverlight accesso a qualsiasi risorsa all’interno del nostro dominio utilizzando il protocollo HTTP. E’ possibile definire maggiore granularità, per dare accesso solo ad alcuni percorsi del nostro dominio oppure dare accesso anche tramite altri protocolli / porte (ad esempio, tramite una socket).
Quando entra in gioco il file di policy
Per un applicazione Windows Phone, la risposta è semplice: ogni qualvolta dobbiamo recuperare una risorsa qualsiasi da un sito web, che si tratti di un file XML, di una immagine o altro. Tipicamente, queste richieste vengono fatte utilizzando gli oggetti WebClient (più semplice da utilizzare ma che consuma maggiori risorse) o HttpWebRequest (più veloce e performante, ma più complesso da usare). Se nell’utilizzo di una di queste due classi ci imbattiamo in errori del tipo Unspecified Error, allora quasi sicuramente ci siamo imbattuti in un sito il cui file di policy è mancante oppure vieta esplicitamente l’utilizzo delle risorse
Verificarlo è semplice: vi basta puntare l’URL del vostro browser al file di policy, che vi ricordo deve essere presente nella root di dominio (ad esempio, http://www.website.com/clientaccesspolicy.xml).

Recent Comments