Microsoft Live - Live Connect

Windows LIVE series:

• Introducere
• Web Authentication
• Live Connect
• Basic Operations
• SkyDrive

Si am ajuns la lucruri mai interesante. O sa incep azi sa povestim despre Live Connect. Ce putem sa facem cu Live Connect? Un user conectat la aplicatia noastra se poate conecta la email, SkyDrive, messeaging sau orice alt serviciu folosind un Live ID.
Cum il folosim? Partea buna in toata nebunia asta este ca API-ul de Live Connect este conform standardului OAuth 2.0 si suporta atat JSON cat si protocolul XMPP. Acesta poate sa fie integrat in orice fel de aplicatie, indiferent de limbaj sau platforma.
Daca e prima data cand auziti de XMPP, trebuie sa stiti ca acesta este un standard de comunicare pentru aplicatiile de chat, care permite ca sa ne integram aplicatiile proprii de chat cu Messenger-ul de la Microsoft faca nici o problema.
In urmatorul exemplu o sa vedem ce trebuie sa facem ca un utilizator sa se autentifice prin apeluri de tip REST:
- redirectam userul spre urmatoarea pagina, unde reprezinta id-ul pe care l-am primit cand ne-am inregistrat aplicatia, iar reprezinta url spre care userul o sa fie redirectionat in momentul in care procesul de autentificare s-a terminat cu succes. Despre parametrul vrea sa vorbim putin mai tarziu

https://oauth.live.com/authorize?client_id=<client_id>&scope=<scope>&response_type=code&redirect_uri=<redirect_url>

- dupa ce autentificare sa terminat, userul este redirectionat spre . In url o sa avem un parametru cu numele de 'code', pe baza caruia, putem sa obtinem token-ul de acces a userului. Folosind acest cod putem sa accesam orice serviciu integrat cu Live Connect. Mai jos gasiti modul in care serverul o sa ne apeleze aplicatia:

<redirect_url>?code=<o_cheie_unica>

- token-ul de acces a userului, de care avem nevoie ca sa accesam serviciile dorite se obtine apeland urmatorul url:

https://oauth.live.com/token?client_id=<client_id>&redirect_uri=<redirect_url>&client_secret=<client_secret_key>&code=<code>&grant_type=authorization_code

• client_secret_key - reprezinta cheia unica pe care am obtinut-o cand am inregistrat aplicatia
• authorization_code - specifica modul prin care vrem sa obtinem token-ul clientului. In cazul nostru pe baza codului pe care l-am obtinut la pasul precedent

Raspunsul care o sa ne vina in urma ultimului apel o sa contina 5 elemente:

1. access_token - token-ul de acces la servicii, pe care o sa il folosim cand vrem sa accesam un serviciu
2. authentification_token - token-ul de autentificare
3. scope - pentru ce servicii poate sa fie folosit token-ul
4. token_type - tipul de token obtinut( de obicei o sa fie 'bearer')
5. expires_in - durata de timp cand token-ul de acces poate sa fie folosit( valoarea este exprimata in secunde).

Mai jos gasiti un exemplu de raspuns in format JSON, pe care il primim in urma apelului:

{    "access_token" : "ExxXCSFCCWEECECE...AA==",    "authentication_token" : "423423-423424-2342342";    "expires_in" : 3600,    "scope" : "wl.signin wl.basic wl.calendars",    "token_type" : "bearer"}

Intr-un alt post o sa revin cu o descriere despre cum consumam serviciile integrate cu Live ID. Ce trebuie sa tinem minte este ca ce trebuie sa facem este sa apelam un url, cu anumiti parametrii in care sa includem si token-ul de acces.
Am ramas dator cu o explicatie. Ce este un SCOPE? Actiune prin care cerem permisiune unui user sa accesam unu sau mai multe servicii in numele acestuia.
Exista trei tipuri de scope:

• core - sunt serviciile de baza precum: conectare la Live Connect, lista de contacte, acces offline la date, fara ca userul sa mai fie nevoit sa se autentifice in aplicatia noastra
• extended - cateva servicii auxiliare, care completeaza functionalitatiile de baza( calendar, poze, skydrive, messeger, etc)
• developer - servici create de catre alti dezvoltatori, care sunt integrate cu Live Connect( orice persoana poate sa scrie o aplicatie si sa fie accesibila de catre orice persoana prin intermediul Live Connect)

