2009-10-08 12 views
1

J'ai un site qui utilise le SqlMembershiprovider. C'est une boutique en ligne. L'utilisateur se connecte avec son nom d'utilisateur et son mot de passe. En dehors de cela, il y a un contrôleur qui est responsable de l'affichage des détails de livraison pour les commandes, qui sont importés à partir d'un autre système. Ces commandes n'ont aucune connexion avec les utilisateurs du système d'appartenance. Pour afficher les détails de la livraison, vous devez indiquer le numéro de commande et un jeton imprimé sur la facture.Multiple Membershipprovider pour une application

Pour autoriser l'accès, je voudrais implémenter un fournisseur de membre personnalisé qui est utilisé uniquement pour ce contrôleur unique. Est-il faisable d'utiliser 2 fournisseurs différents pour une application?

EDIT

Il y a deux ou trois pages que l'utilisateur peut accéder à une fois qu'il a fourni le numéro de commande et le jeton.

Répondre

1

Je ne pense pas que vous ayez besoin d'un fournisseur d'appartenances distinct. Il suffit de rendre publique cette action et les actions associées (ne pas décorer avec AuthorizeAttribute). Ensuite, exigez que le numéro de commande et le jeton de facture fournis soient valides. C'est-à-dire que si vous avez le numéro de commande et son jeton associé, vous pouvez afficher les détails de la livraison. Vous pouvez vérifier cela en vérifiant simplement qu'ils correspondent dans les données fournies par l'autre système.

[AcceptVerbs(HttpVerbs.Post)] 
public ActionResult DeliveryDetails(string orderNumber, string invoiceToken) 
{ 
     var order = otherDb.Orders 
         .Where(o => o.OrderNumber == orderNUmber 
             && o.InvoiceToken == invoiceToken) 
         .SingleOrDefault(); 

     if (order == null) 
     { 
      return View("Error"); 
     } 

     return View(order); 
} 
+0

Le problème est que j'ai deux ou trois pages qui ont besoin de ce logininformation. Je dois vraiment avoir un cookie d'authentification. Je mets à jour ma question pour inclure cette information. –

+0

Je pense que je ferais cela basé sur une variable de session au lieu d'un cookie. Créez un attribut de filtre d'action personnalisé qui vérifie si l'utilisateur est autorisé OU s'il possède un indicateur de session indiquant qu'il possède un jeton de commande/facturation valide. Cela vous évitera d'avoir à utiliser des rôles spéciaux pour distinguer les utilisateurs authentifiés normaux de ces "invités" et vous permettre de continuer à utiliser le AuthorizeAttribute par défaut ailleurs. – tvanfosson

Questions connexes