gennaio 2005 - Posts
Da pochi giorni (27/01/2005) è disponibile, su un Workspace di GotDotNet, la nuova versione dell'Updater Application Block.
Provo a riportare le mie prime impressioni. Hanno migliorato molti aspetti che erano critici o comunque migliorabili nella precedente versione come:
- Possibilità di sganciarsi da BITS (Background Intelligent Transfer System) implementando l'interfaccia IDownloader e creando dei downloader custom. L'interfaccia IDownloader c'era anche prima, seppur più semplice, ma ora la sua implementazione che usa BITS è implementata in un assembly separato che possiamo anche ignorare completamente.
- Possibilità di aggiornare singoli file e non per forza tutta l'applicazione, sfruttando l'hashing sui singoli file, per rilevare le differenze
- Facoltà di eseguire N attività post-installazione, compreso lanciare un pacchetto MSI di Windows Installer, per installare applicazioni accessorie (non male!)
- Incrementato il numero di eventi disponibili per tracciare lo stato dell'Updater dalle nostre applicazioni
- Utilizzo dei percorsi relativi sui file nella configurazione
- Possibilità di interrompere e riprendere i download degli aggiornamenti tra diverse sessioni di lavoro
- Ora è possibile cancellare/copiare/spostare file e cartelle come operazioni post-installazione, in questo modo è possibile "pulire" il client dalle vecchie installazioni o annullare da remoto degli upgrade che per qualche ragione causano effetti collaterali da sospendere
- Utilizza Microsoft Enterprise Library per alcune delle sue funzionalità (Logging, Configuration, Security)
A prima vista mi sembra che sia stato fatto un ottimo lavoro. Nei prossimi giorni proseguirò nell'approfondimento.
(Aspetto curioso: per ora l'abbiamo scaricata solo in 79 :-) ...)
Mi permetto di dire la mia su un post di Marco Barzaghi, che ho letto oggi in merito alla sicurezza e alla crittografia.
Mi sento particolarmente coinvolto dall'argomento visto che lo scorso anno, insieme a Marco, siamo intervenuti in 12 città parlando di sicurezza per conto di MSDN Italia e anche di recente abbiamo dato il nostro contributo sul tema, con tre articoli nello speciale sicurezza di Visual Basic Journal.
Provando a dare una risposta al quesito “...manka qlkosa?” mi viene da dire:
- Prima regola d’oro sulla sicurezza di una tecnica di encryption dei dati: “La sicurezza di una comunicazione criptata deve dipendere solo dalla segretezza della chiave e non dalla segretezza dell’algoritmo usato per proteggere il messaggio” (principio di Kerckhoffs). Questo significa che proteggere l’algoritmo con obfuscation è inutile al fine di rendere sicuro un messaggio criptato.
- Impedire a un attaccante di invocare un metodo utilizzando StrongNameIdentityPermissionAttribute è altrettanto inutile in quanto un hacker saprà sicuramente che con il comando “caspol –s off” può spegnere qualsiasi tipo di verifica (come spiega Keith Brown in questo articolo)
Per rendere sicura l’encryption di un messaggio occorre quindi rendere sicura la chiave utilizzata, oltre a scegliere ovviamente un algoritmo di encryption che sia il giusto bilanciamento tra solidità e costo computazionale, rispetto a quella che è la reale importanza del dato da proteggere.
Nel roadshow abbiamo consigliato di utilizzare DPAPI (Data Protection API) in quanto si basa su chiavi di encryption simmetriche, protette per conto nostro dal sistema, quindi non è più compito nostro preoccuparci della segretezza della chiave. In questo articolo di MSDN è spiegato come utilizzare DPAPI in .NET.
Alternativamente è possibile utilizzare un algoritmo a chiave simmetrica come AES (in .NET corrisponde a Rijndael). Sconsiglio DES per la sua relativa fragilità rispetto alla potenza di calcolo odierna e al fatto che è fallibile alle ripetizioni (problema noto anche come paradosso del compleanno: cercate “birthday paradox” su google, relativamente alla crittografia). 3DES è meglio di DES, in quanto è meno fallibile a problemi legati alle ripetizioni, visto che applica in sequenza 3 volte DES, ma è di conseguenza abbastanza lento. Considerate inoltre che AES è stato scelto dal Governo degli Stati Uniti, dopo un’attenta selezione tra diversi algoritmi in concorso.
In generale con algoritmi a chiave simmetrica (cioè che usano la stessa chiave per criptare e decriptare i messaggi) conviene usare chiavi non banali e sufficientemente lunghe, così come blocchi di dimensione consistente (almeno 128bit), mantenute opportunamente segrete.
Se si cercano livelli di sicurezza superiori, è possibile adottare algoritmi di encryption a chiavi asimmetriche (detti anche public key algorithms), come RSA. In .NET esistono delle classi apposite, quindi risulta anche semplice utilizzarli.
Nel caso preso in esame da Marco Barzaghi, e in generale in tutti quei casi in cui si vuole proteggere stringhe di connessione, password applicative o altro di simile, credo che la soluzione migliore sia utilizzare DPAPI.
Nel caso in cui invece si voglia proteggere un’applicazione da installazioni non autorizzate, è possibile valutare l’uso della firma digitale, per esempio su file di licenza XML, sfruttando XML Signature (supportato da .NET). Nel roadshow abbiamo mostrato in tutte le tappe come costruire una simile soluzione.
Se non siete venuti al roadshow:
1) male, molto male! J
2) battete un colpo e vedrò di mandarvi lo snippet di codice, che comunque potete scaricare come esempio da MSDN
Per approfondire questi argomenti consiglio la lettura dell’ottimo libro Practical Cryptography, ma non mangiate pesante prima di iniziare a leggerlo J ....
Il 25 gennaio MTOM è diventata una Raccomandazione del W3C:
http://www.w3.org/TR/soap12-mtom/ e con lui XOP:
http://www.w3.org/TR/xop10/.
Aspettavo l'uscita dell'esame da diverso tempo. Ora il papà :-) di BizTalk l'ha annunciato:
http://blogs.msdn.com/scottwoo/archive/2005/01/17/354647.aspx
Non mi resta che studiare bene tutto e buttarmi ...
Penso che appena avrò un attimo sarà il caso di valutare l'installazione di questo utilissimo controllo anche sui blogs di DevLeap:
http://blogs.ugidotnet.org/penpal/archive/2005/01/13/9238.aspx
Intanto metto un POST sul POST di Andrea, così ho rispettato la licenza :-) e lo ringrazio per il bel lavoro svolto.
Certo è triste che rompano con lo spamming anche sui blog! :-(
Segnalo nel blog una risposta che ho appena mandato via email a un lettore di VBJ che mi ha chiesto come sia possibile leggere da IsolatedStorage il percorso assoluto di un file o di un folder.
Che io sappia un metodo pubblico per farlo non c'è, però esiste un metodo internal di nome GetFullPath che fa al caso nostro. Per chiamarlo dobbiamo appoggiarci a un po' di Reflection:
MethodInfo mi = isoFile.GetType().GetMethod("GetFullPath", BindingFlags.NonPublic | BindingFlags.Instance);
object[] parameters = new object[1] { "Files/Ordini/Ordine01.txt" } ;
string fullPath = StringType.FromObject(mi.Invoke(isoFile, parameters));
Come tutte le volte che si utilizza Reflection, in particolare su membri privati o internal, bisogna assumersi la responsabilità di ciò che si fa, perchè il codice privato/internal potrebbe essere cambiato senza alcun preavviso.
Inoltre in generale non è una buona regola accedere ai file dell'IsolatedStorage usandone il path assoluto, altrimenti perchè dovremmo usare l'IsolatedStorage?
Come poi giustamente mi segnala Marco via email: i diritti necessari a fare quell'operazione (e probabilmente per accedere al file con un percorso assoluto) difficilmente sono quelli di "Local Intranet" o "Internet".
Non male come titolo di un libro: http://www.microsoft.com/MSPress/books/6895.asp .
Appena esce lo compro e poi vi dico!
Diverse persone mi hanno chiesto via email se ho intenzione di organizzare il bis dell'evento di Brescia (http://devcon.devleap.com/oneday/) dalle parti di Roma.
Le ragioni di una eventuale replica sono:
- Andare incontro a chi non poteva permettersi una trasferta apposta per un giorno
- Fornire a chi era impegnato/incasinato con l'inizio dell'anno una seconda possibilità
- Provare a scendere sotto Firenze, cosa che raramente si fa con questo tipo di eventi
- Consentire a chi non ha fatto in tempo ad iscriversi di seguire comunque l'evento
La formula la conoscete ... sul sito c'è scritto tutto. Ovviamente sarebbe a Roma e non a Brescia. Pensate se vi può interessare e semmai fatemi una email (paolo@devleap.com) o lasciate un commento qui sotto.
Come nel caso di Brescia ... se in tanti mi daranno un feedback positivo vedrò il da farsi. Magari nello scrivermi fate anche qualche ipotesi di data.
Se non altro se dovessimo ripetere l'evento a Roma .... non ci sarà la nebbia :-) e quindi potrete trovare tutti l'hotel al primo colpo! :-)
Approfittando del fatto che fino a domattina sarò in ferie... ho fatto qualche test di prestazioni dei servizi SOAP sia su HTTP, che HTTPS che SOAP.TCP con l'ultima release di WSE2 (SP2).
Ecco i risultati che ho ottenuto:
Ho provato, in tutte le varie salse, un servizio, chiamandolo 1000 volte, per 3 volte (quindi 3000 in tutto) e vedendo il tempo medio impiegato. Il servizio restituiva un array di 20 item di tipo Customer così definiti:
<s:complexType name="Customer">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Name" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Email" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="Id" type="s:int" />
</s:sequence>
</s:complexType>
Per WS-Security intendo WS-SecureConversation (scambio del token) + WS-Security con o senza encryption (ENC) e firma digitale (DSIG).
Ed ecco l'interpretazione dei risultati:
- Ovviamente HTTP liscio è il più veloce
- SOAP.TCP liscio è più lento di HTTP, ma il vantaggio di SOAP.TCP non è la velocità, ma il fatto di poter lavorare peer-to-peer e in asincrono
- HTTPS è risultato molto veloce, leggermente di più di quello che mi aspettassi
- HTTP + WS-Security con encryption è risultato circa 3 volte più lento di HTTP "liscio", ma in questi tempi va calcolato lo scambio del token di WS-SecureConversation
- La firma digitale - con WSE2 - è quella che determina il vero rallentamento. Usiamola quindi solo quando serve davvero.
- I SoapService che sfruttano la possibilità di essere configurati come HttpHandler non sono particolarmente veloci, quindi è meglio usarli solo se abbiamo bisogno del massimo controllo sul messaggio SOAP, altrimenti meglio andare all'antica con gli ASMX.
Avrei dovuto comprare il Qtek 9090, al posto del mio attuale 2020, per Natale. Poi per N motivi non l'ho preso e mi ero ripromesso di farlo come prima cosa ieri :-), dopo aver concluso la DevCon OneDay.
Invece mi si è presentato Marco con il suo Qtek 9090 appena preso e che mi ha consentito di rilevare che:
- La tastiera secondo me è completamente inusabile: troppo piccola e troppo scomoda. Per scrivere un numero o un carattere tipo !, ?, @, ecc. devi fare i salti mortali
- La retroilluminazione della tastiera è basata su luce blu intensa (io sono allergico alla luce blu intensa, non sto scherzando). Marco mi ha già detto che è possibile disattivare la retroilluminazione, ma poi come faccio a usarlo in treno o in aereo al buio? :-)
- La telecamera/fotocamera funziona molto meglio di quella del 2020 e dall'idea ha un qualche sistema di stabilizzazione dell'immagine, perchè le fotografie, al contrario di quelle che scatto con il 2020, non sono mosse ma ben ferme
- I vari accessori del 2020 a prima vista non vanno sul 9090, che ha un connettore diverso, quindi dovrei ricomprarne alcuni
Ma perchè dovrei comprare il 9090 avendo già il 2020? Perchè sul 2020 non ho la WiFi! :-( A questo punto mi sta venendo la tentazione di acquistare l'IPaq 6340 che ha le stesse caratteristiche del 9090, ma a prezzo rivenditore riesco a pagarlo molto meno, è più leggero (190g invece di 205g), però non ha la fotocamera integrata, ma solo come optional. Lo so: è un telefono a che serve la telecamera? Ma confesso che da quando ho il Qtek 2020 ho rivalutato la fotocamera. Le fografie e i filmati 640x480 sono "usabili" e in diverse occasioni mi è risultato comodo avere solo il Qtek con me e poter telefonare, riprendere, fotografare, scaricare la posta, ecc.
La tastiera dell'IPaq è rimovibile (comodo ...) quando non la vuoi la stacchi e non te la porti appresso.
E per guarnire il tutto mi arriva Andrea :-) che dice che il Qtek 8010 va benissimo!
Non so che fare .... :-(
Devo decidere tra:
http://www.pocketpcitalia.com/recensioni/hardware/qtek9090.asp
http://www.pocketpcitalia.com/recensioni/hardware/qtek_8010.asp
http://www.pocketpcitalia.com/recensioni/hardware/hp_ipaq_6340.asp
Aiutatemi! :-) Scherzi a parte ... se avete uno di questi cellulari ... e avete voglia di farlo ... datemi dei feedback per decidere! :-)
Dura la vita del malato di tecnologia!
Nelle prossime settimane parlerò di SOA e Smart Client (con un taglio decisamente più introduttivo di quanto abbiamo fatto ieri al DevCon OneDay) nei seguenti WebCast:
SOA: teoria
Mercoledì 19 gennaio, ore 14.30
SOA è l’acronimo di Service Oriented Architecture. Si tratta di un’architettura di disegno e sviluppo di servizi SOAP in grado di rispettare le seguenti regole fondamentali: i servizi hanno confini espliciti; sono autonomi; condividono gli schema (XSD) e i contratti (WSDL) ma non le classi e le librerie; la compatibilità è definita a livello di policy. In questo WebCast vedremo in dettaglio il perchè di queste regole e capiremo come farne tesoro nel disegno dei nostri servizi SOAP.
SOA: la pratica con ASP.NET
Mercoledì 26 gennaio, ore 14.30
La seconda puntata di questa serie di Webcast si concentra sulle tecniche di sviluppo SOA di servizi ASP.NET. Infatti disegnare e sviluppare servizi SOA richiede di modificare il modo di lavorare “classico”, utilizzato nello sviluppo di Web Service ASP.NET. Vedremo come disegnare i messaggi, partendo dagli schema XSD, e i contratti, partendo dai documenti WSDL, per poi implementarli in servizi ASP.NET.
Smart Client Parte 1 - Teoria
Martedì 1 febbraio 2005, ore 14.30
Sempre più spesso, nello sviluppo di applicazioni, ci si trova a dover scegliere tra applicazioni Windows o Web. Le applicazioni Windows hanno interfacce utente evolute, funzionalità interattive, rapidità nei tempi di risposta, ma sono onerose da installare e da mantenere, richiedono permessi particolari sul client e in generale costano molto come deployment. Le applicazioni Web hanno un costo di installazione quasi pari a zero, basta avere un browser per usarle, ma hanno interfacce utente spesso poco evolute e scarsamente interattive, inoltre richiedono la presenza costante della rete per dialogare con il server. Le applicazioni Smart Client prendono tutto ciò che di buon hanno entrambe le tipologie di applicazioni, cercando di snellire le fasi di deployment e aggiornamento, fornendo interfacce utente evolute e consentendo il lavoro disconnesso. In questa sessione valuteremo gli aspetti architetturali di una soluzione Smart Client.
SOA: la pratica con WSE2
Mercoledì 2 febbraio, ore 14.30
Web Services Enhancements 2.0 è una libreria di Microsoft che estende e completa il motore di Web Service ASP.NET standard. WSE2 fornisce gli strumenti necessari per sviluppare servizi realmente SOA, anche indipendenti da ASP.NET. In questo terzo WebCast vedremo come utilizzare WSE2 per creare servizi SOA orientati al messaggio e indipendenti dal protocollo (HTTP).
Smart Client Parte 2 - Pratica
Giovedì 3 febbraio, ore 14.30
In questa seconda puntata avremo un approccio pratico allo sviluppo di Smart Client, valutando gli aspetti tecnici e implementativi di una soluzione “disconnettibile”. In particolare prenderemo in esame l’Offline Application Block di Microsoft, utilizzandolo come punto di partenza per lo sviluppo dell’infrastruttura di comunicazione di un applicativo Smart Client dimostrativo. Concentreremo in particolare la nostra attenzione sul trasferimento e sul trattamento dei dati disconnessi e sulla gestione della sicurezza.
E anche DevCon OneDay (acuview) è andata! Personalmente sono molto soddisfatto! Sono anche stanco morto, ma soddisfatto. Mi permetto di dire che ritengo l'esperimento riuscito. Mi sono divertito un casino! :-) Stasera siamo usciti a cena (noi di DevLeap in forze, con Coriano da remoto via Qtek insieme alla Sig.ra Coriani e a Junior), abbiamo mangiato come porcellini :-) e bevuto come DevLeap ;-) ... è andato tutto molto bene!
Grazie a tutti!
Come da soggetto! Ci vediamo domani....
More Posts
Next page »