Archives mensuelles : janvier 2014

Une présentation de la librairie Microsoft ASP.NET Identity

Disons-le, les chances que vous faites un site avec ASP.NET et que vous aillez la nécessité d’authentifier un utilisateur pour lui présenter du contenu privilégié sont assez hautes.

Au début des temps, il y avait ASP.NET Web Forms. À l’époque, l’approche était innovante et permettait aux développeurs d’applications web de mettre en place des solutions web complexes.

Ceci étant dit, depuis la venue .NET 2.0, en 2005, ASP.NET met à la disposition des développeurs des fonctionnalités permettant d’authentifier ses utilisateurs. Tout ce dont vous avez besoin est d’une base de données SQL et le tour est joué. Une très très grande majorité des outils développés pour ASP.NET utilisent ces fonctionnalités. De plus, il est même possible d’y ajouter des fonctionnalités personnalisées grâce à ses possibilités d’extensibilité.

Microsoft ASP.NET Identity

Microsoft ASP.NET Identity est le nom de la librairie que vous aurez à retenir lorsqu’il sera temps d’authentifier vos utilisateurs. Après dix ans, l’aspect de la gestion de l’authentification des utilisateurs avec ASP.NET avait nécessairement besoin d’un petit coup de jeunesse.

Avant tout, une mise en contexte est nécessaire. Il faut voir comment est comment le développement web, avec .NET, s’est transformé dans les dix dernières années.

À l’époque, ces technologies n’existaient pas :

J’ai aussi l’impression que vous pourriez aussi compléter la liste avec votre propre sélection de technologies. L’écosystème est vaste et assez riche.

Comment ça marche

En quelques mots, le fonctionnement de ASP.NET Identity est lié de très près au fonctionnement d’Entity Framework. Les fondations vous permettant d’aller récupérer les informations d’un utilisateur ou d’en modifier les informations utilisent Entity Framework.

Une ligne de code vaut mille mots, j’ai l’habitude de dire. De façon très simpliste, il est possible de créer un utilisateur de cette façon :

L’exemple de code a été pris ici.

Tout le code vous permettant de gérer l’authentification de vos usagers au sein de votre application est situé sous l’espace de noms Microsoft.AspNet.Identity.

Une première observation est que l’API d’ASP.NET Identity est maintenant conçu pour utiliser les fonctionnalités d’appels aux méthodes asynchrones. D’ailleurs, l’exemple de code précédemment utilisé utilise directement cela.

L’autre fonctionnalité au coeur de la librairie est l’utilisation de la notion Code First présente dans Entity Framework. Cet aspect vous permet de développer la définition des propriétés que contient votre identifiant utilisateur (nom, ville, âge, etc.).

Une connexion chez Google ou Facebook

Ce qui devient très intéressant avec ASP.NET Identity est la possibilité d’authentifier ses visiteurs à l’aide de leur compte Facebook et/ou Google à même l’API fourni par ASP.NET.

Ceux qui ont déjà eu à développer ce genre d’applications savent que ce n’est pas tout le temps une partie de plaisir et que, selon l’implémentation choisie, l’opération expose de développeur à une multitude de situations à gérer. De plus, il est de plus en plus fréquent d’avoir à authentifier des utilisateurs en utilisant un compte Google, Facebook ou même Microsoft.

Ceci étant dit, avec ASP.NET Identity, il est relativement facile de développer une application utilisant OAuth2 de Google, par exemple. Comme le démontre l’article, il revient à configurer votre application pour utiliser une connexion Google et vous serez en bateau. L’interaction avec le fournisseur d’authentification sera gérée automatiquement.

Y mettre la main

ASP.NET Identity est une librairie de son temps. En ce sens, je veux dire qu’elle s’installe à l’aide de NuGet. Au total et selon votre contexte de développement, il y a trois librairies à votre disposition :

La meilleure façon de s’initier à ASP.NET Identity est de pouvoir lire du code qui l’utilise. À ce sujet, je recommande d’aller jeter au coup d’oeil à ce dépôt GitHub. Il s’agit d’une application de démonstration utilisant la majeure partie des fonctionnalités de la librairie. Bien conçu!

Sources

Les liens de la semaine – Édition #64

Développement

.NET

Web

Technologie

Science et autres

Vous connaissez surment « Ce Projet »

J’écris souvent au sujet des réalités reliées au développement web. Par fois, j’exprime des opinions sur des sujets que je trouve importants ou des fois sur des concepts qui s’apparentent plus au gros bon sens.

smellEn arrondissant sommairement, cela fait presque dix ans que je travaille comme développeur. J’ai passé plus de la moitié de ce temps à faire du développement web. Cette expérience me permet d’affirmer la chose suivante : tout développeur a eu ou aura à travailler sur Ce Projet™.

Oui oui, Ce Projet.

Vous le savez. Il s’agit du projet que, dès l’instant où vous apprenez que vous aurez à y travailler, le regard des autres ne ment pas. Lentement mais sûrement, vous sentez ce sentiment de désespoir vous animer pour les semaines à venir.

