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 non siamo mai contenti e se non abbiamo rogne ce le andiamo a cercare, ecco che voglio presentarVi le modalità per dotare la app 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.

Qualche giorno fa sono andato a trovare un mio grande amico, che mi ha accolto indossando la maglietta in figura.

Ho subito capito che aveva indossatto la maglietta in mio onore, poichè la scritta era celebrativa per la serie che stavo scrivendo, e di cui questo post fa parte.

Evidentemente l'occhiata cui faceva riferimento era alle configurazioni introdotte sui servizi Azure Mobile, e di cui ho parlato nei post precedenti.

Il mio amico dapprima ha negato la connessione tra la mia serie e la sua maglietta, ma poi, dopo alcune mie insistenze, ha confermato le mie supposizioni.

Non ho capito molto il referimento al ginecologo, ma lo stesso amico mi ha assicurato che mi avrebbe spiegato nei prossimi giorni.

Per questo motivo ho pensato di mettere la foto che ritrae la sua bellissima T-Shirt: ho anche deciso di parlarne qui per sfatare il falso mito che chi si occupa di informatica non capisce mai le battute o le frasi spiritose !

Non la si fa a Giampaolo TUCCI !

Premesso questo fatto buttiamoci nella parte finale dell'autenticazione server-flow.

Quando ho esposto la configurazione all'interno del portale Azure per l'autenticazione in analisi avevo detto che avrei discusso del campo Allowed External Redirect URLs.

L'autenticazione server-flow con l'utilizzo dell'SDK Azure Mobile Client richiede che si definisca un nuovo URL Schema nonchè un host per la nostra app. L'URL Schema sono quei caratteri prima dell'indirizzo in un URL.

<URL Schema>://<Host>

L'utilizzo è quello di permettere il redirect dei servzi Azure al device (step 4 autenticazione server-flow - vedi post precedenti).

Dopo aver configurato il servizio backend in Azure è possibile proseguire nella costruzione della app aggiungendo l'autenticazione. Il codice lo trovate in linkografia.

Iniziamo a vedere che nella classe delegata a chiaccherare con il backend Azureè stato aggiunto un metodo che server per eseguire il login.

public Task LoginAsync()
{

	var loginProvider = DependencyService.Get(<ILoginProvider>);
	return loginProvider.LoginAsync(client);
}

In questo post esporrò come implementare la funzionalità di autenticazione di tipo server-flow usando come identity provider nientemeno che Facebook.

Occorre dire che se si vuole usare un IdP tra quelli supportati da Azure il processo di configurazione è praticamente uguale per tutti.

> Accedere alla console developer dell’IdP scelto

> Creare una nuova App e abilitare l’utilizzo dell’autenticazione Oauth

> Configurare la parte impostando l’URL del redirect del mobile app service di Azure e quindi prelevare gli identificativi proposti (App Id e App Secret) e che saranno usati da Azure per verificare la correttezza dei dati ricevuti dall’IdP.

> Accedere al portale Azure Impostare i dati sopra ottenuti dall’IdP nel Mobile App service.

Proteggere i controller del backend da accessi non autenticati (attributo [Authorize])

Sembra un bel casino, ma vedrete che è una passeggiata di salute !

Rimarco nuovamente che qui useremo Facebook come identity provider, ma il processo è assolutamente analogo per gli altri IdP supportati in Azure.

Per accedere al portale developer di facebook usare il link in llinkografia, e quindi selezionare nuova app "Add New App".