Facebook offline_access deprecation: le possibili soluzioni

Postato da regole-seo, in Programmatori (Beyond-SEO), in data 11/06/2012

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

Indice articoli - "Facebook offline_access deprecation: la soluzione"

soluzioni-facebook-offline_access-deprecation

Nell’articolo precedente abbiamo visto quali sono i problemi derivanti della rimozione dell’offline_access token di Facebook e di come questa rimozione rappresenterà un grosso problema per tutte quelle applicazioni che non integrano un browser o che non prevedono la presenza di un utente che possa autenticarsi su Facebook all’occorrenza.

Infatti, anche se solitamente la documentazione delle API di Facebook presuppone la presenza di un utente che stia interagendo con un’applicazione tipicamente per mezzo di un browser o di una mobile app, potrebbero esserci casi in cui questi presupposti non abbiano senso.
Pensate ad esempio a processi schedulati ed eseguiti notte tempo per scaricare i dati da Facebook insight e creare della reportistica ad hoc.
Un altro esempio potrebbe essere quello di un’applicazione in esecuzione in background sulla macchia dell’utente allo scopo di recuperare, ogni giorno, l’elenco aggiornato degli amici dell’utente, controllare quali di questi compiono gli anni e mandare loro gli auguri in modo automatico.

Esempi se ne possono trovare tanti.
Si tratta appunto di applicazioni che non prevedono e soprattutto non necessitano della presenza dell’utente per dover compiere il proprio lavoro. In effetti spesso non dispongono neanche di un’interfaccia utente.

Dunque, poichè come abbiamo visto nell’articolo precedente il nuovo “access_token” di Facebook scade dopo 60 giorni, come possono queste applicazioni continuare a lavorare?

I vari forum dedicati agli sviluppatori sono stati tempestati da moltissime domande relative all’offline_access deprecation di Facebook.
Qui sotto le risposta alle più importanti e frequenti di queste:

  • D: A partire dal 5 Luglio 2012, quando Facebook disattiverà definitivamente la modalità offline access” ormai deprecata, cosa accadrà agli acces_token fino ad oggi utilizzati nelle nostre applicazioni?

    R: Qualsiasi access_token eventualmente memorizzato nella vostra applicazione per poter eseguire l’accesso alle Facebook API anche in assenza di un utente scadrà entro 60 giorni.

  • D: Esiste un modo per aggiornare l’access_token o prolungarne la durata?

    R: Si, esiste ma prevede l’autenticazione dell’utente tramite browser o la realizzazione di un software in grado di replicare l’esatto comportamento di un browser (come vedremo tra poco).

  • D: Cosa succede ad un’applicazione che deve svolgere del lavoro in background, nell’eventualità che l’utente non si autentichi in Facebook per più di 60 giorni?

    R: Non riuscirà più a compiere il suo lavoro poiché dopo la scadenza dell’acces_token, essa non potrà più accedere alle Facebook API.

  • D: Cosa succede, ad esempio, ad un servizio di newsletter che invia agli utenti informazioni utili, nel caso in cui non venga richiesto agli utenti stessi di autenticarsi su Facebook ogni 60 giorni e di visitare la pagina dell’ applicazione per poter rieseguire la procedura di “refresh” dell’access_token?
    R: Il servizio si fermerà dopo 60 giorni… …e probabilmente gli utenti se ne dimenticheranno.

Il “rinnovo” di un access_token può avvenire tramite una procedura che richiede un’autenticazione utente, descritta nella documentazione ufficiale, purtroppo solo in termini di un utente reale che utilizza un browser.

Da nessuna parte è documentata una procedura “programmatica” per eseguire un’autenticazione utente su Facebook.

Le motivazioni sul perché Facebook abbia deprecato la modalità offline access francamente mi sfuggono.
Google, ad esempio, come Facebook utilizza per le sue API il protocollo OAuth 2.0 ma nel suo caso permette alle applicazioni l’accesso offline tramite un valido processo di autenticazione dell’applicazione e dello scambio di opportuni token.

