Questo post è stato scritto da Gian Maria Ricci, MVP Visual Studio ALM

Gestione conflitti in sistemi centralizzati

I conflitti possono accadere in entrambe le tipologie di VCS (Version Control Systems), sia in quello centralizzato sia in quello distribuito, è comunque interessante capire a fondo come i vari sistemi riescano ad identificarli per permetterne la risoluzione.

Nel source control standard di Team Foundation Server i conflitti vengono rilevati sia durante la fase di Check-In, sia durante la fase di Get-Latest. Durante un Get-Latest infatti, per ogni file modificato nel server e che viene quindi scaricato per aggiornare la versione locale, Visual Studio verifica se il file ha modifiche pendenti ed in caso affermativo si ha un conflitto, poiché il file è stato modificato da due distinte parti.

In caso di conflitto Visual Studio cerca di capire se è possibile effettuare un merge automatico delle modifiche, senza richiedere dunque l'intervento manuale dell'utente. Questo accade ad esempio se le modifiche riguardano parti differenti di un file.

Nel caso non sia possibile procedere ad un merge automatico, lo sviluppatore viene notificato e si procede ad effettuare un merge manuale utilizzando Visual Studio o altri strumenti equivalenti. Come nota si consiglia comunque di controllare sempre dopo il Get-Latest se sono state scaricate nuove modifiche ed in caso affermativo, anche se non vi sono conflitti, è sempre buona norma rieseguire gli Unit Test per vedere se le modifiche scaricate sono compatibili con le modifiche pendenti locali.

Durante un check-in la situazione è invece leggermente differente; si supponga infatti che Marco abbia fatto un Get-Latest recuperando il changeset con id 100 ed inizi a lavorare su di un file. Nel frattempo Giorgio modifica lo stesso file effettuando Check-In e creando quindi un changeset con id superiore, supponiamo il 101. Per correttezza Marco dovrebbe sempre effettuare un Get-Latest e risolvere eventuali conflitti prima di tentare un check-in; supponiamo invece che utilizzi la procedura meno corretta e tenti di effettuare direttamente il check-in senza curarsi di eseguire un Get-Latest.

In questo caso durante le operazioni di check-in, per ogni file viene associato il numero di versione che tale file aveva nel workspace locale quando sono iniziate le modifiche, nel nostro esempio 100. Il server verifica quindi la versione attuale del file (in questo caso la 101 perché è stato modificato da Giorgio), e se le due versioni non corrispondono il file è stato modificato da entrambi. Anche in questo caso è possibile che le modifiche possano essere risolte da un automerge, ma in caso non siano compatibili, il check-in viene bloccato.

Questo blocco è fondamentale, perché se non ci fosse Marco avrebbe erroneamente sovrascritto ed annullato le modifiche di Giorgio. Quando il check-in viene bloccato, si rende necessario procedere ad un Get-Latest e risolvere i conflitti localmente prima di tentare nuovamente un check-in.

Gestioni conflitti in git

In un sistema distribuito la gestione dei conflitti è molto simile, ma complicata dal concetto di commit locale. In questo scenario di esempio si hanno due utenti: Gian Maria Ricci ed alkampferOutook, i quali possono modificare entrambi lo stesso file e fare commit in locale contemporaneamente. Questo accade perché il commit è locale, ogni sviluppatore ha una linea di codice composta dai suoi commit e quindi nessun conflitto si genera se due sviluppatori modificano e fanno commit di uno stesso file. Si supponga che entrambi gli sviluppatori abbiano fatto un clone di un repository, costituito per ora da un singolo commit con id 202396b ed abbiano fatto alcune modifiche creando ognuno due commit nel proprio repository locale.

NOTA: Nella descrizione seguente, ogni qualvolta si parla di origin si intende implicitamente il server remoto predefinito collegato al repository locale, che di base è il server da cui si è effettuato il clone. Data la sua natura distribuita, è possibile che il proprio repository locale Git si sincronizzi con più server (detti remote) e quindi la dicitura server può risultare ambigua, non esistendo di fatto il concetto di un unico server centralizzato.

Sebbene non si sia ancora parlato di branch, per ora si consideri semplicemente che q uando si effettua il primo commit in un repository Git, viene automaticamente creata una prima branch chiamata master che costituisce l'unica branch attiva.

