为每个用户生成不同AntiForgeryToken的方法是什么
我正在使用带有 Razor 视图引擎的 MVC3。
我需要为每个用户生成不同的 AntiForgeryToken。
我正在考虑生成一个唯一的盐值，并在用户注册时将其存储在用户表中，并使用该盐来生成令牌，但是如何将该盐值绕过到属性ValidateAntiForgeryToken 。我认为我需要定义一个自定义属性，但我不知道如何进行（通过访问用户信息来使用盐值）。
提前致谢。
I'm using MVC3 with Razor view engine.
I need to generate a different AntiForgeryToken for each user.
I'm thinking of generating a unique salt value and store it in users table when the users registers, and to use that salt to generate the token, but how can I bypass that salt value to the attribute ValidateAntiForgeryToken. I think I need to define a customized attribute but I don't know how would that go (with getting access to user information to use the salt value).
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您想要不同的盐，那么您需要从现有代码中推出自己的盐或提出一个新方案。
但请记住，这些令牌已经是特定于用户的。以用户 A 身份登录的某人无法使用用户 B 会话中的令牌。
另请注意，它们不是一次性使用的令牌，那么您想在这里阻止什么？使用户 A 无法为用户 B 生成一个吗？再次 - 请记住用户 a 没有以用户 b 身份登录，因此如果这是伪造的，当前完成的检查将会失败。
If you want a different salt, then you'll need to roll your own off the existing code or come up with a new scheme.
However keep in mind, these tokens are already user specific. Someone logged on as user A cannot use a token from user B's session.
Also note they are not one time use tokens, so what are you trying to prevent here? Make it so user A cannot generate one for user b? again - keep in mind user a isn't logged on as user b, so the check that is currently done would fail if this is forged.
这是一个非常相似的问题，有一个很好的解决方案：
ValidateAntiForgeryToken Salt 值的运行时加载
基本上，您只需要创建一个 属性，它包装了 ValidateAntiForgeryToken 属性的功能，在运行时使用自定义盐值。
该解决方案的另一件伟大的事情是：该属性可以在控制器级别应用，自动应用于所有 POST 方法。
但是，正如其他人所说，MVC AntiForgeryToken 实现已经使用用户名来生成令牌，因此除非您别有用心，否则这样做不会为您带来任何好处。
Here's a very similar question with a great solution:
runtime loading of ValidateAntiForgeryToken Salt value
Basically, you'll just need to create an attribute that wraps the functionality of the
ValidateAntiForgeryTokenattribute, using a custom salt value at runtime.Another great thing in that solution: the attribute can be applied at the Controller level, automatically applying to all POST methods.
However, as others have said, the MVC AntiForgeryToken implementation already uses the username in generating the token, so unless you have ulterior motives, doing this won't gain you anything.