2010-07-27 6 views
8

Je suis à la recherche de conseils sur les cookies dans ASP.Net MVC (ou simplement sur la gestion des cookies en général). J'ai stocké des informations d'authentification sur les utilisateurs qui s'authentifient via un formulaire de connexion dans un cookie. Cela fonctionne très bien, mais j'ai maintenant besoin de stocker un peu plus d'informations dans le cookie. Cette information supplémentaire n'est pas vraiment "liée à l'authentification" donc j'hésite à la stocker dans le ticket d'authentification. Y a-t-il une meilleure pratique pour stocker des informations supplémentaires. Est-il possible de définir plusieurs cookies (et si c'est le cas une bonne/mauvaise pratique)? D'autres choses que je devrais considérer ici?Meilleures pratiques concernant les cookies MVC d'ASP.Net

Voici le code actuel que je utilise pour régler le ticket d'authentification et l'envelopper dans un cookie:

private HttpCookie GetAuthCookie(AuthToken authToken) 
{ 
    var authTokenXml = serializationService.Serialize(authToken); 
    var authCookieString = FormsAuthentication.Encrypt(
     new FormsAuthenticationTicket(
      0, 
      Keys.AuthToken, 
      DateTime.Now, 
      DateTime.Now.AddMinutes(AppSettings.SessionTimeoutMinutes), 
      true, 
      authTokenXml)); 
    var cookie = new HttpCookie(FormsAuthentication.FormsCookieName, authCookieString) 
        { 
         Expires = DateTime.Now.AddDays(AppSettings.AuthCookieExpireDays) 
        }; 
    return cookie; 
} 

Répondre

2

Il y a une limite de taille à la taille d'un cookie peut être, 4096 octets. Après cela, vous devrez peut-être découper les données dans plusieurs cookies si vous souhaitez continuer à stocker dans les cookies. Évidemment, vous avez maintenant la complexité supplémentaire de lire de tous pour reconstruire votre ticket d'authentification + données et, si un cookie n'a pas été envoyé avec le reste, cela peut avoir des conséquences désastreuses.

Avez-vous envisagé d'utiliser un magasin de sessions différent? C'est effectivement ce que vous utilisez le cookie comme ici et à moins que ce soit lié à l'authentification et doit être disponible dans le pipeline de traitement avant que la session soit accessible, je serais enclin à envisager de mettre cette session en session. Vous pouvez utiliser une banque de sessions hors processus telle qu'une base de données si vous ne souhaitez pas stocker la session en cours.

+0

Oui, j'ai envisagé d'utiliser l'état de session SQL Server comme alternative à l'approche de cookie. Les données supplémentaires que j'ai besoin de stocker sont petites (probablement 20 caractères), donc il ne devrait pas ajouter trop de surcharge sur le fil ou en termes de taille de cookie. J'espérais éviter d'utiliser une base de données uniquement pour stocker cette information supplémentaire, à moins que ce ne soit vraiment la meilleure pratique, et c'est pourquoi j'ai posé la question ici. Merci pour vos commentaires. – Paul

+0

si ce n'est que 20 caractères, il ne fait probablement pas de mal dans le cookie. Si c'est si petit, utiliser la session in proc pourrait aussi être un bon choix. Peut-être essayer les deux façons et voir ce qui est préférable? –

1

Vous ne devez mettre que des données d'authentification dans le cookie d'authentification. Asp.net utilise les cookies de la même manière que sur n'importe quelle plateforme de programmation pour le web. Vous pouvez définir autant de cookies que vous le souhaitez et y stocker ce que vous voulez. Quelques exemples:

http://www.cookiecentral.com/faq/

http://stephenwalther.com/blog/archive/2008/07/08/asp-net-mvc-tip-15-pass-browser-cookies-and-server-variables-as-action-parameters.aspx

http://www.asp.net/general/videos/read-write-and-delete-cookies-in-aspnet

12

Règle générale: stocker dans le cookie que le minimum (ce qui est habituellement l'ID utilisateur) et utiliser ce minimum pour aller chercher le reste à partir de votre banque de données chaque fois que vous en avez besoin. Si vous êtes satisfait de la performance, vous pouvez arrêter de lire.

Si vous vous rendez compte que votre banque de données contient trop de requêtes, vous pouvez utiliser la session ou mettre en cache les résultats de vos requêtes.