Vediamo dunque quali sono oggi le possibili soluzioni all’offline access deprecation di Facebook:

  • SOLUZIONE 1 – Metodo ufficiale ma solo per applicazioni dotate di browser e interfaccia utente (developers.facebook.com/roadmap/offline-access-removal/).
    Si tratta della soluzione ufficialmente documentata da Facebook e descrive come “migrare” i settaggi della propria applicazione registrata su Facebook per adottare la nuova modalità di accesso alle API. Viene anche fornito l’ “end point” (URL) a cui redirigere l’utente autenticato per rinnovare il tempo di scadenza (expiration time) dell’access_token.
    In risposta all’invocazione di questa URL avrete il nuovo access_token con un nuovo expiration time di 60 giorni. Molto probabilmente (cosa confermata dai miei test) l’access_token ritornato sarà identico a quello precedente con la sola differenza che potrà essere usato per altri 60 giorni.
    Facebook afferma però che l’access_token ritornato potrebbe anche essere diverso, quindi meglio non farci troppo affidamento.
  • SOLUZIONE 2 – “Authentication for Devices”: metodo ufficiale ma solo per pochi fortunati (developers.facebook.com/docs/authentication/devices/).
    Facebook descrive una procedura “Authentication for Devices” che potrebbe permettere ad applicazioni prive di browser di poter accedere alle API aggirando il problema dell’autenticazione utente.
    Purtroppo questa modalità, nata per supportare “dispositivi con limitate periferiche di input” o che “non supportano html” (notate che Facebook proprio pare non essere consapevole che possano esistere applicazioni che operano in bacground), è accessibile solo a un numero ristretto di Partner Facebook e dunque non mi è neanche stato possibile effettaure dei test.
  • SOLUZIONE 3 – Emulare il browser utente nel processo di autenticazione:
    Questa soluzione richiede molto lavoro e una buona competenza tecnica.
    Di fatto, si tratta di emulare in tutto e per tutto il comportamento di un browser per effettuare un’autenticazione dell’utente in modo programmatico e cioè dal codice della vostra applicazione.
    La cosa è particolarmente complessa per chi non ha competenze tecniche adeguate e cercherò qui di descrivere step by step quello che dovreste implementare. Il mio consiglio è quello di usare strumenti di monitoraggio come WebScarab effettuando l’intera procedura dal vostro browser per monitorare tutta la comunicazione HTTP che avviene tra voi e Facebook e poterla replicare dal vostro software.

    • 1) Effettuate una chiamata (GET) dalla vostra applicazione alla URL di oauth/autenticazione:
      https://www.facebook.com/dialog/oauth?client_id=CLIENT_ID_DELLA_VOSTRA_APPLICAZIONE&redirect_uri=REDIRECT_URL_DELLA_VOSTRA_APPLICAZIONE&response_type=token
    • 2) Estraete tutti i cookies ritornati dalla risposta nella “Set-Cookieheader e seguite ogni “locationheaders di redirezione (gestendo lo scambio e l’aggiornamento dei cookie durante tutto il processo).
    • 3) Effettuate lo “scraping” della pagina che viene ritornata, contenente il form di login di Facebook, per recuperarne tutti i campi di input.
    • 4) Sottomettete tramite una chiamata POST i campi identificati (popolandoli con le vostre credenziali) insieme ai cookies identificati nella richiesta del punto 2 e settando correttamente gli headers “referrer” e il “content-type”.
    • 5) Questo step si verifica solo se l’utente con cui vi state autenticando non ha ancora concesso i permessi di accesso alla vostra applicazione. In tal caso Facebook vi restituirà la pagina di richiesta di tali permessi. Effettuate lo “scraping” anche per questa pagina e successivamente la chiamata POST di sottomissione dei dati (sempre avendo cura di settare anche il “referrer” header con la URL da cui la form è stata acquisita).
    • 6) A questo punto occorre seguire le varie headerlocation” di redirect che vengono ritornate a partire dalla POST precedente fino a quando viene ritornata la “redirect url” settata per la vostra applicazione registrata su Facebook.
    • 7) Quest’ultima URL conterrà anche il parametro “access_token” che, fate attenzione, rappresenta un token temporaneo che può essere “scambiato” per un access_tokene valido per 60 giorni effettuando una chiamata GET all’endpoint di OAuth seguente: https://graph.facebook.com/oauth/access_token?client_id= CLIENT_ID_DELLA_VOSTRA_APPLICAZIONE&client_secret= CLIENT_SECRET_DELLA_VOSTRA_APPLICAZIONE&grant_type=fb_exchange_token&fb_exchange_token=ACCESS_TOKEN_TEMPORANEO.
    • In risposta a questa ultima chiamata GET vi verrà ritornato il vostro access_token e il suo expiration time (di 60 giorni) espresso in secondi.

    Si, lo so, non è proprio un gioco da ragazzi :) .
    Anche se riusciste a mettere in piedi questa soluzione (io ci sono riuscito tramite Java dopo circa una settimana di lavoro e studio dello scambio di dati che avviene tra il browser e Facebook al momento del login), io vi sconsiglio altamente di intrapprendere questa strada per almeno due validi motivi.

    • Sostanzialmente si tratta di una hacking di Facebook e non di una soluzione ufficialmente documentata.
    • Non essendo una soluzione ufficiale, di sicuro non verranno pubblicati sulla Facebook roadmap eventuali cambiamenti al sistema di login e voi potreste trovarvi da un giorno all’altro ad avere un software che non funziona più e a dover rifare tutto da capo.
      Cosa racconterete ai vostri clienti?
  • SOLUZIONE 4 – Avvisare preventivamente gli utenti della scadenza imminente del token e fornirgli uno strumento tramite il quale possano rigenerarlo.
    Questa è la soluzione da me adottata e, a mio giudizio, la più idonea anche se, mi rendo conto, potrebbe non essere sempre applicabile.
    Nel mio caso, un processo schedulato, in esecuzione in background, recupera i dati di Facebook insight dalle pagine dei clienti e ne crea della reportistica custom.
    Questo processo ogni volta verifica l’expiration time dell’ access_token legato all’utente e a 10 giorni dalla scadenza gli invia una e-mail contenente le istruzioni per il rinnovo dell’access_token.
    Di fatto, le istruzioni, chiedono all’utente di accedere a Facebook tramite apposito link per rigenerare i permessi di accesso richiamando la URL dell’endpoint di OAuth:

    https://www.facebook.com/dialog/oauth?client_id=CLIENT_ID_DELLA_VOSTRA_APPLICAZIONE&redirect_uri=REDIRECT_URL_DELLA_VOSTRA_APPLICAZIONE&response_type=token

    Questa URL innesca la procedura di rigeneraione dell’ access_token riportandolo poi su una thank you page finale.

    Nel prossimo articolo vi mostrerò un esempio pratico di codice per implementare questa soluzione e ottenere l’estensione dell’expiration time di un access_token.

Escludendo le soluzioni ufficiali, decisamente non utili ad applicazioni non dotate di browser e soprattutto di interfaccia utente, sarete d’accordo con me che gli altri metodi sono in realtà dei workaround.
A oggi però paiono non esistere soluzioni migliori.
Personalmente la cosa non mi stupisce più di tanto. Scusate lo sfogo personale ma in effetti tra tutte le API che sto utilizzando nei miei progetti (Facebook, Google Analytics, Google Adwords, Youtube, iTunes, Magento, Adform ecc.) Facebook è sempre il sistema che crea più grattacapi.

Spero che in futuro le cose migliorino! :)
Se intanto trovate altre soluzioni al problema fatemi sapere!

Scrivi un commento