Discussion :

[Skalp]

Cette discussion est consacrée à l'article :

Implémenter une authentification par formulaire avec OWIN et ASP.Net MVC 5

Lien vers l'article

Dans ce tutoriel en pas à pas et avec le minimum de code, voyez comment mettre en place une authentification sur un site ASP.Net MVC 5 à partir d'un modèle de site vide (sans tous les morceaux de code incompréhensibles des modèles de projet avec authentification).
Ce mode est basé sur OWIN. Il remplace le mode d'authentification par formulaire (Forms Authentication), très populaire en ASP.Net.
Voyez aussi comment ajouter des informations utilisateurs personnalisées dans le cookie d'authentification à l'aide des « Claims » (ou revendications).
Ce mode est bien adapté pour une application métier dans un intranet d'entreprise, car il est simple à mettre en place et suffisamment sécurisé.

Postez ici vos commentaires concernant cette publication.

[Lana.Bauer]

Merci pour ce tutoriel !

[stailer]

Bonjour,

J'ai utilisé Owin via SignalR pour faire du temps réel. Mais peux-tu m'expliquer l'intérêt dans une simple authentification, à utiliser Owin, par rapport à une connexion classique (ou par ajax) ?

Merci pour ce tutoriel très clair et détaillé... Il me manque juste le "pourquoi du comment" en intro

[Skalp]

J'ai utilisé Owin via SignalR pour faire du temps réel. Mais peux-tu m'expliquer l'intérêt dans une simple authentification, à utiliser Owin, par rapport à une connexion classique (ou par ajax) ?

Salut et merci de l'intérêt que tu as porté à l'article.

Il y a plusieurs raisons d'utiliser la norme OWIN pour l'authentification :
La première est qu'elle permet de stocker dans le cookie d'authentification des informations personnalisées sur l'utilisateur (son nom, son prénom, mais surtout ses rôles applicatifs) avec les Claims.
Avec l'authentification "classique" (je suppose que tu veux parler de FormsAuthentication), on a bien la propriété UserData pour ça, mais c'est une chaîne de caractères qui n'est pas simple à gérer (plus d'infos ici).
La deuxième est qu'elle est implémentée en ASP.Net MVC, alors pourquoi s'en priver ?
La troisième est pour troller un peu : je n'ai jamais utilisé SignalR, mais il est apparemment possible d'utiliser l'authentification classique. Alors je te retourne la question : pourquoi avoir utilisé OWIN avec SignalR ?

Qu'entends-tu par "connexion par ajax" ?

Voilà, est-ce que ça répondu à ta question ?
Pour plus d'informations sur OWIN, voir l'article suivant : ASP.NET - Tutoriel sur OWIN

[stailer]

Ok merci pour tes précisions. J'ai lancé aujourd'hui un projet en ASP.NET MVC 5 (j'étais en 3 et un peu en 4 jusqu'à maintenant) et c'est vrai que Owin est là d'entrée de jeu.
Je vais me faire des petits tests avec ton article, sur le stockage d'infos utilisateurs.

Pour répondre à tes questions :

La troisième est pour troller un peu : je n'ai jamais utilisé SignalR, mais il est apparemment possible d'utiliser l'authentification classique. Alors je te retourne la question : pourquoi avoir utilisé OWIN avec SignalR ?

En fait j'ai pas touché à Owin mais ce que je voulais dire c'est qu'avec SignalR il est installé d'office et il faut le configurer dans ce qu'ils appellent les "HUB". exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
[assembly: OwinStartup(typeof(MonNamespace.MyHub1))]
namespace MonNamespace
{
 
    public class MyHub1 : Hub
   {
       ...
   }
}

Je découvre un peu et jusqu'à maintenant Owin était un peu une "boite noire" pour moi.

Enfin :

Qu'entends-tu par "connexion par ajax" ?

En fait je gère l'authentification en session et j'ai crée mes propres objets pour la sécurité et les droits (désolé, "Ajax" était un mauvais terme). Tout ce que fait FormsAuthentification ou ce que tu présentes dans l'article, finalement je le gère moi-même.

Mais je ne dis pas que c'est mieux ! au contraire. En voyant ton article je m'interroge justement sur le fait de "mélanger" l'authentification comme tu la présentes et un système de droit personnalisé pour mes futurs projets.

[Skalp]

Je découvre un peu et jusqu'à maintenant Owin était un peu une "boite noire" pour moi.

Oui, quand j'ai commencé aussi avec le projet MVC avec authentification, il y avait plein de code pré-configuré tout à fait inintelligible...

