0

J'essaie d'implémenter un petit site ASP.NET MVC qui interagit avec un autre site. En bref, les sessions sont gérées entre le site principal et les sites satellites via des jetons dans l'URL. Je peux spécifier le format d'URL mais je ne peux pas supprimer l'exigence qu'un jeton de session soit soumis dans le cadre de l'URL. Je suis en train d'essayer de configurer le routage et suis dans quelques esprits ici. Je ne peux pas décider lequel serait le meilleur, ou s'il y a peut-être une meilleure façon de le faire. Les principales façons je pense:ASP.NET MVC a suggéré le routage pour l'URL avec le jeton de session

routes.MapRoute("Main", "{controller}/{action}/{id}/{token}"); 

comme URL Donne http://mysite.com/Products/Detail/5/5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f Pro: conserve la plupart du temps avec la convention existante MVC pour le site nagivation Con: Ajoute des complications à l'acheminement en soutenant les valeurs par défaut pour les ID et l'action.

routes.MapRoute("Main", "{token}/{controller}/{action}/{id}/"); 

URL comme http://mysite.com/5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f/Products/Detail/5 Donne Pro: routage simplifie - peut encore appliquer par défaut action/id selon convention standard MVC Con: très URL "comme un Web". Nécessite regex pour valider que la première variable est un GUID/jeton valide avant de passer à l'itinéraire suivant dans la table.

L'autre possibilité de venir à l'esprit, des séances passant comme:

http://mysite.com/Home/Index?session=5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f 

Le problème lié à c'est j'ai une classe de base dérivée de contrôleur qui toutes les autres pages sécurisées traversent. La classe SecureController remplace Execute() et vérifie la validité du jeton provenant de l'URL. Les deux approches (GET et routage) semblent être assez faciles pour obtenir le jeton dans la fonction Execute() du contrôleur, mais l'approche GET est plutôt collante, alors que l'approche de routage semble être, faute de meilleure explication, casser la élégance de la conception de routage MVC.

Est-ce que quelqu'un d'autre a pris un problème similaire et a eu des succès particuliers ou des difficultés à partager?

Répondre

2

Il semble que peu importe ce que vous faites, vos URL seront assez compliquées avec ce jeton.

J'ai également dû gérer ce type de fonctionnalité de connexion unique dans une application ASP.NET MVC, mais j'ai opté pour une approche légèrement différente et beaucoup plus simple: j'ai créé un GatewayController avec une action SignOn qui a jeton de session et une URL en tant que paramètres.

Ensuite, cette action SignOn vérifie simplement la validité du jeton de session, puis connecte l'utilisateur sur mon site, en redirigeant vers l'URL fournie. À partir de ce moment, le jeton de session n'est plus nécessaire, car l'authentification à partir de ce moment serait basée sur un cookie.

Cela peut ne pas être entièrement applicable dans votre cas, en fonction de vos besoins. Si vous devez vérifier en permanence la validité du jeton de session, vous pouvez toutefois faire la même chose que moi et stocker le jeton de session dans les données de session de l'utilisateur, ce qui vous permet de vérifier le jeton dans chaque requête.

+0

+1, c'est exactement ce qu'il faut faire. Authentification unique. –

+0

Sorte d'approche similaire à ce que je souhaite idéalement faire, sauf qu'il est impératif que chaque URL contienne le jeton. Semble inutile, mais parfois vous avez juste à jouer selon les règles ... – nathanchere