0

在我的应用程序的身份验证代码中，FormsAuthentication用于处理最复杂的部分，我已将可能的罪魁祸首缩小到运行应用程序到 BinaryFormatter 的某些机器上的环境问题。

在某些机器上，身份验证过程正确完成并且我的用户已登录。但是，在其他机器上，相同的输入BinaryFormatter会产生不同的结果（实际上是相同的，除非我遗漏了什么），从而破坏了身份验证过程并且用户永远无法登录在。

在正确的环境中，它会生成一个长度约为373的序列化字符串。在恶劣的环境下，产生的序列化字符串是5,024。问题就在这里。

以下是代码的运行方式：

var formatter = new BinaryFormatter();
var buffer = new MemoryStream();

formatter.Serialize(buffer, HttpContext.Current.User);

这反过来又弄乱了身份验证过程的其余部分，因为它本质上创建了一个包含大约 40,000+ 字节数据的 cookie，而该 cookie 永远不会创建 cookie（需要 4,096 字节或更少才能被浏览器接受）。

我的问题，它不容易测试（告诉我） -两台机器之间有什么不同会导致序列化差异？两者都在 Visual Studio 的 Windows 7 上开发并在内置的 Cassini 服务器上运行，但是否还有其他常见的陷阱会导致Serialize返回如此截然不同的结果？

4

1 回答 1

0

我的一个同事遇到了这个问题，看来问题确实出在序列化程序中：

我尝试使用 ASP.NET 基于角色的授权，并且需要为客户端浏览器中的角色生成 cookie。当我将 .NET 框架从 v4.0 升级到 v4.5 时。不再生成 cookie。经过测试和检查，我发现这是因为 RolePrincipal.ToEncryptedTicket() 返回的字符串文本比以前长了 10 倍，至少一个大于最大 cookie 长度 4,096。这就是 RoleManagerModule 无法为 asp.net 角色生成 cookie 的原因。当我卸载 .NET framework 4.5 并重新安装 v4.0 时，它又变成了正常情况。角色的 Cookie 再次出现在客户端浏览器中

[来源：http ://connect.microsoft.com/VisualStudio/feedback/details/759157/net-4-5-binaryformatter-serialization-generates-too-long-string ]

该页面上还有来自微软的回复，称他们已对其进行了调查（该页面是错误报告）并将其标记为已解决，因为这是设计使然。

删除 .NET 4.5 和 4.0，然后重新安装 4.0 对我有用 - 目前我的应用程序运行正常，我将研究重新处理 auth 部分来回避这个问题，所以它可以移动未来转向 4.5 框架。

于 2012-09-12T12:19:39.097 回答