会话状态v ViewState [英] Session State v ViewState

问题描述

在我们的应用程序中，我们有一个"BasePage"，它声明了应用程序中每个页面或多或少要使用的许多属性.

In our application, we have a "BasePage" that declares a number of properties to be used by more or less every page in the app.

在这些属性中，它们写入ViewState.这些通常都是int或较小的字符串值，没有太大的意义.典型的用法是调用Web服务并保存一个ID，例如在页面内使用.

Inside these properties, they write to ViewState. These are all typically an int or small string value, nothing huge. Typical use is call a web service and hold an id for use within the page, for example.

我之所以使用viewstate是因为我担心会话变量的丢失(例如IIS回收).另外，我认为，很小的值不会对页面大小造成太大的影响.

I've used viewstate since I'm wary of the loss of session variables should IIS recycle for example. Also, I figured, very small values would not add hugely to the page size.

虽然我对会议过于偏执，这会是一个更好的选择吗?

Am I being overly paranoid about session though and would it have been a better option.

我们的环境是2个服务器群集，每个服务器上均具有SSL终止，负载均衡器维护着粘性会话-因此，使用In Proc并不是一个问题，我只是非常警惕.

Our environment is a 2 server cluster with SSL termination on each server, sticky sessions maintained by the load balancer - so using In Proc is not a problem per say, I'm just very wary of it.

推荐答案

从不信任您的用户发送的数据.

Never trust your user sent data.

即使您收到的所有数据都不敏感，如果将其发送到用户浏览器，也应在使用前再次检查.也许大多数用户都是合法的，但是只有一个用户可以破坏您的应用程序.

Even all data you receive is not sensitive, if you send it to your user browser, you should to check it again before use it. Maybe most users are legitimate, but just one can break your application.

您可以选择哪些存储数据?

What are your options to store data?

• 隐藏字段；可以很容易地在客户端进行篡改
• Cookie；保留用户特定数据的古老方法，但规模非常有限.
• ViewState;您的数据会使用带宽发送到客户端并返回，并且可能会被篡改.
• 会话，InProc；您永远不会有问题，直到应用程序池被回收
• 会话，状态服务器；您可以将会话数据保留在另一个服务器进程中.
• 会话，数据库；可以使用几乎(如果不是全部)负载平衡方案，因为您不需要坚持会议，也不必担心应用程序池回收.您所有的数据都属于我们您的SQL Server.

• Hidden field; can ve easily tampered at client side
• Cookie; ancient method to keep user specific data, but very size limited.
• ViewState; your data go to client and come back, using bandwidth and could be tampered.
• Session, InProc; your never have problems, until a application pool get recycled
• Session, State server; you keep your session data in another server process.
• Session, database; can work with almost (if not all) load balance scenarios, as you dont need stick sessions, nor to worry with app pools recycling. All your data are belong to us your SQL Server.

在阅读您的方案时，您可能需要处理进程外会话存储.

Reading your scenario, you probably need to deal with out-of-process session storage.

这篇关于会话状态v ViewState的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！