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.