Da anni mi occupo di software gestionale: in questo ambito la correttezza dell’algoritmo implementato rappresenta la parte più importante del software prodotto.

Quello che voglio dire è che in questo campo specifico elementi come perfomance, bellezza delle UI e architettura impiegata rappresentano fattori assolutamente secondari e trascurabili rispetto alla correttezza e precisione dei risultati prodotti.

Una maschera che permette inserire dei dati contabili può essere bella e funzionale quanto si vuole, nonché essere velocissima e appoggiarsi sull'architettura più estensibile e moderna possibile, ma se capita che in un aggiornamento porti alla situazione in cui un qualsivoglia conteggio previsto dalla faragginosa contabilità italiana risulti essere errato, o anche solo non correttamente arrotondato, allora l’intero software viene considerato una emerita schifezza.

Per questo motivo la gestione dei test del software gestionale prodotto è una procedura che deve sempre essere eseguita con "religiosa" cura: uno sbaglio, seppur minimo, dei calcoli eseguiti è considerato alla stregua di un tradimento.

Nella pratica per realizzare test per tale tipo di software ci si è sempre basati su un approccio misto: parte dei test vengono eseguiti in modo automatico, tramite unit-test, e parte in modo manuale, con l’utilizzo di personale addestrato a trovare, calcolatrice alla mano, i seppur minimi difetti dei calcoli proposti.

La domanda può sembrare banale, ma come si fanno ad ottenere delle informazioni sull’utente (ad esempio lo userid) che si è appena autenticato usando l’IdP ?

La procedura è completamente eseguita per mezzo di chiamate all’SDK del client Azure o anche dell’SDK dell’IdP, e in nessun punto vi è la possibilità di accedere allo userid inserito dall’utente.

Solo usando la client-flow si ha in mano il token rilasciato dall'IdP, che eventualmente può essere utilizzato, sempre con l’ausilio dell’SDK fornito, per prelevare ulteriori informazioni sull’utente.

Questa operazione implica sempre chiamate a servizi esterni, nonchè conoscere molto bene l'SDK dell'IdP utilizzato.

Se invece si usa l'autenticazione server-flow è impossibile accedere al token originario e/o alle informazioni che l’IdP ha sul nostro utente (esempio: la mail).

Per ovviare a questo i servizi Azure Mobile mettono a disposizione un endpoint apposta che restituisce proprio questa informazione.
<URL backend>/.auth/me.

Più in dettaglio interrogando questo endpoint, aggiungendo alla richiesta il token rilasciato dai servizi Azure, verranno restituite le informazioni principali che l’IdP ha sul nostro utente, insieme anche al token originario rilasciato dell’IdP.

Nota molto importante.

Siccome in casi particolari un utente può essersi autenticato ai servizi Azure con l'ausilio di più Idp contemporanemante, usando questo endpoint si hanno indietro tutte le informazioni di tutti gli IdP associato all’utente. Per questo motivo la risposta è una List e non un oggetto singolo.

In questa parte della serie dirò qualcosa sul codice utilizzato per eseguire l'autenticazione client-flow (vedere linkografia): ovviamente affinchè tutto funzioni occorre aver seguito con religiosa cura i passi di configurazione esposti nelle puntate precedenti.

Il codice esposto permette l'autenticazione presso l'IdP Facebook usando il relativo SDK nativo: Xamarin.Facebook.Android.

Prosegue la serie dedicata allo sviluppo di una app che permette di segnalare i migliori posti dove si gusta la vera focaccia genovese.

Oramai la app ha delle caratteristiche di tutto rispetto: offline-sync e gestione autenticazione in modalità server-flow.

Siccome siamo programmatori 8o almeno io tento di esserlo) e per questo non siamo mai contenti, e se non abbiamo rogne ce le andiamo a cercare, ecco che voglio presentarVi le modalità per dotare la app in sviluppo con autenticazione client-flow.

Come detto in precedenza questo tipo di autenticazione si basa sull'SDK nativo messo a disposizione dall'IdP: nel nostro caso Facebook.

Anche in questo caso prima di buttarci nel codice occorre configurare il portale developer di Facebook, in modo da permetterci di usare il relativo SDK.