Microsoft Live - Live Connect

Windows LIVE series:

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:

access_token - token-ul de acces la servicii, pe care o sa il folosim cand vrem sa accesam un serviciu
authentification_token - token-ul de autentificare
scope - pentru ce servicii poate sa fie folosit token-ul
token_type - tipul de token obtinut( de obicei o sa fie 'bearer')
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.

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see

Navigating Cloud Strategy after Azure Central US Region Outage

Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage. But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too

Cloud as a Story - Vunvulea Radu

Search This Blog