Ce Projet où, lorsque vous commencez à travailler dessus, le collègue vous donne la directive suivante : « si tu touches à cette classe-là, viens me voir avant ».

Avec Ce Projet, il semble plus simple de dupliquer du code un peu partout que de s’attaquer au réusinage de code (aussi appelé refactoring. ha!) de la logique en question.

Lorsque vous êtes désespéré, vous tentez de retrouver le numéro de téléphone ainsi que l’adresse de résidence du développeur de l’application afin de lui livrer une correction qui saura se souvenir longtemps.

S’il est question code smell, vous vous dites que, dans ce cas, Ce Projet doit être en décomposition avancée.

Une chose est certaine. Par manque de temps et de budget, l’état de délabrement de Ce Projet ne s’améliorera pas.

Il y a plusieurs facteurs qui font en sorte qu’un projet est difficile à maintenir. Il se peut que le code en place, par la nature du problème à résoudre, soit complexe. Cela peut être aussi expliqué par des délais de livraison qui ont été écourtés. Que, par extension, la qualité en a aussi été affectée !

Peu importe la nature du problème qui affecte votre application, il faut savoir que la dette technique est le phénomène sous-jacent. Une dette technique est comme son équivalent financier. Elle aura tendance à prendre plus d’ampleur si elle n’est pas régulièrement remboursée.

Dans tous les cas, je lève mon clavier bien haut à tous ceux qui ont entre leurs mains Ce Projet. Votre patience et votre santé sont mises régulièrement à dure épreuve. Vous vous dites que vous y avez goûté plus d’une tasse ces derniers temps. Dites-vous que vous n’êtes pas seuls ;)

Les liens de la semaine – Édition #63

Parenthèse autopromotionelle : une façon de plus de connecter entre geeks. Allez cliquer sur « J’aime » sur la page Facebook de French Coding.

Développement

.NET

Technologie

Web

  • Deux séries de 40 cartes (partie 1 et partie 2) expliquant le monde dans lequel nous vivons.

Science et autres

Le jour où j’ai appris à déboguer du JavaScript avec Visual Studio 2013

Un certain matin, je travaillais sur un bout de code. Entre deux recherches Google, il y a quelque chose, qui m’a frappé en plein entre les deux yeux. Je crois avoir manqué le mémo qui concerne la possibilité de faire du débogage de JavaScript avec Visual Studio?

Je ne crois pas l’avoir vu passer. C’est aussi à cet instant que je me suis mis à chercher sur à ce sujet.

À même Visual Studio

Ce que j’ai réalisé, c’est qu’il est possible de faire le débogage de son code JavaScript à même Visual Studio. Ligne par ligne. Un point d’arrêt à la fois. Toutes les variables.

studio-js-debug

L’image présente la fonctionnalité en question. Comme il est annoncé ou votre argent sera remis. Ce n’est pas de la frime. Le seul requis pour utiliser Internet Explorer pour arriver à vos fins. Il suffit de configurer les différents points d’arrêts désirés, démarrer une séance de débogage (F5) et aller naviguer à la page désirée.

Pendant un moment, je me suis demandé si c’était une bonne ou une mauvaise chose. Après tout, je ne connais pas vraiment de gens qui utilisent Internet Explorer pour faire leurs développements web. Et les artisans du web que je connais considèrent le navigateur comme un mal nécessaire.

Faire mieux

Pour quelle raison est-ce qu’un développeur web utiliserait Internet Explorer alors qu’il peut utiliser un navigateur comme Firefox et Google Chrome pour le faire? Ces deux derniers ont des fonctionnalités de développement et de débogage intégrées à même le navigateur. En plus, les outils intégrés fonctionnent très bien!

En contrepartie, ce que les gens ne sont pas nécessairement au courant, c’est que les fonctionnalités reliées à l’éditeur de JavaScript au sein de Visual Studio ont été significativement améliorées depuis Visual Studio 2012. L’expérience de développement est devenue réellement plus agréable.

studio-js-intellisense

Depuis Visual Studio 2013, l’expérience de développement va encore plus loin. L’utilisation de l’éditeur de JavaScript ressemble de plus en plus à celui de C#. Il est question de fonctionnalités comme l’inspection de variables, navigation à la définition de fonctions et même de l’intellisense sur les différentes fonctions et librairies.

Le bien, le mal.

Je le répète encore une fois. La vraie question est bien la suivante : est-ce que vous connaissez vraiment un développeur web qui utilise Internet Explorer comme navigateur principal?

L’intérêt de la solution Internet Explorer et Visual Studio est bien uniquement pour les développeurs .NET et d’applications Windows 8. Dans ce dernier cas, il est bien important de pouvoir déboguer son application Windows 8 propulsée par JavaScript à même Visual Studio.

L’intégration de JavaScript au sein de Visual Studio est maintenant un incontournable pour l’avenir. Saviez-vous qu’il est même possible de faire du développement node.js à même Visual Studio? Il est même possible de faire le débogage du code en temps réel!

Sources