Dopo aver introdotto i concetti generali e aver impostato la struttura dell'applicazione, vediamo in questa seconda parte i dettagli implementativi per poter usufruire del provider Google per autenticare gli utenti del nostro sito web.
Login.aspx
La pagina di login è estremamente essenziale e contiene solo un pulsante per effettuare il login. Vediamo il code behind:
La prima operazione che si effettua è quella di recuperare l'end-point corretto a cui chiedere il servizio di autenticazione. La URL di partenza come vediamo è https://www.google.com/accounts/o8/id e successivamente ci avvaliamo della classe OID_OAUTH_Helper che ci recupera l'end-point già sotto forma di URL. La risposta che ci fornisce Google per restituirci l'end-point è un file XSDR nella seguente forma:
con XPath recuperiamo il valore del tag <URI> e a quell'indirizzo andremo finalmente a chiedere di autenticarci l'utente. Finora tutto liscio. Il bello viene ora perchè vediamo quale URL dobbiamo creare per poter mettere in moto tutto il meccanismo. La URL è quella presente nel tag <URI>. Questa da sola ovviamente non basta. Infatti dobbiamo costruire una query string adeguata alle nostre esigenze. In particolare dopo la URL inseriremo il carattre '?' e una serie di parametri per indicare qual'è il nostro dominio (nel nostro caso semplicemente localhost), la modalità con cui chiediamo i dettagli, l'ID di cui abbiamo bisogno, l'eventuale email di Google,lo username con cui ha fatto logon, il language di riferimento, la pagina a cui reindirizzare l'utente dopo che il logon ha avuto successo ed altri parametri che possono essere reperiti (non con poca difficoltà) direttamente dal link Google in cui viene spiegato il significato di ALCUNI parametri (purtroppo non tutti). Dopo aver creato la nostra URL proviamo a vedere qual'è la risposta di Google alla nostra richiesta:
Questa in teoria dovrebbe essere la risposta da ritornare al client con un codice HTTP 302. Il codice HTTP 302 significa: caro client, la risorsa l'ho trovata,ma guarda che non è alla url da te indicata, ma nella URL che ti indico nello Header Location. Quindi se davvero vuoi la risorsa devi rivolgerti a quella URL. In parole povere si causa un redirect che il client effettuerà senza disobbedire. Ho detto in teoria perchè in pratica se facciamo un redirect con la URL tornata da Google, otteniamo nient'altro che un servizio negato! Il motivo? dopo un miliardo e mezzo di prove si scopre che i parametri 'continue' e 'followup' devono essere soggetti a funzione di Encode Url altrimenti Google non riconosce nulla. Via peresempio il carattere '=' e il carattere '&', ma solo nel valore del parametro continue e all'interno del valore del parametro 'followup'. Il resto va lasciato così com'è. Per fare questo ci avvaliamo della funzione NormalizeResponseURI che effettua tutto questo. A questo punto siamo pronti per ritornare al client una risposta '302' affinchè lui possa fare un redirect e raggiungere la pagina di login di Google:
Finalmente! Il nostro utente adesso se la vede direttamente con Google. Attenzione! Dice Google al nostro utente: qualcuno (Localhost in questo caso) sta chiedendo delle informazioni sul vostro conto (mail. language ed altro).Per poter autorizzare questo qualcuno occorre accedere con le tue credenziali Google così potrai scegliere che cosa fare. Appena le credenziali di accesso permetteranno di entrare nel proprio account, all'utente verrà chiesto di autorizzare le informazioni da passare al nostro sito:
L'utente ha la possibilità di autorizzare l'accesso a queste informazioni, oppure di non autorizzare il nostro sito. Se l'utente decide di autorizzare allora viene reindirizzato alla pagina Bridge che abbiamo scelto essere la pagina di arrivo dopo il logon e in cui si è pensato di inserire la logica di aggancio tra lo username Google e l'utente della nostra applicazione web. La pagina Bridge l'abbiamo inserita per una questione di semplicità in modo tale che ciascuna pagina avesse il suo compito ben preciso. Nulla vieta di effettuare tutte queste operazioni nella pagina di Login
Se l'utente ancora non si è autenticato sul nostro sito,andiamo a recuperare le informazioni restituiteci da Google le quali, confrontate con quelle sol nostro DB ci permetteranno di dire che l'utente è o meno un utente riuconosciuto nel nostro sito. Se è tutto ok lo reindirizziamo a nostra volta alla pagina Home della porzione reserved del nostro sito. La cosa fondamentale da fare è questa: se l'utente è riconosciuto valido da Google e da noi, creiamo l'associazione sul DB e poi creiamo tramite la chiamata a FromsAuthentication.SetAuthCookie un cookie che sarà associato allo username che avrà fatto logon e potrà pertanto godere dei benefici dell'autenticazione Windows Form, proprio come se l'appartenenza o meno all'insieme degli utenti autorizzati fosse effettuata dal nostro sito direttamente e non da Google.
Da notare come i dati che ci interessano si trovino nei parametri della request
string identity_url = request.Params["openid.claimed_id"];
string email = request.Params["openid.ext1.value.email"];
Subscribe