Facebook offline_access deprecation: dove sta il problema e chi ne sarà coinvolto?

Postato da regole-seo, in Programmatori (Beyond-SEO), in data 20/05/2012

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

Indice articoli - "Facebook offline_access deprecation: la soluzione"

Facebook-offline-access-deprecation

Chi ha a che fare con le API di Facebook, di questi ultimi tempi avrà qualche fastidiosa preoccupazione relative a ciò che accadrà successivamente alla rimozione dell’”offline access permission”.

In questo articolo, suddiviso in più parti, cercheremo di capire quali sono le implicazioni di questa rimozione, quali alternative abbiamo per aggirare il problema e individueremo i rari ma concreti casi per cui ora pare non esserci una soluzione.

Riassumendo, la modalità “offline access permission” dava la possibilità ad un’applicazione di potersi interfacciare con le API di Facebook anche qualora l’utente coinvolto nell’azione non fosse autenticato in Facebook.

In questo modo, tramite l’utilizzo di uno speciale “token” (stringa alfanumerica) chiamato “offline access token”, da utilizzare nelle invocazioni delle Facebook API, anche le applicazioni esterne al contesto web, quali ad esempio desktop application oppure applicazioni in esecuzione in background potevano compiere qualsiasi tipologia di azione utilizzando le API anche senza la presenza fisica dell’utente davanti al browser e senza conoscere le credenziali dello stesso utente.

Bene. Come segnalato sulla Facebook developer roadmap, dal 2 maggio 2012 l’ offline_access permission è stata deprecata e su tutte le applicazioni registrate in Facebook è stata abilitata la modalità “migrazione” per questo tipo di accesso che renderà il vostro offline access token non più valido.
Se la cosa crea problemi alla vostra applicazione potrete disabilitare questa modalità e tornare alla situazione precedente.
ATTENZIONE però: il 3 ottobre 2012 tale modalità sarà abilitata definitivamente per tutte le applicazioni e non più disattivabile.

La pagina di Facebook “Removal of offline_access permission” dedicata a questa migrazione spiega come è possibile passare alla nuova modalità e descrive un porcesso con cui recuperare una nuova tipologia di token valido per 60 giorni e che può essere rinnovato qualora stia per scadere o sia già scaduto.

Detto questo, in prima analisi, ognuno di noi potrebbe pensare:
“avere un token che può essere rinnovato quando si desidera equivale ad avere un token che non scade e probabilmente devo solo modificare la mia applicazione per rigenerare questo token ogni 60 giorni.”

Anche se nella maggior parte dei casi di interazione tra web application e Facebook la risposta a questa intuizione potrebbe essere “certo che si!!!”, una spada di Damocle si abbatterà su tutte le applicazioni che non prevedono la presenza di un utente che possa autenticarsi su Facebbok quando il token è in scadenza.

Si, infatti il processo di rigenerazione (o meglio di estensione di validità) del token descritto da Facebook può essere attivato solo se l’utente coinvolto nell’azione invocata sulle API è autenticato in Facebook (o comunque si trova davanti ad un browser e ha la possibilità di autenticarsi).

Dunque che ne sarà di tutte quelle applicazioni che non integrano un browser?
Che ne sarà di tutti quei processi attivi in background che magari dovevano pubblicare sulla bacheca utente delle news a intervalli prestabiliti piuttosto che semplicemente effettuare le opportune interrogazioni per creare della reportistica utilizzando i dati insight delle pagine Facebook dell’utente?

Queste applicazioni potevano fino ad ora contare sull’“offline access token” che, non avendo scadenza, poteva essere memorizzato localmente e riutilizzato all’occorrenza.

La frase che troviamo nella pagina “Removal of offline_access permission” di Facebook è estremamente chiara e lapidaria:
“…desktop applications will automatically get user access_tokens returned that have the longer expiration time. However, there is no way to get a long-lived user access_token without having the user login to your app again.

Pertanto questo tipo di applicazioni, non avranno possibilità di rinnovare il token se non tramite il login dell’utente su Facebook.
Peccato che in nessun modo (pur essendo in possesso delle credenziali) Facebook documenta come sia possibile eseguire un login utente in modo programmatico cioè esclusivamente tramite chiamate alle API da parte dalla nostra applicazione e senza dunque la necessità dell’intervento umano dell’utente.

Anche sull’autorevolissimo sito “stackoverflow.com” si è molto parlato di questo argomento e solo a titolo simbolico cito un’altra frase comparsa in una risposta che non lascia spazio a speranze:
“Since a web browser needs to be involved for the actual authorization, there is no such thing as a “standalone script” that does it all.”

Anche se Facebook non lo documenta, di fatto una soluzione per autenticare un utente in modo programmatico esiste. Consistebbe nel simulare in tutto e per tutto il comportamento del browser dall’interno della nostra applicazione a partire dal submit delle credenziali, la gestione dei redirect e dello scambio di cookie.

Nel prossimo articolo dedicato alle possibili soluzioni al problema dell’offline_access deprecation di Facebook accennerò a questa soluzione anche se mi sento di sconsigliare caldamente questa via se desiderate creare un software robusto e indipendente da eventuali modifiche fatte da Facebook che possano da un momento all’altro rendere inutile i vostri sforzi.

Scrivi un commento