Pentru o lista detaliata puteti accesa urmatorul link http://msdn.microsoft.com/en-us/library/hh243646.aspx.

Read More

Windows Live - Web Authentication

Windows LIVE series:

• Introducere
• Web Authentication
• Live Connect
• Basic Operations
• SkyDrive

Live ID se poate folosii pentru doua lucruri:

• autentificarea userilor in aplicatia noastra folosind contul de Live ID
• accesul aplicatiei noastre la servicii pe care un user de LIVE ID are access( photo sharing, agenda, calendar, etc)

Astazi o sa discutam despre cum poate un utilizator sa se autentifice in aplicatia noastra folosind contul de de Live ID.
Mai jos o sa prezint vechiul mod de autentificare, care a devenit absolute, odata cu lansarea "Live Connect", despre care o sa povestim cat de curand. Prefer sa prezint si acest mecanism in cazul in care lucrati cu aplicatii deja facute care folosesc vechiul mecanism de autentificare.
Acest mecanism de autentificare a fost denumit de cei de la Microsoft "Windows Live ID Web Authetification", dar nu are nimic mai special. In momentul in care userul doreste sa se autentifice, acesta este redirectat spre pagina Windows Live ID, unde isi va introduce datele. Dupa acest pas, userul este redirectat inapoi spre aplicatia noastra cu o cheie unica( token) - denumita Cliend ID, pe baza careia putem sa identificam userul. Pe langa aceste informatii, avem access la cateva date de baza a userului precum nume, tara, etc.
Cliend ID este o cheie unica formata din 16 caractere, pe care o sa trasmiteti la servere Windows Live de fiecare data cand un user se autentifica. Toate datele care se trasmit o sa fie encriptate si semntate pe baza unuei chei secrete pe care o primiti in momentul in care va inregistrati aplicatia.
Primul pas pe care trebuie sa il facem este sa ne inregistram aplicatia. Fiecare aplicatie se identifica unic pe baza unei chei. Acest lucru se poate face la urmatorul link: http://go.microsoft.com/fwlink/?LinkID=144070
Odata ce avem aplicatia inregistrata, trebuie sa adaugam in aplicatia noastra un link de autentificare prin Live ID. Acest link o sa contina ca si parametrii:

• appid - cliend ID( cheia unica a aplicatiei noastre)
• context -( optional) pagina spre care userul sa fie redirectionat dupa ce autentificarea se finalizeaza( ex. welcome.html)
• style -( optional) o colectie de atribute folosite prin care se poate personaliza bunoul de sign in

Dupa ce userul isi introduce credentiale o sa fie redirectionat spre pagina noastra. Pe flowul normal, in cookies o sa gasim un token encriptat cu cheia "webauthtoken". Acesta o sa contina urmatoarele date despre user:

• User.Id – id-ul unic a fiecarui user
• User.Timestamp – data ultimei autentificari
• User.Context – contextul care a fost specificat in momentul autentificarii
• User.Token – token-ul unic a userului curent( dupa o anumita perioada de timp acesta o sa expire)

Trebuie precizat ca datele sunt encriptate este AES128, iar cel de semnare este HMAC-SHA256. Mai jos gasiti un exemplu de cum trebuie facuta decriptatea si extragerea datelor.

public string DecryptResponse(){     const int ivLength = 16;     token = HttpUtility.UrlDecode(token);     byte[] ivAndEncryptedValue = Convert.FromBase64String(token);     var decryptAlg = new RijndaelManaged();     decryptAlg.KeySize = 128;     decryptAlg.Key = cryptKey;     decryptAlg.Padding = PaddingMode.PKCS7;     var memStream = new MemoryStream(ivAndEncryptedValue);     byte[] iv = new byte[ivLength];     memStream.Read(iv, 0, ivLength);     decryptAlg.IV = iv;     cStream = new CryptoStream(memStream, decryptAlg.CreateDecryptor(),                          CryptoStreamMode.Read);     sReader = new StreamReader(cStream, Encoding.ASCII);     return sReader.ReadToEnd();}

