Home - About me - Browse by categories

[Build 2012] - Windows Phone 8 Application Model

Première session de la journée après le keynote qui fut assez riche en démos autour de Windows 8 / Windows Phone 8 et en surprises… Smile

image

Pour cette première session Windows Phone 8 de la semaine, on s’intéresse aux nouveautés concernant le développement d’applications sur la plateforme. Elle est présentée par Andrew Clinick, Group Program Manager Windows Phone.

##

Modèle d’exécution

Il faut garder en tête que tout ce qui fonctionnait sous Windows Phone 7.x continue à tourner sous Phone 8 : pas besoin de recompiler les applications.

Premier point abordé pendant la session : les performances des applications. Celles-ci doivent démarrer vite et être fast & fluide sinon, les utilisateurs risquent de ne pas vouloir les utiliser. Pour cela, Windows Phone 8 introduit une nouveauté : Compile in the cloud. Lorsque vous soumettez votre XAP dans le centre de développement, celui-ci est automatiquement recompilé en utilisant NGEN (Native Image Generator) et le XAP est mis à jour (au passage, c’est fait pour toutes les apps 7.x du store). L’utilisataion de NGEN est possible puisque désormais les applications s’exécutent dans la CoreCLR (comme sous Windows 8).

Le support des dual core sous Phone 8 est aussi pour beaucoup Smile

###

Fast App Resume

Cette fonctionnalité est une évolution du fast app swtiching de Phone 7.5. Le constat a été fait que trop peu d’utilisateurs utilisent le task switcher (pression longue sur le bouton back). Du coup maintenant l’application est résumée depuis n’importe où : Live Tile, app list, toast, deep link…

Multitasking

Il est désormais possible d’avoir une application qui utilise le service de localisation en continue. Au lieu d’être endormie, l’application peut continuer à s’exécuter en background pendant que l’utilisateur utilise une autre application.

Maps

Le contrôle Bing Maps est toujours supporté mais déprécié. Il faut désormais utiliser les nouveaux contrôles Nokia Maps !!

Intégration avec le téléphone

VOIP

Microsoft propose aux apps de s’intégrer avec la partie téléphone, pour les applications de type VOIP : récupérer des notification pour les appels entrants, activation d’appels vidéos, nouveaux background agent pour les appels voix, amélioration du support des pushs notifications.

Une application peut donc être en attente d’appels (c’est le cas pour Skype par exemple) et être réveillée dès que l’appel se produit (ouverture d’une popup similaire à celle d’un appel entrant GSM).

Une application peut également venir alimenter le hub contact en données (sans passer par les tâches contacts, comme sous 7.x). L’accès aux contacts créés par l’application se fait en lecture/écriture, mais en lecture seule pour les autres contacts (comme sous Mango)

Deep Linking & Partage

