Stockage de la totalité de la session dans un cookie a été standard dans les rails des dernières années - il y a un moyen facile d'atteindre quelque chose de similaire avec ASP MVC?
Par défaut, n'importe quoi dans Session / Tempdata est stocké en mémoire sur le serveur. Dans web.config, cela peut être modifié en un cache SQL Store / Server. J'aimerais pouvoir avoir ces objets persistais dans un cookie.
On dirait que je pouvais implémenter un fournisseur de magasin de session personnalisé. Y a-t-il une approche plus simple?
6 Réponses :
dépend de quel type de données vous souhaitez stocker dans le cookie, si vous voulez simplement stocker une chaîne, le code suivant fera:
HttpCookie cookie = new HttpCookie("username","sth");
cookie.HttpOnly = true;
cookie.Expires = DateTime.Now.AddMonths(3);
HttpContext.Current.Response.Cookies.Add(cookie);
Vous ne devriez pas utiliser des sessions pour cela, mais des profils à la place. Les profils utilisent des cookies pour correspondre aux ordinateurs vers des profils, etc. La clé de profil est stockée dans un cookie et n'est pas perdue lors de la fermeture du navigateur, etc.
info ici; http://odetocode.com/articles/440.aspx
Je décourage vivement à stocker toute la session dans les cookies. Il a des implications de mauvaises performances. Considérez ceci: chaque demande (à chaque ressource) contiendra une surcharge de données obsolètes que vous n'avez besoin qu'une seule ou deux fois. Finalement, ces frais généraux vont frapper vos utilisateurs, votre bande passante et vos performances de votre site.
Voici un exemple: P>
GET / HTTP/1.1 Host: localhost OtherUsefulHeaders: foo Cookie: YourSessionState=...
Comment maintenir les informations de session via TempData (implémentées via un magasin de cookies) est-elle plus rapide? Il y a aussi le code supplémentaire au-dessus de la maintenance de cette tempdata. Une session doit être assez légère - dans notre cas, il s'agit d'une douzaine d'octets - de sorte que les frais généraux de la demande devraient être minimes. Un magasin de session basé sur les cookies a été adopté en standard dans Rails en 2007. Cet article explique pourquoi ils ont fait ce mouvement. Ryandaigle.com/ Articles / 2007/2 / 21 / ...
Je suis très heureux pour la communauté des rails, mais mon point est basé sur des données statistiques: YUIBLOG.COM/BLOG/2007/03/01/PERFORMANCE-RESEARCH-PART-3 . Tempdata est avantageux sur la session en ce que ses frais généraux ne s'appliquent qu'une seule fois - lors d'une page aller-retour. Sinon, les cookies devraient être propres. Quoi qu'il en soit, après une expérience amère dans un scénario de ferme Web, je n'utilise pas du tout une session, cela ne vaut pas la peine.
Quelle méthode utilisez-vous maintenant pour l'état de la session? J'aurais pensé que l'objet de la session (que ce soit Inproc ou non) ou un cookie sont les seuls choix?
@UPTHECREECK - J'écris du code qui ne s'appuie pas sur l'état de la session. Chaque information peut être reconstruite à partir de la demande (y compris des cookies) ou stockée dans le cache / dB (s'il est coûteux de ré-calculer).
Oui, implémentez un fournisseur de session sur mesure . Et non, Afaik il n'y a pas une approche plus simple.
ps. Ce n'est pas aussi mauvais qu'il a l'air, c'est-à-dire que la moitié du échantillon ODBC écrit à la DB.
Suite à cela, j'ai mis en place un fournisseur de session d'état personnalisé et c'était bien simple. Merci pour l'aide.
Je pense qu'il serait beaucoup plus efficace de stocker l'ID de session (un hachage ou autre chose) dans le cookie, puis utilisez cet identifiant pour obtenir les données de session de la mémoire / de la base de données / quel que soit le stockage que vous préférez. Garder l'état de la session complète dans un cookie augmente insuffisamment la bande passante.
Aussi, gardez la sécurité à l'esprit: Si le cookie contient des informations d'authentification ou d'autres données sensibles et que vous n'êtes pas prudent, il peut facilement être piraté par l'utilisateur pour obtenir des privilèges ou autrement gâcher avec votre application (crypter les données craint aussi. , parce que vous devez ensuite baser-64 encoder les données cryptées, qui gaspillent davantage la bande passante et le temps de traitement). Vous devriez jamais saisie de confiance de l'utilisateur.
Un magasin de session personnalisé serait-il nécessaire dans ce cas ou serait-il simplement logique de désactiver la session dans le web.config?
Je recommande de stocker Pour stocker Il existe en fait un package Nuge disponible (qui correspond à cette implémentation personnalisée pour vous): brockallen.cookietempdata et Voici la documentation . La bonne chose à propos de ce paquet est que cela compresse et crypte votre Tout ce dont vous avez besoin pour Faire est d'installer le package Nuget, puis de remplacer tempdata code> dans la cookie (par opposition à toute la session). templdata code> dans la cookie, vous devez remplacer itempdataProvider Code> et implémentez votre propre fournisseur personnalisé. P> templdata code>, vous n'avez donc pas besoin de vous soucier de l'envoi de texte brut sur Internet. P> CreateTempDataProvider code> dans votre contrôleurbase code> Classe: p> using BrockAllen.CookieTempData;
namespace myProject.web.Controllers
{
public class ControllerBase : Controller
{
// use CookieTempDataProvider instead of default provider
protected override ITempDataProvider CreateTempDataProvider()
{
return new CookieTempDataProvider();
}
}
}
Voulez-vous dire «une session entière dans un cookie»?