In urmatorul post o sa discutam despre Live Connect.

Read More

Code Retreat Sibiu

Sambata, 28 ianuarie 2012, sunteti invitati la birourile iQuest din Sibiu la o sesiune de Code Retreat.

Code Retreat este o oportunitate ca pe parcursul unei intregi zile sa scrieti cod doar de fun, fara presiunea deadline-urilor. Chiar daca nu reusesti sa termini decat cateva linii de cod, daca sunt “perfecte”, te consideram totusi “de-al nostru.” Este o ocazie in plus sa practicam ceea ce, ca dezvoltatori profesionisti de software, predicam: conceperea de cod minunat

Idea este simpla: se gaseste cate un partener de TDD pentru o problema de programare (tema) pentru 2×3 sesiuni de cate 45 de minute in orice limbaj doriti. Daca nu ati mai folosit TDD sau daca nu ati mai programat in echipa sa nu va fie teama: suntem prietenosi si nu va mancam de vii pentru asa ceva

Dupa fiecare sesiune perechile vor imparti pareri si cunostinte dobandite.

Pentru mai multe informatii: http://www.iquest.ro/blog/2012/01/26/iquest-code-retreat-sibiu/#.TyEYVvlactk

Update: Dupa acest eveniment, cea mai interesanta sesiune mi s-a parut pair-programing cand nici unu nu avea voie sa vorbeasca. A fost o experienta extrem de interesanta. Abia astept urmatoare competie de acest gen.

Read More

Web application end - how to determine why has stopped

Sa spunem ca avem o aplicatie web care se afla pe IIS. Observam ca aplicatia uneori moare si nu reusimg sa ne dam seama din ce cauza. Din anumite motive "exceptia" care se intampla in aplicatie nu poate sa fie prinsa si aplicația moare fără sa logeze nici o informație. De ce spun "exceptie", deoarece uneori poate sa fie vorba de un pool recycle care sa genereze acest comportament( cauza nu este mereu o exceptie in adevaratul sens al cuvântului).
Ce putem face? O solutie este ca in Global.asax.cs, in metoda Application_End sa obtinem date despre motivul pentru care aplicatie se termina si sa scriem aceste date in trace sau sa le logam undeva. Aceasta metoda o sa fie apelata de fiecare data cand aplicatia este oprita. Din pacate informatiile pentru care aplicatia este oprita se pot obtine doar prin intermedul reflection. Nu avem o alta modalitate sa obtinem aceste date. Daca aplicatia primeste un semnal din exterior ca trebuie sa se opreasca metoda Application_Error nu o sa fie apelata.
Mai jos gasiti un exemplu de implementare a metodei Application_End:

 public void Application_End()
        {
            HttpRuntime runtime = (HttpRuntime)typeof(System.Web.HttpRuntime).InvokeMember("_theRuntime",
                                                                                             BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField,
                                                                                             null, null, null);
            if (runtime == null)
            {
                return;
            }

            string message = (string)runtime.GetType().InvokeMember("_shutDownMessage",
                                                                                 BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField,
                                                                                 null, runtime, null);

            string stackTrace = (string)runtime.GetType().InvokeMember("_shutDownStack",
                                                                           BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField,
                                                                           null, runtime, null);

            Trace.WriteLine(string.Format("Application_End: {0} {1}", message, stackTrace));

        }

Enjoy!

Read More

Office document and custom properties in .NET 3.5

In documentele Office( Excel, Word, ..) putem sa stocam meta-propietati. Aceste meta-propietati sunt denumite custom properties. O parte din ele sunt definite de catre fiecare utilizator in parte, iar altele exista by default.
Informatii precum "Last Saved Time" sau "Last Author" sunt setate automat de catre Office in momentul in care lucram cu un document. In cazul in care dorim sa accesam aceste informatii din .NET 4.0 este destul de simplu, dynamic types isi face perfect treaba aici.
Partea interesanta este cand este nevoie sa accesam aceste date din .NET 3.5 de exemplu, unde dynamic types exista, dar nu ne permite sa il folosim asa cum am dorii.
Pentru a putea sa accesam custom properties dintr-un document Office, in .NET 3.5 trebuie sa ne reintoarcem putin in timp. Orice incercare de a accesa aceste propietati direct, o sa termine cu o eroare de COM la runtime.