Quando Gian Maria Ricci tenta di effettuare il push verso il server origin, git non fa altro che verificare la posizione della branch corrispondente nel sistema destinazione e se non ci sono stati cambiamenti dall'ultima volta che è stato fatto pull esegue un fast-forward, ovvero copia semplicemente i commit nel sistema destinazione.

Quello che accade in dettaglio è: quando uno sviluppatore effettua un pull (o il clone iniziale), tutti i commit del sistema remoto vengono scaricati nel repository locale, cosi che i due repository siano perfettamente allineati ed identici (nei sistemi distribuiti infatti ogni sviluppatore ha una copia completa del repository). Quando uno sviluppatore effettua commit locali, questi vengono aggiunti sequenzialmente alla branch attiva ed ognuno ha un id (costituito da un hash SHA1), come si può vedere con un git logf. (il comando logf non è altro che un alias creato con l'istruzione git config --global alias.logf "log --graph --oneline --all --decorate")

Il dato interessante è dato dalla colorazione, che identifica in maniera univoca la situazione del repository. In primo luogo, in verde, è mostrata la branch attiva locale; la master è attualmente pari alla HEAD (è infatti l'unica branch ed è quella attiva), ed è associata all'ultimo commit con hash ca9fd1e. La mast er remota, ovvero quella del TF Service, è invece mostrata in rosso ed è chiamata origin/master ad indicare appunto che è la branch master del remote chiamato origin. Avendo effettuato due commit, la branch master locale è due commit più avanti della master remota, che invece è ferma al 202396b. L'operazione di push non fa altro che tentare di inviare i due commit locali al server e se nel frattempo nessuno ha effettuato operazioni di push, questi commit locali vengono semplicemente copiati nel server.

Effettuando di nuovo un log da riga di comando si può notare come ora la origin/master sia allineata alla master locale, ed i due commit sono stati correttamente copiati nel server.

Supponiamo ora che l'altro sviluppatore (AlkampferOutlook) abbia anche lui effettuato due commit e tenti di effettuare l'operazione di push. In questo caso i due commit sono sempre successivi al commit 202396b, ma nel frattempo la branch master del server è stata aggiornata ed ora punta al commit c a9fd1e. In questo caso l'operazione viene fermata, dato che non è più possibile effettuare il fast-forward; AlkampferOutlook deve quindi effettuare il merge con le modifiche che nel frattempo sono state inviate da Gian Maria Ricci. L'interfaccia suggerisce quindi di effettuare un pull (operazione analoga al get-latest) ed effettuare la merge in locale.

Tentando il push da command line il messaggio è molto più esplicito

Fetch, pull e risoluzione di conflitti in locale

La soluzione al conflitto è fare un pull, ma prima di procedere in questa direzione è preferibile entrare più a fondo nel funzionamento di git per comprendere più in dettaglio cosa accade durante questa operazione.

Una volta che il suo tentativo di Push è stato rigettato, AlkampferOutlook può effettuare un log a riga di comando per capire lo stato del suo repository.

La situazione è esattamente omologa a quella vista da Gian Maria Ricci precedentemente, ovvero la master locale è due commit più avanti della branch remota, ma questa informazione è purtroppo oramai obsoleta, perché nel frattempo Gian Maria Ricci ha fatto push sulla master remota. Per aggiornare la situazione del repository locale e scaricare i commit che nel frattempo sono stati aggiunti al server è necessario usare il comando fetch (git fetch)

Questo comando contatta il server remoto, scaricando le eventuali modifiche effettuate dall'ultimo aggiornamento. Visual Studio ha il vantaggio di mostrare una comoda visualizzazione grafica di quello che è cambiato dopo che viene effettuato il fetch

Dall'immagine precedente è immediatamente chiaro che Gian Maria Ricci ha fatto due commit rispetto il nostro ultimo aggiornamento ed è necessario dunque procedere ad un merge.

La stessa visualizzazione si può avere in command line:

In questo caso è leggermente più difficile comprendere cosa sia successo, ma la rappresentazione grafica premette comunque di capire che la branch master locale è partita dal commit 202396b, ed è evoluta con due commit (806c743 e d9f7cc7), mentre la origin/master, partita anche essa dal commit 202396b è ora evoluta con altri due commit (8374733 e ca9fd1e) che sono stati effettuati da Gian Maria Ricci.

Un tool utile per familiarizzare con questi concetti ed avere una chiara visualizzazione è stato scritto da Phil Haack e permette di avere una visualizzazione grafica del proprio repository, in maniera analoga alle varie immagini che si vedono sui tutorial o libri su Git. Il tool si chiama SeeGit ed è possibile trovarlo qui (http://haacked.github.io/SeeGit/)

Se invece si vuole una visualizzazione grafica veramente completa è possibile utilizzare un altro tool completamente gratuito chiamato SourceTree, il quale permette di gestire un repository Git o Mercurial fornendo una interfaccia molto intuitiva e che permette facilmente di visualizzare le differenze tra i file.

A discapito del tool utilizzato, una volta effettuat o il fetch, è necessario procedere al merge tra le proprie modifiche e quelle appena scaricate con il comando

git merge origin/master

Questo comando non fa altro che effettuare una merge tra la branch locale correntemente attiva (la master in questo caso) e la origin/master. Se non vi sono conflitti, ovvero le modifiche nei vari commit non riguardano le stesse porzioni di file, il merge viene eseguito in maniera automatica e lo sviluppatore dovrà quindi procedere alla verifica del merge stesso, in maniera analoga a quello che si fa dopo un merge su un VCS centralizzato.

Le operazioni di fetch e merge sono comuni per allineare la propria branch con quella di un server di upstream, per cui in git è presente il comando pull che effettua entrambi i comandi in uno. In Visual Studio infatti abbiamo la possibilità di effettuare il fetch o direttamente il pull. Sia che venga fatto a riga di comando o da Visual Studio o con qualsiasi altro tool questa è la situazione che si ha dopo un fetch+merge (o pull)

La situazione è ancora più chiara utilizzando l'utility di Phil Haack.

Dato che ogni sviluppatore possiede un repository locale, è molto comune la situazione in cui, partendo da un singolo commit, si abbia la divergenza con più linee di codice, una sviluppata in locale e l'altra in uno dei remote con cui si sta lavorando. In questo caso quindi il commit 140f00a8 ha due commit padri, perché costituisce la merge dei due distinti rami di codice che si sono generati dal primo commit 202396b4. A tutti gli effetti quindi quando avvengono conflitti quello che si fa è fare un merge della branch locale con la corrispondente branch remota che è stata portata in locale con il comando fetch.

Una volta che la correttezza del merge è stata verificata (Unit Test e/o verifica manuale), è possibile effettuare il push. Se nel frattempo nessuno ha inviato altri commit, i tre commit (i due effettuati in locale ed il risultato della merge) verranno inviati al server, altrimenti sarà necessario procedere nuovamente ad un nuovo pull.

Risoluzione di conflitti all'interno di Visual Studio

Naturalmente è possibile che entrambi gli sviluppatori abbiano modificato lo stesso file, in questo caso durante il merge git notificherà l'utente della presenza di uno o più conflitti.

La comodità di uno strumento grafico come Visual Studio è capire con facilità tutti i file che hanno attualmente generato conflitti ed avere quindi un quadro preciso della situazione. È comunque possibile utilizzare la command line anche per le operazioni di merge, dato che gli eventuali conflitti vengono comunque risolti con un tool visuale, lanciato in automatico dalla command line stessa.

In questo caso il conflitto è su un singolo file, è possibile premere sul link Compare Files per lanciare il compare tools di Visual Studio e capire cosa è cambiato.

Di base però si preme il bottone Merge e si gestiscono i conflitti direttamente da Visual Studio

Se avete installato precedente mente msysgit o i tool di GitHub è possibile che premendo il bottone Merge vi si apra il KDiff3 o qualche altro strumento di risoluzione conflitti. Questo accade perché git memorizza nelle configurazioni gli strumenti da usare per il compare e la risoluzione di conflitti, in modo che possano essere lanciati durante il merge da command line. Dato che il plugin per git integrato in Visual Studio preserva le configurazioni, se nel config è indicato di usare kdiff3, Visual Studio onora la configurazione e non usa il suo strumento integrato. Per risolvere questo problema ed usare Visual Studio è possibile editare direttamente il file di configurazione di git locale o globale inserendo questa configurazione

[diff]

      tool = vsdiffmerge

[difftool]

      prompt = true

[difftool "vsdiffmerge"]

      cmd = \"C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Common7\\IDE\\vsdiffmerge.exe\" \"$LOCAL\" \"$REMOTE\" //t

      keepbackup = false

      trustexistcode = true

[merge]

      tool = vsdiffmerge

[mergetool]

      prompt = true

[mergetool "vsdiffmerge"]

      cmd = \"C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Common7\\IDE\\vsdiffmerge.exe\" \"$REMOTE\" \"$LOCAL\" \"$BASE\" \"$MERGED\" //m

keepbackup = false

      trustexistcode = true

Il file di configurazione locale si chiama config ed è nella cartella .git del repository locale, mentre il file di configurazione globale per l'utente si chiama .gitconfig ed è nella cartella di profilo dell'utente c:\users\nomeutente. Entrambi sono file di testo che possono essere editati senza problemi. Localizzate le eventuali sezioni già presenti (quelle tra parentesi quadre) e sostituitele con quelle mostrate sopra

Se non è stato configurato nessuno strumento, Visual Studio di default utilizza i suoi strumenti integrati.

Indipendentemente dallo strumento utilizzato per la risoluzione dei conflitti, una volta che tutti sono stati risolti, i file risultano modificati e debbono quindi essere committati nel repository locale prima di poter effettuare il push verso il server remoto. Nella figura sottostante è infatti rappresentata la situazione in cui ho due commit da inviare al remote, il primo è il commit che ha generato conflitto, il secondo è quello che risolve il conflitto.

Questo post è stato scritto da Giancarlo Lelli (@itsonlyGianca), Microsoft Student Partner di Cagliari.

In questo articolo vedremo come implementare un’autenticazione SMS nelle nostre app Windows Store, ovvero come Windows 8 permette questo tipo di procedura, quali sono le classi che permettono di interfacciarsi ad un dispositivo mobile broadband e soprattutto i prerequisiti hardware e a livello di ambiente di sviluppo necessari per usufruire di tutte le potenzialità di questo particolare metodo di autenticazione.

Prefazione

Prima di addentrarci nell’argomento preciso che le procedure riportate in questo articolo non si possono applicare a coloro cha hanno intenzione di sviluppare app per operatori di telefonia mobile, ma solamente a coloro che vogliono utilizzare all’interno della loro field application (per cui mi riferisco a coloro che svilupperanno app del tipo LOB) questo tipo di layer di sicurezza. Gli esempi di codice forniti in questi articolo saranno in C#

Background

Il supporto alla tecnologia mobile broadband non è qualcosa di nuovo al dir la verità, infatti era già presente ai tempi di Windows 7, tuttavia la maniera in cui poteva essere utilizzata risultava piuttosto problematica, dovuta alla necessità di installare software e driver di terze parti per rendere operativo il nostro mobile broadband device. In Windows 8 queste problematiche sono state risolte, introducendo delle funzionalità che ad oggi permettono all’ utente di avere un esperienza utente sempre connessa, permettendo di considerare le connessioni a consumo come qualcosa (in certi casi) analogo al Wi-Fi. A questo proposito è stato fatto un lavoro di re- ingegnerizzazione dello stack di wireless networking che ha portato una serie di interessanti novità, due delle principali sono:

Introduzione del Mobile Broadband Interface Model (MBIM) ovvero sia una nuova specifica hardware che i produttori potranno adottare nei loro dispositivi garantendo così un hardware experience di gran lunga superiore a quella a cui eravamo abituati. Infatti all’ interno di Windows 8 la specifica MBIM viene fornita come qualcosa out of the box, ovvero già nativamente supportata, infatti il class driver che è destinato a supportare questo particolare tipo di device è già nativamente disponibile all’ interno del SO, quello che dobbiamo fare noi è semplicemente connettere il dispositivo al nostro pc/tablet, senza nemmeno preoccuparci di eventuali aggiornamenti perché è tutto gestito da Windows Update.

Introduzione di due nuovi namespace strettamente collegati:

· Windows.Device.Sms: che espone classi e metodi gestiti e fruibili da tutti i linguaggi supportati da WinRT per interfacciarsi ai dispositivi mobile broadband connessi al nostro pc/tablet.

· Windows.Networking.Connectivity: permette di ottenere informazioni sulla connettività, l’uso e il piano dati per la connessione a consumo attiva. I dati ottenuti tramite questi metodi possono essere usati per evitare il cosiddetto bill-shock, ovvero costi superiori al normale dovuti a sfori sul piano dati.

In questo articolo ci concentreremo soprattutto sul primo del due namespace illustrati sopra.

Windows.Device.Sms – Features

Le funzionalità messe a disposizione a noi developer da questo namespace sono innumerevoli, le principali, e quelle che consumeremo noi negli esempi di questo articolo sono elencato di seguito:

· Invio e ricezione di SMS in formato di testo

· Interfacciamento con il dispositivo mobile broadband

· Letture, scrittura e cancellazione di sms dal message store (memoria della sia card)

· Enumerazioni di tutti i dispositivi mobile broadband connessi

· Nuovo event trigger per background task

Ovviamente molti dei metodi di questo spazio dei nomi rispettano la filosofia asincrona di Windows 8 perciò supportano pienamente le due nuove keyword async/await, tuttavia alcune operazioni sono ancora collegate al vecchio concetto di callback associati ad un evento, a questo proposito mi riferisco agli eventi che riguardano la ricezione di un nuovo SMS e al cambiamento di stato del nostro mobile broadband device.

Per facilitare l’integrazione di un app mobile broadband con il sistema operativo è stato introdotto anche un nuovo event trigger che potrà essere usato nella definizione di nuovi background task per permettere ad un app la cui funzione è strettamente di messaggistica di potersi svegliare qualora venga ricevuto un sms, sganciandosi così dal vincolo dei callback che ovviamente vengono eseguiti solo quando l’app è in esecuzione.

Operazioni preliminari

Prima di buttarci nei meandri di Visual Studio ci sono alcuni step preliminari da eseguire, che permettono alla nostra app di avere i privilegi di accesso al MB device, ovvero, definire il metadata package per il nostro dispositivo MB e impostare le capabilities nella nostra solution di VS2012.

I requisiti software sono i seguenti:

· PC con Windows 8 (preferibilmente Pro) installato

· Visual Studio 2012

· Windows Driver Kit installato

I requisiti hardware invece:

· Dispositivo mobile broadband che sfrutta lo standard MBIM collegato al pc/tablet. [List]

Completati questi step strettamente preparatori, la prima cosa che dobbiamo fare (se non lo abbiamo già fatto) è collegare il nostro MB device al nostro pc/tablet. Non appena il device verrà collegato, il sistema operativo riconoscerà che si tratta di un dispositivo che sfrutta il MBIM e quindi attraverso il Device Metadata Retrieval Client (DMRC) controllerà in primis che all’interno del nostro computer non ci sia già un metadata package relativo a quella periferica (device metadata cache – device metadata store), qualora non esistesse o ha bisogno di essere aggiornato il DMRC farà una query al Windows Metadata and Internet Services website (WMIS) per determinare l’esistenza di un package per tale dispositivo, qualora esistesse il DMRC lo scarica lo scompatta e lo memorizza all’ interno della cartella che contiene la cache dei metadati. (%PROGRAMDATA%\Microsoft\Windows\DeviceMetadataStore\). Arrivati a questo punto possiamo aprire VS2012, subito noteremo che nella barra dei menù è apparsa una nuova voce ovvero “Drivers”. Navighiamo come mostra la figura uno sino ad arrivare al menù relativo ai MB device metadata.

Una volta aperto quel menù ci ritroveremo davanti il wizard per l’authoring di service metadata, noi per comodità sceglieremo di modificarne uno già esistente (quello scaricato dal DMRC) e una volta che verrà aperto muoviamoci nella scheda “Applications” e andiamo a riempire i campi raggruppati nelle sezioni Metro Style device app e privileged application. Una volta fatto andiamo nella scheda finish e salviamo il newly edited package sostituendolo a quello già esistente. Con questa procedura abbiamo aggiunto la nostra app alla whitelist di tale dispositivo. Una feature collegata ai metadata package è la possibilità di specificare degli URL di app già nello store di modo che una, volta fatto il deploy del pacchetto, quando verrà connesso un dispositivo qualsiasi che abbia dei metadati già definiti, Windows 8 scaricherà automaticamente l’app indicata dallo store.

Il prossimo step sta nel definire le capabilities nella nostra solution di VS2012, questo step è abbastanza banale ma leggermente diverso da quello a cui siamo abituati poiché il file *.appxmanifest non permette l’aggiunta di tale feature tramite interfaccia grafica. Per cui dovremmo aprire tale file in modalità di testo e inserire il seguente codice:

Adesso siamo pronti a sviluppare la nostra app.

Code snippet per app di Windows Store C#

Presupponendo l’aggiunta di questi namespace e la dichiarazione di queste tre variabili:

< a href="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-87-58-metablogapi/3678.clip_5F00_image006_5F00_664BDFDE.png">

Inizializziamo il MB device

Il codice sopra riportato è abbastanza autoesplicativo, ovvero per prima cosa creiamo un grande blocco try-catch, poi inizializziamo la variabile mai device con l’istanza del dispositivo Mb di default, se non vengono sollevate eccezioni utilizziamo una messagebox per far visualizzare alcune info sulla periferica collegata, altrimenti visualizziamo il tipo di errore. Le info base che visualizzeremo sono: il numero di telefono della sim inserita, la classe cellulare della scheda lo stato del device e la capienza della memoria della sim.

Enumerazione di tutti i dispositivi mobile broadband

Tralasciando la parte identica allo snippet precedente notiamo come il metodo .GetDeviceSelector() permetta di utilizzare una stringa AQS per identificare all’ interno del nostro pc/tablet tutti i dispositivi mobile broadband, dopodiché con un semplice ciclo for visualizziamo tutte le info base per ogni device, identificando il singolo device attraverso il suo Id univoco utilizzato il inizializzare ad ogni ciclo la variabile di tipo SmsDevice a meno di eventuali eccezioni.

Invio SMS

Lettura messaggi dalla memoria della sim

In questo snippet vediamo come è possibile legge gli SMS dallo store della sim, vale la pena evidenziare due cose, ovvero, l’enumerazione SMSMessageFilter permette di identificare la tipologia di msg da leggere ( inviati, ricevuti, eliminati, bozze, tutti) e il fatto che all’ interno del ciclo i messaggi sono convertiti dal formato binario al formato testo con il metodo della classe SmsTextMessage .FromBinaryMessage().

Cancellazione messaggi dal message store

Tralasciando il codice già spiegato nello snippet precedente, le righe 6-7 mostrano come sia possibile cancellare in massa più messaggi semplicemente specificandone il tipo grazie all’ enumerazione spiegata prima, oppure come cancellare un singolo messaggio specificandone l’id al’ interno della lista instanziata in riga 3. La sottile differenza dei due metodi sta nel fatto che uno è singolare e l’altro è plurale!

Sottoscrizione e cancellazione ad eventi (messaggio ricevuto, stato device cambiato)

L’Intellisense provvederà creare i metodi di callback, nel primo caso un parametro del metodo sarà una variabile che permetterà di ottenere info sull’ SMS appena ricevuto, mentre nel secondo caso si potrà capire in che modo il dispositivo ha cambiato stato tramite la proprietà .DeviceStatus

Autenticazione via SMS concetti e algoritmi

Ora che abbiamo visto come poter sfruttare un MB device in Windows 8 per poter fare inviare sms alla nostra app, vediamo che tipo di approccio dobbiamo avere per essere sicuri dell’ efficacia di questo metodo. In questo articolo vedremo l’implementazione .NET degli algoritmi più usati in questi casi ovvero quelli definiti nei documenti RFC4226 e l’ RFC6238. Il primo fornisce una autenticazione basata su contatore mentre il secondo una basata su un determinato time span calcolato sul tempo UNIX. In questo articolo vedremo nel dettaglio il primo algoritmo (dato che per il secondo l’unica differenza sta nel primo valore fornito in input, che varia da un intero, ad un valore intero random dipendente dalla seguente formula calcolato su un intervallo di 30 secondi)

Y = (Now-UNIX_time) /30

Algoritmo RFC4226

L’algoritmo è definite come segue:

1. Prendi in input il numero di volte che è stato eseguito l’algoritmo + 1 insieme alla secret key

2. Incapsula tutto in un array di byte e calcola il SHA1 HMAC

3. Esegui delle operazioni bitwise e calcola il modulo del risulta dividendolo per 10^x dove X è il numero di cifre che vogliamo abbia il nostro codice di verifica.

4. Nel caso in cui il risultato dello step 3 abbia meno cifre di X fai un padding con zero

Code snippet dell’ algoritmo e chiamata del metodo

Il codice appena riportato è inserito dentro una Task<T> poiché proviene da un cloud service hostato su Windows Azure.

Questo snippet mostra la chiamata a tale funzione e l’invio del codice via sms. La classe SmsAuthServiceClient esiste perché deriva da una service reference che punta al cloud service dove è definito l’algoritmo della pagina precedente

Per quanto riguarda l’algoritmo RFC6238 il metodo avrà un parametro ovvero la chiave segreta e il resto sarà tutto definito a run time. Sotto è riportato l’algoritmo.

Grazie per avere letto questo articolo e per ora è tutto, se hai suggerimenti dubbi o domande contattami pure all’ indirizzo email: Questo indirizzo e-mail è protetto dallo spam bot. Abilita Javascript per vederlo.