Ormai il mondo del web avanza molto più velocemente di quanto ci si potesse aspettare agli albori di questa tecnologia. Ogni giorno vengono rilasciate nuove librerie, implementate nuove applicazioni e studiati nuovi approcci ai problemi normalmente affrontati che è praticamente impossibile seguire in dettaglio tutte queste trasformazioni. Figuriamoci implementare ogni volta una versione personalizzata del servizio che si adatti al nostro ambiente di lavoro ...
Fortunatamente, con l'evolversi delle tecnologie di programmazione internet, gli sviluppatori hanno pian piano iniziato a lavorare nell'ottica di rendere i loro prodotti interfacciabili con applicazioni di terze parti: in questo modo chiunque può utilizzare funzionalità complesse da implementare nuovamente facilitandosi il compito ed allo stesso tempo ampliando il bacino di utenza della libreria sfruttata.
Tra i vari servizi utilizzati dagli utenti di tutto il mondo non possiamo accantonare quelli di Google che stanno via via sovrastando le alternative grazie ad un ottimo livello di integrazione e velocità di evoluzione.
I dati sono la fonte fondamentale di informazioni che è molto importante condividere ed utilizzare correttamente: Google ci viene incontro fornendo delle API apposite, chiamate Google Data APIs (o GData per gli "amici") che si occupano per l'appunto di fornire un'interfaccia comoda e semplice per lavorare con i dati solitamente gestiti dalle sue applicazioni di punta. Possiamo accedere e manipolare dati di Calendar, Blogger, CodeSearch e molti altri appoggiandoci a standard affermati e con il minimo sforzo.
Lo Zend Framework fornisce una libreria che facilita ulteriormente l'introduzione di queste funzionalità nelle nostre applicazioni; essendo lo Zend Framework una serie di librerie che, salvo alcuni casi, possono lavorare indipendentemente l'una dall'altra ed essendo supportata da molti sviluppatori e dalla Zend stessa, sicuramente rimane una delle migliori alternative a disposizione degli sviluppatori PHP.
Lo Zend Framework e GData
Come accennato precedentemente, le API GData utilizzano un protocollo standard per le interrogazioni, nello specifico il protocollo APP (Atom Publishing Protocol) supportato dal formato Atom. Ogni servizio che può essere interrogato dalle API GData è esposto nel framework Zend con un'apposita classe che fornisce i metodi necessari all'interrogazione, nascondendo gran parte delle operazioni relative al processo di generazione delle chiamate e decodifica delle risposte. Queste classi estendono tutte dalla classe base Zend_Gdata_App
.
Per interrogare una delle applicazioni disponibile è necessario interagirvi attraverso una sottoclasse di Zend_Gdata_Query
; questa classe fornisce le funzionalità necessarie a limitare le interrogazioni, fornire le chiavi di ricerca e generare gli URL che rappresentano l'interrogazione da effettuare.
I dati vengono restituiti sotto forma di feed e vengono inviate al server sotto forma di Entry. Ogni entry specifica in base all'applicazione interrogata eredita dalla classe base Zend_Gdata_App_Entry
e viene utilizzata anche per estrarre dai feed i dati restituiti da un'interrogazione.
Questa è in poche parole la struttura delle API esposte dallo Zend Framework per interagire con le API Gdata.
In generale è bene ricordare che Google limita l'accesso ai dati privati o alle operazioni di aggiornamento o eliminazione a tutti gli utenti non correttamente autenticati; se si desidera effettuare queste operazioni è necessario avere a disposizione delle chiavi di accesso corrette, che potranno essere successivamente utilizzate tramite le librerie di autenticazione esposte.
Esistono due sistemi di accesso chiamati AuthSub e ClientLogin. Il primo è consigliato per applicazioni web, o comunque tutte quelle applicazioni che possono permettersi di gestire un rindirizzamento ad una pagina HTML del server di Google che verrà utilizzata per l'autenticazione; dopo l'autenticazione verrà utilizzata una stringa (chiamata token) che, appositamente integrata nel processo di utilizzo della libreria, permetterà di interfacciarsi ai dati privati. Il secondo sistema è invece consigliato per le applicazioni Desktop ed utilizza un sistema di credenziali basate su username e password che possiamo considerare standard.
In generale le operazioni necessarie per operare con le API GData tramite lo Zend Framework prevedono l'acquisizione di un'istanza della classe relativa all'applicazione che si vuole interrogare, preventivamente inizializzata con i dati relativi alle credenziali di autenticazione. Successivamente questa classe può essere interrogata e manipolata direttamente senza doversi preoccupare della comunicazione con il server di Google che verrà svolta automaticamente.
Autenticazione in pratica con le API Gdata
In base all'esigenza è possibile instanziare la classe da utilizzare per l'accesso trasparente ad i dati di Google fornendo delle informazioni di autenticazione ottenute utilizzando uno dei metodi esposti dalla libreria oppure procedere con un utente non autenticato che avrà accesso in lettura solamente ai calendari pubblici.
Se si desidera autenticare l'utente utilizzando ClientLogin, sarà necessario disporre di nome utente e password valide e poi procedere come segue:
require_once 'Zend/Loader.php'; Zend_Loader::loadClass('Zend_Gdata'); Zend_Loader::loadClass('Zend_Gdata_ClientLogin'); Zend_Loader::loadClass('Zend_Gdata_Calendar'); Zend_Loader::loadClass('Zend_Http_Client'); $client = Zend_Gdata_ClientLogin::getHttpClient("nome_utente@gmail.com", "password", Zend_Gdata_Calendar::AUTH_SERVICE_NAME); $service = new Zend_Gdata_Calendar($client);
attraverso la funzione getHttpClient
della classe Zend_Gdata_ClientLogin
viene generata un'istanza della classe Zend_Http_Client
che verrà utilizzata per accedere ai servizi di Google. Questo metodo accetta un nome utente ed una password obbligatori. Oltre a questi due parametri è possibile specificare il nome (sotto forma di stringa e solitamente esposto con una costante definita nella classe relativa al servizio che volgiamo utilizzare) del servizio; se non lo si specifica verrà utilizzato un valore generico che Google accetterà indipendentemente dal servizio acceduto.
Se si desidera invece autenticare l'utente attraverso AuthSub il processo è leggermente più complesso e sfrutta le sessioni (direttamente dalla documentazione ufficiale):
function getCurrentUrl() { global $_SERVER; $php_request_uri = htmlentities(substr($_SERVER['REQUEST_URI'], 0, strcspn($_SERVER['REQUEST_URI'], "nr")), ENT_QUOTES); if (isset($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) == 'on') { $protocol = 'https://'; } else { $protocol = 'http://'; } $host = $_SERVER['HTTP_HOST']; if ($_SERVER['HTTP_PORT'] != '' && (($protocol == 'http://' && $_SERVER['HTTP_PORT'] != '80') || ($protocol == 'https://' && $_SERVER['HTTP_PORT'] != '443'))) { $port = ':' . $_SERVER['HTTP_PORT']; } else { $port = ''; } return $protocol . $host . $port . $php_request_uri; } function getAuthSubHttpClient() { global $_SESSION, $_GET; if (!isset($_SESSION['sessionToken']) && !isset($_GET['token'])) { // Parameters to give to AuthSub server $next = getCurrentUrl(); $scope = "http://www.google.com/calendar/feeds/"; $secure = false; $session = true; $authSubUrl = Zend_Gdata_AuthSub::getAuthSubTokenUri($next, $scope, $secure, $session); header("HTTP/1.0 307 Temporary redirect"); header("Location: " . $authSubUrl); exit(); } if (!isset($_SESSION['sessionToken']) && isset($_GET['token'])) { $_SESSION['sessionToken'] = Zend_Gdata_AuthSub::getAuthSubSessionToken($_GET['token']); } $client = Zend_Gdata_AuthSub::getHttpClient($_SESSION['sessionToken']); return $client; } session_start(); $service = new Zend_Gdata_Calendar(getAuthSubHttpClient());
Il concetto è sempre quello di creare un'istanza della classe Zend_Http_Client
da passare come primo argomento al costruttore della classe che si occuperà di interfacciarsi con la nostra applicazione; a differenza del sistema precedente però, la classe client viene generata in modo differente attraverso il metodo getAuthSubHttpClient
. Questo metodo in primis controlla se abbiamo già a disposizione un token da utilizzare per le interrogazioni.
Un token è una stringa generata successivamente ad un'autenticazione effettuata sul server di Google da un determinato indirizzo, a cui si verrà reindirizzati in caso il token non esiste. Se il token esiste invece, viene salvato in sessione ed utilizzato come parametro per il metodo getHttpClient
della classe Zend_Gdata_AuthSub
. La funzione getCurrentUrl
viene utilizzata per indicare quale sarà l'indirizzo al quale il server Google dovrà reindirizzare la chiamata successivamente ad un'autenticazione corretta. Questo valore viene passato insieme all'url della pagina di autenticazione ed a due parametri che indicano sei il server è sicuro e se si utilizzano le sessioni al metodo getAuthSubTokenUri
, che genera un indirizzo HTTP da utilizzare per reindirizzare il processo di autenticazione.
Conclusione
Nel prossimo articolo procederemo con la libreria Gdata, introducendo le prime operazioni di lettura ed interrogazione su Google Calendar.