En fait je gère l'authentification en session et j'ai crée mes propres objets pour la sécurité et les droits (désolé, "Ajax" était un mauvais terme). Tout ce que fait FormsAuthentification ou ce que tu présentes dans l'article, finalement je le gère moi-même.
Mais je ne dis pas que c'est mieux ! au contraire. En voyant ton article je m'interroge justement sur le fait de "mélanger" l'authentification comme tu la présentes et un système de droit personnalisé pour mes futurs projets.

C'est un débat intéressant, tu pourrais démarrer un sujet sur le forum ?

[totof159]

Bonjour,
J'utilise aussi l'authentification owin, mais je n'arrive pas à comprendre un fonctionnement.

Dans votre projet github, pour lorsqu'on se connecte (login==mdp) ok, ensuite on navigue sur un onglet (home/about), on clique sur déconnecter (suppression du cookie etc.) on fait le précédent du navigateur et on tombe sur notre page (about) cela me semble être un comportement gênant Non ?

avez vous une solution ? ou est ce normal ?

merci

christophe

[DotNetMatt]

Si tu y as encore acces, c'est probablement parce que le cookie n'est pas supprime correctement apres l'appel a la methode de deconnexion.

Dans la methode AuthenticationController / Logout(), tu peux rajouter le type d'authentification, par exemple :
authenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie);

[totof159]

Bonjour,
J'ai bien fais authenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie); et regardé dans la navigateur si le cookie avait disparu et c'est bien le cas.
lorsque je clique sur un lien cela charge bien la page login mais c'est seulement le retour arriere qui affiche la page sans les données....

[DotNetMatt]

Je t'avoue n'avoir jamais fait ce genre de manipulation (revenir en arriere apres le sign out). En principe je dirais que tu ne devrais pas etre en mesure de voir la page. Peut-etre qu'il manque quelque chose dans le tuto ? Ou peut-etre que c'est une histoire de cache ?

Je regarderai ca ce soir, la je suis au taf (il est 10:35 AM ici) Entre temps si quelqu'un passe, n'hesitez pas

[Skalp]

Il s'agit effectivement du cache navigateur.
Si tu vides le cache (Ctrl+F5), tu retombes sur la page de login.

[totof159]

il s'agit a priori d'une histoire de cache navigateur ou session... mais je ne trouves pas cela très secure...
Imaginons, vous êtes sur votre compte bancaire vous déconnectez et quelqu'un passe derrière vous retour arrière et on affiche la page...

[Skalp]

il s'agit a priori d'une histoire de cache navigateur ou session... mais je ne trouves pas cela très secure...
Imaginons, vous êtes sur votre compte bancaire vous déconnectez et quelqu'un passe derrière vous retour arrière et on affiche la page...

Ce simple tutoriel ne montre que le strict minimum. Il est plutôt indiqué pour une application de gestion d'entreprise où il s'agit de limiter l'accès à une application et où les postes de travail sont nominatifs.

Il existe des façons très simples de prévenir l'affichage du cache en cas de retour arrière après une déconnexion.
Après une rapide recherche, j'ai pu trouver des choses comme ça :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Response.Cache.SetCacheability(HttpCacheability.NoCache);  // HTTP 1.1.
Response.Cache.AppendCacheExtension("no-store, must-revalidate");
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.

et au moment de la déconnexion :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Session.Abandon();
Session.Clear();
Session.RemoveAll();
authenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie);
Response.Redirect("/Home", false);

(NB : je n'ai pas essayé ces morceaux de code)

[totof159]

je ne me suis pas penché dessus, ok merci j'essaye ca

[totof159]

J'ai trouvé quelques choses de pas mal

Il faut tagué tous les contrôleurs avec:

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[OutputCache(NoStore = true, Duration = 0, VaryByParam = "None")]
public class xxxxxController : Controller
{
....
}

[katkiller]

Pour l’implémenter sur l'ensemble de tes "Controller" le plus simple est de l'ajouter de manière global dans la class "FilterConfig" qui est appeler dans App_Start.

[totof159]

Je valide. Cela fonctionne avec dans la class "FilterConfig" qui est appelée dans App_Start :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
filters.Add(new OutputCacheAttribute
{
   NoStore = true,
   Duration = 0,
   VaryByParam = "*"
});

[Skalp]

Je valide. Cela fonctionne.

Très bien !
Du coup, toutes les pages du site ne seront jamais mises en cache, à aucun moment.
Attention tout de même aux problèmes éventuels de performance, car le serveur sera sollicité à chaque appel de page.