Facebook offline_access deprecation: estendere l’access_token expiration time

Postato da regole-seo, in Programmatori (Beyond-SEO), in data 24/09/2012

[Parte 3 di 3] Facebook offline_access deprecation: la soluzione.

Indice articoli - "Facebook offline_access deprecation: la soluzione"

facebook-offline_access

Dopo aver visto quali sono le possibili soluzioni ai problemi causati dall’offline_access deprecation di Facebook, vediamo un esempio concreto di come implementare la soluzione numero 4:
“Avvisare preventivamente gli utenti della scadenza imminente dell’access_token e fornire loro uno strumento tramite il quale rigenerarlo”.

Il contesto applicativo è quello di un processo in background che non dispone di un’iterfaccia utente e, ancora più importante, la sua corretta esecuzione deve potere avvenire anche in assenza dell’utente.

Come sappiamo dalla documentazione ufficiale, Facebook da la possibiltà di generare degli access_token con una “expiration time” di 60 giorni.

La nostra soluzione prevede l’utilizzo di tre componenti con i tre rispettivi compiti:

  • Rilevazione dell’”expiration time” effettiva dell’access_token in uso e eventuale segnalazione all’utente interessato.
  • Avvio della procedura di rigenerazione dell’expiration time.
  • Ricezione del nuovo access_token con expiration time rigenerato a 60 giorni.

Vediamo nel dettaglio come possono essere implementati.

Rilevatore dell’”expiration time” effettiva dell’access_token in uso. (Java 1.6)

Questa componente implementata in Java (dipendente dalla libreria javamail reperibile qui.) si occupa di:

  • Reperire da Facebook la quantità di tempo mancante alla scadenza dell’access_token in uso.
  • Avvisare l’utente via e-mail quando mancano meno di 10 giorni alla scadenza dell’access_token, fornedogli le istruzioni per estendere la durata dell’access_token di altri 60 giorni.

L’invio dell-email avviene tramite la classe di utility “MailSender”.
Per ridurre al minimo il codice, l’esempio implementa un semplice metodo main.
Chiaramente l’esecuzione deve in realtà essere schedulata dal sistema tramite crontab o applicativamente usando ad esempio quartz scheduler.
Potrete riadattare questo codice alle vostre specifiche esigenze o ottimizzarne i vari aspetti come la gestione delle eccezioni.

Nel codice sopra esposto sono stati utilizzati dei placeholder che vanno sostituiti con le variabili dipendenti dalla vostra applicazione registrata su Facebook e dalle vostre necessità.
Ecco come sostituire i valori delle variabili:

  • YOUR_FACEBOOK_APP_ID: l’id applicazione / chiave api della vostra applicazione registrata su Facebook.
  • YOUR_FACEBOOK_CLIENT_SEECRET: la chiave segreta della vostra applicazione registrata su Facebook.
  • YOUR_FACEBOOK_APP_REDIRECT_URI : la URL della pagina web (che mostreremo successivamente) a cui Facebook redirigerà l’utetne alla fine della procedura di rigenerazione dell’access_token. Fate attenzione che questa URL deve essere un “sotto path” della URL del sito indicata nella vostra applicazione registrata su Facebook.
  • NO-REPLY@YOURCOMPANY.COM: l’e-mail del mittente che desiderate utilizzare.
  • CUSTOMER_MAIL@CUSTOMER_COMPANY.COM: e-mail del destinatario (l’utente che desiderate avvisare della scadenza dell’access-token).
  • YOUR_SMTP_USERNAME: il vostro username smtp per l’invio dell’e-mail.
  • YOUR_SMTP_PASSWORD: la vostra password smtp per l’invio dell’e-mail.
  • CUSTOMER_CURRENT_FACEBOOK_ACCESS_TOKEN: l’attuale access_token in scadenza, usato dal vostro utetne (recuperato eventualmente dal vostro database).
  • CUSTOMER_FACEBOOK_USERNAME: lo username usato dal vostro utente su Facebook.

La classe java precedente utilizza una classe di utility “MailSender” che, attraverso le librerie javamail, esegue l’invio della mail all’utente.
Il semplice codice della classe “MailSender” esula dallo scopo di questo articolo. Potete trovare un semplice esempio di invio e-mail tramite java a questo indirizzo:
www.tutorialspoint.com/java/java_sending_email.

Pagina web di rigenerazione dell’expiration time (PHP)

Il link inserito nell’ e-mail inviata all’utente tramite la classe java precedentemente descritta, porterà l’utente su Facebook e darà il via alla procedura di rigenerazione dell’access_token.
Il controllo dunque passerà a Facebook che si occuperà eventualmente di fare autenticare l’utente e di redirigelo infine sulla nostra pagina web (la cui url va inserita inserita al posto del valore “YOUR_FACEBOOK_APP_REDIRECT_URI” nel codice precedentemente illustrato).

Quando Facebook richiamerà la YOUR_FACEBOOK_APP_REDIRECT_URI appenderà alla URL i seguenti parametri:

  • access_token: questo è un access token valido il cui periodo di validità è però limitato (“short-lived access token“). Questo primo access token dovrà essere utilizzato nell’ultima richiesta a Facebook per ottenere l’access_token definitivo della durata di 60 giorni (“long-lived access token“).
  • expires_in: i secondi di validità dell’access_token temporaneo appena recuperato.
  • state: il contenuto del parametro “state” utilizzato per costruire il link inviato nella mail dell’utente. Si tratta di un parametro di servizio. Potete settare il valore di questo parametro come meglio credete quando costruite il link. Per mia comodità ho deciso di valorizzarlo con lo username Facebook dell’utente.

Ecco il codice di questa pagina realizzata in PHP in questo esempio:

Pagina web di ricezione del nuovo access_token con expiration time rigenerato a 60 giorni.

La pagina php descritta in precedenza redirige l’utente su un’ultima pagina php “YOUR_LANDING_PAGE.php” il cui compito è quello di scambiare l’access_token temporaneo appena ottenuto (memorizzato nella variabile “temp_token”) con l’access_token “long-lived” che durerà per altri 60 giorni.
Facebook afferma che l’access_token “long-lived” potrebbe coincidere con quello già in nostro possesso. In tal caso semplicemente viene riportato a 60 giorni il suo expiration time.
Il codice dell’ultima pagina è il seguente:

YOUR_FACEBOOK_APP_ID e YOUR_FACEBOOK_CLIENT_SEECRET, come già visto nella classe Java precedentemente descritta, vanno sostituiti rispettivamente con l’”id applicazione / chiave api” e la chiave segreta della vostra applicazione registrata su Facebook.
Il long-lived access_token così ottenuto potrà dunque essere salvato localmente e essere riutilizzato per altri 60 giorni.

A oggi questo è il sistema che reputo più valido in tutti quei casi in cui un’applicazione che non dispone di un’interfaccia utente deve ri-acqisire il Facebook access_token per potere accedere ai dati dell’utente.

Di fatto si tratta di un workaraund che prevede il rilevamento della prossima scadenza dell’access_token in nostro possesso e l’avviso dell’utente interessato che sarà guidato nella procedura di rigenerazione dell’access_token.

Qualcuno ha identificato soluzioni migliori al problema?

Scrivi un commento