♪
Traduction▲
Cet article est la traduction la plus fidèle possible de l'article original de Brad Abrams, Business Apps Example for Silverlight 3 RTM and .NET RIA Services July Update: Part 3: Authentication.
L'authentification▲
Voici encore une mise à jour de ma présentation du Mix 09 intitulée « building business applications with Silverlight 3 ».
Vous pouvez regarder
La démo requiert les éléments suivants (tout est 100 % gratuit) :
- Visual Studio 2008 Express SP1 (qui comprend SQL Server 2008 Express) ;
- Silverlight 3 ;
- .NET RIA Services.
Vous pouvez, de plus, télécharger les fichiers de la démo complète et jeter un œil à l'application en cours d'exécution.
Dans cet article, nous allons parler de l'authentification.
NDT Pour cette session, il ne s'agit que d'une présentation basique des possibilités offertes par .NET RIA Services et Silverlight. Une session plus approfondie fera l'objet d'un article futur.
Les applications métier ont souvent accès à des données sensibles. Il est important que vous puissiez auditer, restreindre et contrôler l'accès à vos données. Voyons comment .NET RIA Services et Silverlight opèrent pour réaliser cela. Utiliser le modèle Silverlight Business Application est super facile. Par défaut, il est connecté au système d'authentification d'ASP.NET qui offre un système de gestion utilisateur personnalisable. Je vais faire la démonstration en utilisant l'authentification par formulaire, vous pouvez bien sûr utiliser l'authentification Windows en faisant une légère modification du modèle.
Pour cette démo, je vais faire la démonstration de la création d'un nouvel utilisateur, mais si vous disposez déjà d'une base utilisateur, vous pouvez l'utiliser. NDT Pour cette session, pensez à lancer l'application avec CTRL+F5.
Notez que nous avons des règles de validations fonctionnelles. Maintenant, l'application sait qui vous êtes.
Notez que tout ce qui concerne l'expérience utilisateur sur le client est complètement personnalisable étant donné que tout le code source est inclus dans le projet. Mais le modèle par défaut n'est pas mal pour de nombreuses applications. Maintenant que nous sommes connectés, faisons quelque chose de ces données utilisateur. Par exemple, faisons en sorte que seuls les utilisateurs enregistrés puissent accéder aux données des super employés. Éditons la classe SuperEmployeeDomainService (SuperEmployeeDomainService.cs) sur le serveur afin d'ajouter l'attribut RequiresAuthentication. Il y a d'autres attributs comme les rôles et la possibilité de les gérer dans votre code si vous le voulez.
Maintenant, si nous lançons l'application et que nous ne nous connectons pas, nous n'aurons aucune donnée. Notez que cette validation est faite côté client pour une expérience utilisateur riche et une fois encore sur le serveur pour s'assurer de la sécurité.
Lorsque nous sommes connectés…
… et lorsque nous ne le sommes pas.
Conclusion▲
Ceci conclut donc la troisième partie de cette série. Dans la quatrième partie, nous aborderons les différentes vues de notre logique applicative.
Remerciements▲
Je tiens ici à remercier Brad Abrams de nous avoir autorisés à traduire son article.
Je remercie également ClaudeLELOUP pour sa relecture et ses propositions.