Il est possible d’associer une application à un schéma d’url donnée (exemple zune://, fb://) et faire en sorte que l’application se lance lorsque l’utilisateur clique sur une URL de cette forme. Il est désormais possible d’associer une extension de fichier à une application (comme le faisait déjà Adobe Reader ou les apps de la suite office). Du coup, votre application peut être associée à son propre format de fichier.

Stockage de données

SQL Server et Linq 2 SQL sont toujours supportés sous Windows Phone 8, mais SQLite est maintenant disponible pour la plateforme !!

Windows Phone 8 supporte les cartes SD et des APIs sont disponibles pour lire et écrire sur celles-ci.

Live Apps

Les Live Apps sont les applications qui utilisent des vignettes dynamique (live tiles). Microsoft oriente vraiment son discours autour de la nouvelle home page de Windows Phone, qui supporte désormais 3 tailles de vignettes dynamiques : petite, moyenne et grande. Microsoft encourage tous les développeurs à mettre en place ces vignettes dans leurs apps et propose des modèles de vignettes dans le SDK :

  • Flip : comme sous phone 7.x, se retourne aléatoirement
  • Iconic : possibilité d’avoir une icône, un compteur mais mieux que sous Phone 7.x avec un style proche des apps système type boîte mail etc…
  • Cycle : plusieurs contenus qui défilent de manière cyclique.

Egalement au menu, l’intégration dans l’écran de vérouillage avec la possibilité de changer l’image de fond et d’alimenter l’écran avec trois ligne d’information (comme Outlook pouvait le faire). Le fond d’écran de vérouillage peut être mis à jour depuis l’application en cours d’exécution ou depuis un background agent. Les informations affichées sur l’écran de vérouillage par l’application sont les mêmes que celles de la vignette dynamique (une seule et même API). L’utilisateur choisi quelle (unique) application peut changer le fond d’écran. L’application peut demander à l’utilisateur d’afficher cette fonctionnalité (via API).

Windows Phone 8 en entreprise

Windows Phone 7 a souvent été taclé sur ce point : sa mauvaise intégration en entreprise. Microsoft le sait, mais avec Windows Phone 8, ce temps est révolu ! Smile

Au niveau gestion de flotte mobile, il sera possible d’utiliser Windows Intune (application de police de sécurité, mise à jour d’apps automatique, gestion de parc…)

Au niveau du déploiement d’applications, il sera possible d’utiliser le web, l’email ou encore une application elle-même (un hub d’entreprise, par exemple). Vous devrez fournir votre propre certificat pour signer vos applications. Celles-ci ne seront alors disponibles que pour les collaborateurs de votre entreprise qui auront à enregistrer le certificat depuis leur téléphone (via web, mail…).

Conclusion

Cette session a proposé une vue d’ensemble de toutes les nouvelles fonctionnalités qui tournent autour de l’exécution des applications sous Windows Phone, mais également de l’intégration de celles-ci avec le téléphone / OS. Nous aurons l’occasion d’aller dans des considérations plus techniques au cours des autres sessions !

Stay tuned Winking smile

Julien

read more

Build 2012 c’est parti !

La conférence //Build/ 2012 démarre aujourd’hui même sur le Campus de Microsoft à Redmond et j’ai la chance d’y assister cette année (merci Microsoft France Winking smile) !

Vous l’aurez certainement deviné, le gros focus cette année va être le développement Windows 8 et Windows Phone 8 (après les annonces d’hier : http://www.microsoft.com/en-us/news/presskits/windowsphone/).

Je me suis concocté un parcours complet sur Windows Phone 8, avec au menu des sessions très génériques sur le développement d’apps en général et des sessions plus spécifiques sur les nouvelles features de la plateformes. J’aurai l’occasion d’y revenir sur mon blog au fur et à mesure ! D’ailleurs, le programme des sessions est disponible sur Channel 9 !

image

Stay tuned ! Winking smile

Julien

read more

[ASPNET Web API] Forcer le content type pour une action donnée

Avec ASP.NET Web API, la content négociation se fait à l’aide du header Accept de la requête HTTP. Lorsque le type demandé n’est pas pris en charge, la requête est alors traitée avec le formateur par défaut, en l’occurrence le formateur JSON.

Cependant, dans certains cas il est nécessaire de forcer  le format de retour de la requête. Par exemple pour retourner un flux RSS.

Considérons le code suivant :

public class RssController : ApiController
{
private readonly IBlogService _blogService;
public RssController()
{
var dbContext = new MetroBlogDbContext();
_blogService = new BlogService(dbContext);
}

public IEnumerable<Post> Get()
{
return _blogService.GetLatestPosts(true, 0, 20).ToList();
}
}

Il s’agit d’un simple contrôleur Web API qui retourne une liste d’objet Post (la définition n’a pas d’importance ici). Pour être capable de retourner un format de flux RSS, j’ai écrit un custom formatter pour RSS/Atom (cf. http://www.strathweb.com/2012/04/rss-atom-mediatypeformatter-for-asp-net-webapi/).

Une fois le formateur développé, il suffit de l’enregistrer au démarrage de l’application :

GlobalConfiguration.Configuration.Formatters.Add(new SyndicationFeedFormatter());

Cette solution permet de faire en sorte que lorsque le header Accept de la requête HTTP est à <em>application/rss+xml</em> ou <em>application/atom+xml</em>, le formateur SyndicationFeedFormatter soit utilisé et donc que le format en sortie soit un flux RSS. Ce n’est cependant pas suffisant pour que l’action Get renvoie toujours un flux RSS!

Pour le forcer, il est nécessaire de modifier le code de l’action Get et de créer nous même l’HttpResponseMessage qui sera renvoyé :

public HttpResponseMessage Get()
{
try
{
var posts = _blogService.GetLatestPosts(true, 0, 20).ToList();
var responseMessage = new HttpResponseMessage(HttpStatusCode.OK);
responseMessage.Content = new ObjectContent(typeof(IEnumerable<Post>), posts, new SyndicationFeedFormatter());
responseMessage.Content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/rss+xml");
return responseMessage;
}
catch(Exception ex)
{
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}

A partir de là, quelque soit le header Accept qui est envoyé, le format retourné sera <em>application/rss+xml</em>.

Il est également possible de filtrer certains type en se basant sur le header Accept de la requête afin de forcer le format que dans certains cas :

public HttpResponseMessage Get()
{
try
{
var posts = _blogService.GetLatestPosts(true, 0, 20).ToList();
var responseMessage = new HttpResponseMessage(HttpStatusCode.OK);

if (Request.Headers.Accept.Any(a => a.MediaType == "application/json"))
{
responseMessage.Content = new ObjectContent(typeof(IEnumerable<Post>), posts, new JsonMediaTypeFormatter());
responseMessage.Content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/json");
}
else
{
responseMessage.Content = new ObjectContent(typeof(IEnumerable<Post>), posts, new SyndicationFeedFormatter());
responseMessage.Content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/rss+xml");
}

return responseMessage;
}
catch(Exception ex)
{
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}

Dans le cas présent, si le header Accept de la requête contient le media type <em>application/json</em>, on renvoie un retour en JSON, sinon on renvoie le flux RSS formaté.

A bientôt !

read more

[ASP.NET MVC 4] Mise en place de l’authentification OAuth Facebook

L’une des nouveautés d’ASP.NET MVC 4 est la possibilité de mettre en place très simplement de l’authentification au travers de fournisseurs d’identité tels que Facebook, Microsoft, Google (etc.) dans une application. Ce type d’authentification est d’ailleurs proposée de base dans les nouveaux modèles de projets d’application ASP.NET MVC 4 de Visual Studio. Cependant, afin de bien comprendre comment mettre en place les différentes briques qui permettront cette authentification, je vous propose de partir de zéro et de créer un projet à l’aide du modèle Basic :

image

##

Déroulement de l’authentification

Le processus d’authentification à l’aide d’un fournisseur d’identité externe se déroule en plusieurs étapes décrites sur le schéma ci-dessous :

image

Dans un premier temps, l’utilisateur choisi le fournisseur d’identité (parmi ceux proposés par l’application) avec lequel il souhaite s’authentifier. Il est alors redirigé vers la page d’authentification du fournisseur choisi. L’utilisateur s’authentifie et est renvoyé sur l’application à l’aide d’une URL de callback qui a été transmise au fournisseur d’identité lors de la venue de l’utilisateur. Dans la dernière étape, l’application valide l’utilisateur et récupère son identité (établie par le fournisseur).

Il est alors possible de récupérer 4 informations :

  • L’état de l’authentification (échec ou succès)
  • Le nom d’utilisateur (si succès, transmis par le fournisseur)
  • L’id de l’utilisateur (si succès, transmis par le fournisseur)
  • Le nom du fournisseur

Ajout des références nécessaires à la mise en place de l’authentification OAuth

La mise en place de l’authentification OAuth requière l’ajout de plusieurs références au projet. Il est possible d’en récupérer la plupart à l’aide du package nuget  DotNetOpenOAuth extensions for ASP.NET (WebPages). Une fois le package installé, il ne reste qu’à ajouter une référence vers la librairie Microsoft.Web.WebPages.OAuth.dll depuis la fenêtre d’ajout de référence de Visual Studio.

Voilà les références que vous devriez avoir à ce stade :

image

Configuration des fournisseurs d’identités

Afin que l’authentification puisse fonctionner, il est nécessaire de configurer les différents fournisseurs d’identités à utiliser dans l’application. Dans le cas présent, nous allons voir comment configurer Facebook.

Pour commencer, créez une nouvelle classe dans le dossier App_Start du projet. Nommez la OAuthConfig. Cette classe possède une méthode statique RegisterOAuthProviders qui sera en charge d’initialiser les différents fournisseurs d’identités au démarrage de l’application :

public class OAuthConfig
{
public static void RegisterOAuthProviders()
{
//enregistrement des fournisseurs d'identité
}
}

Appelez cette méthode dans le Global.asax :

public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();

WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);

//enregistrement des fournisseurs d'identités
OAuthConfig.RegisterOAuthProviders();
}
}

L’enregistrement des différents fournisseurs va se faire à l’aide de la classe OAuthWebSecurity définie dans l’espace de noms Microsoft.Web.WebPages.OAuth. Celle-ci possède un certain nombre de méthodes statiques pour enregistrer les différents fournisseurs supportés nativement (RegisterFacebookClient, RegisterMicrosoftClient…).

Configuration de l’authentification Facebook

Avant de procéder à l’enregistrement du fournisseur, il est nécessaire de se connecter sur https://developers.facebook.com/apps et de créer une nouvelle application. Pour se faire, cliquez sur le bouton <em>+ Create New App</em> en haut à droite. Donnez un nom à l’application et validez en cliquant sur <em>Continue</em>.

image

Entrez le code de sécurité pour terminer la création. Pour que l’authentification fonctionne, il est nécessaire de cocher Website with Facebook Login en bas de page et de renseigner l’URL du site web qui va utiliser l’application Facebook pour l’authentification. En l’occurrence ici votre URL de débogue dans Visual Studio :

image

Validez en cliquant sur Save Changes.

Il vous faut alors récupérer l’App ID et l’App Secret en haut de la page, afin d’enregistrer le fournisseur dans Visual Studio.

image

Pour enregistrer le fournisseur, il suffit d’appeler la méthode RegisterFacebookClient de la classe OAuthWebSecurity :

OAuthWebSecurity.RegisterFacebookClient(
appId:"[appId]",
appSecret:"[appSecret]",
displayName: "Facebook"
);

Création de la page de Login

Ajoutez un contrôleur <em>Account</em> et créez une action Login. Le modèle passé à la vue correspond à la liste des fournisseurs configurés (ici Facebook), représentée par la propriété RegisteredProviders sur la classe OAuthWebSecurity :

public class AccountController : Controller
{
public ActionResult Login()
{
return View(OAuthWebSecurity.RegisteredClientData);
}
}

La page affiche alors un bouton pour chaque fournisseur :

@model ICollection<AuthenticationClientData>

@{
ViewBag.Title = "Authentification";
}

## Choisissez un fournisseur d'identité pour vous identifier

@using (Html.BeginForm("Login", "Account", FormMethod.Post))
{
foreach (var provider in Model)
{
<input type="submit" name="provider" value="@provider.DisplayName" />

}
}

Le code appelé lors du POST du formulaire effectue la redirection vers le fournisseur sélectionné, en lui passant la callback URL (appelée après l’authentification par le fournisseur d’identité) :

[HttpPost]
public ActionResult Login(string provider)
{
string callbackUrl = Url.Action("ProviderCallback", "Account");
OAuthWebSecurity.RequestAuthentication(provider);
return new EmptyResult();
}

Lancez l’application, rendez-vous sur la page /Account/Login et vérifiez qu’un bouton Facebook apparait bien :

image

En cliquant sur le bouton, vous devriez être redirigé sur Facebook. Authentifiez-vous, acceptez d’utiliser l’application. Vous devriez alors être renvoyé sur votre site (sur l’action ProviderCallback). Pour le moment, vous devez obtenir une erreur 404.

image

Dans l’action de callback, il s’agit de vérifier que l’authentification a bien fonctionné. Pour cela, il faut utiliser la méthode VerifyAuthentication sur la classe OAuthWebSecurity. Si le résultat est valide, vous pouvez alors récupérer le nom et l’id de l’utilisateur et créer une session (à l’aide de la classe FormsAuthentication, par exemple) :

public ActionResult ProviderCallback()
{
var result = OAuthWebSecurity.VerifyAuthentication();
if (result.IsSuccessful)
{
string userName = result.UserName;
string userId = result.ProviderUserId;
FormsAuthentication.SetAuthCookie(userName, false);
return RedirectToAction("Index", "Home");
}
else
{
return RedirectToAction("Login", "Account");
}
}

Et voilà, le tour est joué, votre utilisateur est authentifié via Facebook.

Le mécanisme d’authentification est ultra générique ici, puisqu’il suffit de rajouter des fournisseurs (Microsoft, Google, Twitter, Yahoo…) dans la méthode RegisterOAuthProviders de la classe OAuthConfig créée au début de cet article !

Le code source de l’application d’exemple est disponible ici : https://juliencorioland.blob.core.windows.net/publicfiles/MVC4.ArticleOAuth.zip

A bientôt image

read more

Authentification Hybride Forms et ACS dans une application ASP.NET MVC hébergée dans Azure

Pour un projet, j’ai du mettre en place un mode d’authentification hybride Forms / ACS (Access Control Service) au sein d’une même application ASP.NET MVC, hébergée dans Azure.

Pour la partie Forms Authentication, je me suis basé sur un custom membership provider qui travaille avec le stockage par table de Windows Azure. Vous pouvez également utiliser les Azure Storage providers disponibles sur CodePlex ou NuGet. Je ne détaillerai pas la configuration de ce type d’authentification qui a déjà été traité dans pas mal d’articles sur le net.

Je souhaitais absolument avoir un mécanisme d’authentification qui soit peu intrusif, et surtout éviter d’avoir à gérer deux types d’authentification techniquement distincts dans mon code (si je suis en ACS alors la déconnexion se fait comme cela, si je suis en Forms alors …). Du coup, j’ai décidé d’utiliser ACS uniquement comme mécanisme d’authentification et du coup comme autorité d’identification des mes utilisateurs.

Pour se faire, j’ai tout d’abord configuré mon espace de noms ACS sur le portail d’administration Windows Azure. Pour voir comment faire cela pas à pas, je vous invite à lire ce billet sur le blog de Léo.

Une fois ACS configuré, il est possible de gérer l’authentification via ACS (et donc Windows Identity Foundation) de plusieurs manières : la première, en utilisant le fichier Web.config et en configurant les bons HTTP module fournis avec le SDK WIF. Lors de la callback d’ACS (après authentification Windows Live, Facebook ou Yahoo…) les modules se chargeront automatiquement de récupérer l’identité de l’utilisateur ainsi que de retourner ses claims (propriétés qui identifient l’utilisateur, telles que son identifiant, son email, son nom… en fonction de ce qui a été configuré sur ACS).

L’autre solution consiste à ne pas utiliser la configuration automatique de WIF et de catcher manuellement la réponse d’ACS après que l’utilisateur soit authentifié. Pour cela, il suffit d’écrire un peu de code, mais rien de bien méchant !

Avant tout, il est nécessaire d’ajouter deux références au projet : Microsoft.IdentityModel.dll (disponible dans le GAC après avoir installé le SDK WIF) et System.IdentityModel.dll.

Il faut commencer par vérifier que la requête HTTP est bien issue d’une callback d’ACS. Pour se faire, on utilise le module WSFederationAuthenticationModule qui fournit des outils pour interpréter les réponses d’ACS en mode WS-Federation :

WSFederationAuthenticationModule wsFedAuthModule = new WSFederationAuthenticationModule();
if (!wsFedAuthModule.IsSignInResponse(request))
throw new HttpException(403, "forbidden");

Ensuite, il est possible de récupérer la réponse sous la forme d’un objet de type SignInResponseMessage :

var signInResponseMessage = wsFedAuthModule.GetSignInResponseMessage(System.Web.HttpContext.Current.Request);

La récupération des claims renvoyé par le STS (Secure Token Service) d’ACS se fait ensuite à l’aide du WSFederationSerializer, qui permet notamment de récupérer le secure token de la réponse :

var serializationContext =
new WSTrustSerializationContext(SecurityTokenHandlerCollectionManager.CreateDefaultSecurityTokenHandlerCollectionManager());
var secureTokenResponse = new WSFederationSerializer().CreateResponse(signInResponseMessage, serializationContext);

La réponse qui est récupérée contient le token de sécurité renvoyé par ACS. Celui-ci contient les différentes informations relative à l’utilisateur et est chiffré. Il est nécessaire d’utiliser un Saml2SecurityTokenHandler afin d’accéder aux informations du token. Avant, il est nécessaire de récupérer l’emprunte du certificat utilisé par ACS, l’espace de nom ACS, ainsi que la liste des URIs autorisées à travailler avec ACS (en fonction de votre configuration, je vous renvoie vers l’article de Léo évoqué plus tôt) :

ConfigurationBasedIssuerNameRegistry issuers = new ConfigurationBasedIssuerNameRegistry();
string certificateTumbprint = "<certificat tumbprint>";
var ascNamespace = "https://votrenamespace.accesscontrol.windows.net/";
issuers.AddTrustedIssuer(certificateTumbprint, ascNamespace);

Saml2SecurityTokenHandler tokenHandler = new Saml2SecurityTokenHandler
{
CertificateValidator = X509CertificateValidator.None
};

SecurityTokenHandlerConfiguration config = new SecurityTokenHandlerConfiguration
{
CertificateValidator = X509CertificateValidator.None,
IssuerNameRegistry = issuers
};

config.AudienceRestriction.AllowedAudienceUris.Add(new Uri("http://127.0.0.1"));
tokenHandler.Configuration = config;

Maintenant que le token handler est correctement configuré il ne reste qu’à utiliser un simple XmlReader pour lire le security token et en extraire la collection de **ClaimsIdentity** qu’il transporte :

using (var reader = XmlReader.Create(new StringReader(secureTokenResponse.RequestedSecurityToken.SecurityTokenXml.OuterXml)))
{
SecurityToken token = tokenHandler.ReadToken(reader);
ClaimsIdentityCollection claimsIdentity = tokenHandler.ValidateToken(token);
}

Chaque ClaimsIdentity contenu dans la collection possède alors une collection Claims, retournant chacun des claim associé à l’utilisateur qui s’est connecté. Il ne reste qu’à implémenter votre propre logique pour créer le cookie de session de l’utilisateur (à l’aide de la méthode SetAuthCookie de la classe FormsAuthentication, par exemple).

Il est donc possible d’avoir un contrôle vraiment fin sur l’authentification d’un utilisateur via ACS, permettant ici d’inter-opérer simplement avec un autre mécanisme d’authentification !

A bientôt image

read more