用户控制的问题，急！
请教大家一个问题，我在做一个基于c#的asp.net的web程序，现在有个问题很麻烦，请各位高手帮我看看！

比如出现了下面的情况：2个不同的用户分别登陆填写自己的信息，但结果是：第一个用户的信息填到了第二个用户的名下，也就是说，第一个用户再次登陆的时候看不到自己的信息，而第二个用户登陆却看到了第一个人的信息，而第二个人自己的信息却看不到。。这是为什么呢？我很着急，谢谢大家帮我想想！

------解决方案--------------------
第一个用户的信息怎么会到第二个用户名下呢？好像没大看明白楼主的意思。
每一个用户都有自己唯一的id，所有信息都只对这个id操作就可以。
------解决方案--------------------
请说明你的用户登陆模型，基于Session，Cookies， Forms 验证 ......
详细提供出错场景
------解决方案--------------------
不太会出现这种情况吧，你是用什么来保存用户信息的，另外如果页面要区分不同的用户，就要使用seesion或者cookie来保存访问者。
------解决方案--------------------
你是不是用cookie了?

不要用静态的,你检查一下
------解决方案--------------------
曾经在MSDN上见过这样的一片文章，Session的信息有可能被其他用户访问到，具体的问题要搜艘了
------解决方案--------------------
http://www.microsoft.com/china/msdn/library/webservices/asp.net/WebAppFollies.mspx?mfr=true

会话和输出缓存
谈到输出缓存，ASP.NET 1.1 和 ASP.NET 2.0 都存在一个潜在的问题，该问题会影响在 Windows Server™ 2003 和 IIS 6.0 上运行的服务器中的输出缓存页。我曾经亲眼看到该问题在 ASP.NET 生产服务器中出现过两次，这两次都是通过关闭输出缓冲来解决的。后来我了解到有一个比禁用输出缓存更好的解决方案。以下是我第一次遇到该问题时的情况。

当时的情况是这样的，某个网站（我们在此称为 Contoso.com，它在小型 ASP.NET Web 领域中运行公共电子商务应用程序）与我的团队联系，抱怨他们遇到了“跨线程”错误。使用 Contoso.com 网站的客户常常突然丢失已经输入的数据，但却看到另一用户的相关数据。稍做分析即发现，跨线程这个描述并不准确；“跨会话”错误更为贴切。看起来 Contoso.com 是在会话状态中存储数据的，由于某些原因，用户会偶尔随机地连接到其他用户的会话。

我的一个团队成员编写了一个诊断工具，用来将每个 HTTP 请求和响应的关键要素（包括 Cookie 标头）记录到日志中。然后，他将该工具安装在 Contoso.com 的 Web 服务器上，并让其运行了几天。结果非常明显。大概每 100000 个请求中会发生一次这样的情况：ASP.NET 正确地为全新会话分配一个会话 ID 并返回 Set-Cookie 标头中的会话 ID。然后，它会在下一个紧相邻的请求中返回相同的会话 ID（即，相同的 Set-Cookie 标头），即使该请求已经与一个有效的会话相关联并且正确提交了 Cookie 中的会话 ID。实际上，ASP.NET 是随机将用户从他们自己的会话中切换出去并将他们连接到其他会话。

我们很惊讶，于是开始寻找原因。我们首先检查了 Contoso.com 的源代码，让我们感到欣慰的是，问题不在那。接着，为了确保问题与应用程序宿主在 Web 领域无关，我们只保留一个服务器在运行，而关闭了所有其他服务器。问题仍然存在，这并不意外，因为我们的日志显示匹配的 Set-Cookie 标头绝不会来自两个不同的服务器。ASP.NET 意外地生成了重复的会话 ID，这令人难以置信，因为它使用 .NET Framework RNGCryptoServiceProvider 类生成这些 ID，并且会话 ID 的长度足以确保相同的 ID 决不会生成两次（至少在下一个万亿年内不会生成两次）。除此之外，即使 RNGCryptoServiceProvider 错误地生成了重复的随机数字，也无法解释 ASP.NET 为何不可思议地将有效的会话 ID 替换为新的 ID（不唯一）。

凭直觉，我们决定看一下输出缓存。当 OutputCacheModule 缓存 HTTP 响应时，它必须小心不要缓存了 Set-Cookie 标头；否则，包含新会话 ID 的缓存响应会将缓存响应的所有接收者（以及其请求生成了缓存响应的用户）连接到同一会话。我们检查了源代码；Contoso.com 在两个页面中启用了输出缓存。我们关闭了输出缓存。结果，应用程序运行数天而没有发生一个跨会话问题。此后，它运行了两年多都没有发生任何错误。在具有不同应用程序和一组不同 Web 服务器的另一家公司中，我们看到完全相同的问题也消失了。就像在 Contoso.com 一样，消除输出缓存就能解决问题。

Microsoft 后来确认此行为源于 OutputCacheModule 中的问题。（当您阅读本文时，可能已经发布了更新。）当 ASP.NET 与 IIS 6.0 一起使用并且启用内核模式缓存时，OutputCacheModule 有时无法从它传递给 Http.sys 的缓存响应中删除 Set-Cookie 标头。下面是导致出现错误的特定事件顺序：

• 最近没有访问网站（因此也没有对应的会话）的用户请求一个启用了输出缓存的页面，但是其输出当前在缓存中不可用。

• 该请求执行用于访问用户最新创建的会话的代码，从而导致会话 ID Cookie 在响应的 Set-Cookie 标头中返回。

• OutputCacheModule 向 Http.sys 提供输出，但是无法从响应中删除 Set-Cookie 标头。

• Http.sys 在后续的请求中返回缓存响应，误将其他用户连接到会话。


故事的寓意又是什么呢?会话状态和内核模式输出缓存不能混合使用。如果您在启用输出缓存的页中使用会话状态，并且应用程序在 IIS 6.0 上运行，则您需要关闭内核模式输出缓存。您仍将受益于输出缓存，但是因为内核模式输出缓存比普通输出缓存快得多，所以缓存不会同样有效。有关此问题的详细信息，请参见 support.microsoft.com/kb/917072。

您可以通过在页面的 OutputCache 指令中包含 VaryByParam= "* " 属性来关闭单个页面的内核模式输出缓存，虽然这样做可能导致内存需求骤增。另一种更安全的方法是通过在 web.config 中包含下列元素来关闭整个应用程序的内核模式缓存：

<httpRuntime enableKernelOutputCache= "false " />

您还可以使用注册表设置来全局性地禁用内核模式输出缓存，即禁用全部服务器的内核模式输出缓存。有关详细信息，请参见 support.microsoft.com/kb/820129。

每次我听到客户报告会话发生了费解的问题，我都会询问他们是否在任何页面中使用了输出缓存。如果确实使用了输出缓存，并且宿主操作系统是 Windows Server 2003，我会建议他们禁用内核模式输出缓存。问题通常就会迎刃而解。如果问题没有解决，则错误存在于代码中。警惕!