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".

Sinora nel progetto oggetto di questa serie non abbiamo in alcun modo introdotto alcun tipo di sicurezza: chiunque usi la nostra app è in grado di utilizzarne i servizi senza nessun limite o controllo.

Inoltre per sempicità il campo nome utente che correda ogni post è un semplice campo di testo, dove ognuno può metterci il valore che desidera.

Ovviamente per molti utilizzi questa libertà non rappresenta il comportamento voluto: nel nostro caso occorre che almeno il campo nome utente all'atto di inserimento del post sia riempito in modo sensato e con un minimo di sicurezza in modo da comprendere chi-ha-scritto-cosa.

E' arrivato il momento di parlare di autenticazione e autorizzazione ! Prima però occorre introdurre un minimo di teoria.

Iniziamo con qualche definizione.

L’autenticazione è il processo che permette di identificare l’utilizzatore del software in modo sicuro: cioè identificare in modo certo un nome utente.

Questo processo nel passato veniva svolto escluivamente tramite l’ausilio di una userid e una password: il concetto che sottende questo tipo di autenticazione è che solo chi conosce la relativa password è in grado di sostenere di essere realmente l’utente specificato.

Ho già parlato nella quinta parte di questa serie della gestione della concorrenza, introducendo la teoria che sottende l'optimistc concorrency così come implementato dall'SDK Azure Mobile, ed esposto aluni codici pratici per gestire la problematica .

In questo momento, però, si sta parlando dell'offline-sync: in tale contesto vedremo che le cose, seppur simili a quanto visto in precedenza, sono giocoforza un pò più complicate.

Inziamo con il dire che per rilevare le modifiche concorrenti la tecnica dall'SDK è sempre la stessa: utilizzo della colonna version (...squadra vincente non si cambia, no ?).

Però nell'online-sync ogni singolo salvataggio viene sottoposto al backend, e quindi l'eventuale gestione della modifica concorrente avviene sul singolo record oggetto del salvataggio.

Nell'offline-sync, invece, a fronte di un singolo push (implicit o meno) si possono sottoporre al backend un numero imprecisato di record modificati, che magari insistono su più tabelle.

Per questo motivo in questo in questo caso potrebbe essere necessario gestire le modifiche concorrenti di più di un record oggetto dell'operazione di push.

Rammento che il push nell'offline-sync sottopone tutte le modifiche avvenute sul database locale SqLite al backend per la loro persistenza sulla base dati remota con lo stesso ordine con cui queste sono avvenute, e richiamando i vari metodi dei controller coinvolti, semplicemente invocando il metodo PushAsync dell'oggetto SyncContext.

Per questo motivo nel caso dell'offline-sync l'SDK Azure Mobile Client mette a disposizione una gestione più articolata della concorrenza, anche se i principi ispiratori sono assolutamente analoghi a quanto già visto.

Aggiungo anche che lavorare con offline-sync sicuramente introduce maggiori probabilità di avere modifiche concorrenti, e un'applicatvo reale dovrebbe poter gestire questa parte in modo preciso e dettagliato sopratutto quando sono coinvolte più tabelle che magari hanno relazioni semantiche tra esse.

Nel seguito un primo esempio di codice utilizzato per gestire i problemi relativi alla concorrenza.