((DocumentProperties)docWorkbook.BuiltinDocumentProperties)["Last Author"]
((DocumentProperties)docWorkbook.BuiltinDocumentProperties).Items[0]

Ca sa putem accesa aceste valori este nevoie sa apelam la Reflection. Orice call pe care il facem pe obiectul de tip DocumentProperties trebuie sa se faca prin reflection. Din cauza ca este un lazy binding, orice conversie a propietatii BuiltinDocumentProperties spre DocumentProperties o sa se termine cu o exceptie.
Mai jos gasiti un sample de cod care permite accesul la meta-propietatiile unui document Office.

private string GetDocumentProperty(Application doc, string propertyName)
      {
          object documentProperties = doc.Workbook.BuiltinDocumentProperties;

          Type propertiesType = documentProperties.GetType();
          object properties = propertiesType.InvokeMember("Item",
                               BindingFlags.Default |
                               BindingFlags.GetProperty,
                               null, documentProperties,
                               new object[] { propertyName });

          Type propertyType = properties.GetType();
          return propertyType.InvokeMember("Value",
                                     BindingFlags.Default |
                                     BindingFlags.GetProperty,
                                     null, properties,
                                     new object[] { }).ToString();
      }

Read More

KeyedByTypeCollection

Cati dintre voi ati folosit pana acuma KeyedByTypeCollection? Sa va spun sincer, pana nu de mult nici nu stiam ca exista. Aceasta colectie este un dictionar unde cheile acesteia sunt reprezentate de tipul valorii adaugate in colectie.

KeyedByTypeCollection<object> collection = new KeyedByTypeCollection<object>();
collection.Add("Car");
collection.Add(1);
collection.Add(1.1);
collection.Add("Dog");  // Aceasta linie o sa arunce exceptie.

Ultima linie o sa arunce exceptie deoarece avem deja in colectie un element de tip string. La prima vedere aceasta colectie pare destul de ciudata si poate genera urmatoarea intrebare:
La ce este folositoare?Un scenariu in care aceasta colectie poate sa foarte folositoare este cand vrem sa avem un factory care sa pastreze obiectele ca si singleton. Folosind aceasta colectie implementarea factory poate sa aibe urmatoarea forma:

public class SingletonFactory<T>
{
     private readonly KeyedByTypeCollection<T> _items = new KeyedByTypeCollections<T>();

     public TItem GetObject<TItem>()
          where TItem : T, new()
     {
          if(!_items.Contains(typeof(TItem))
          {
               _items.Add(new TItem));
          }

          return (TItem)_items[typeof(TItem)];
     }
}

In ce alte scenarii de utilizare ati folosii aceasta colectie?
Enjoy!

Read More

MVC3 - After RedirectToAction ViewBag is null

Intr-un post anterior am discutat putin despre ViewBag.
Sa vedem ce se intampla daca il folosim in urmatorul mod:

public ActionResult Index()
{
     …
     ViewBag.Error = “some error”;
     return RedirectToAction(“Error”,”Home”);
}

In cazul in care o sa dorim in actiune Error din controlerul Home sa accesam ViewBag.Error, o sa observam ca acesta este null. Informatile din ViewBag sunt pierdute in momentul in care se face un RedirectToAction.
O solutie destul de simpla este sa folosim TempData, care persista intre doua actiune. TempData se poate folosii cu success cand dorim sa trimitem date intre requestul current si urmatorul. Durata de viata a obiectelor din TempData, o sa fie pana la urmatorul redirect (inclusiv). Dupa momentul respective aceste date se pierd. Valoriile din TempData sunt tinute pe sesiune intre actine curenta si urmatorea actiune accesata printr-un redirect.

public ActionResult Index()
{
…
TempData.Error = “some data”;
return RedirectToAction(“Error”,”Home”);
}

Read More