在未经身份验证的场景中使用 MVC3 AntiForgeryToken？
通过几个线程我可以看到在用户未经身份验证的站点区域中使用 MVC 防伪令牌是多余的。
我有一个应用程序，它从 site1、site2、site3 等向 mysite.com 发布一些信息。每个站点都有一个唯一标识符，该标识符通过异步 Javascript POST 在 POST 请求中发送。在 site1-3 上执行的 Javascript 在 mysite.com 上生成，然后返回到填充了一些 Javascript 变量的站点。
因此生命周期如下：
- site1 上的页面有一个对 mysite.com 的 Javascript 引用。
- 该链接引用是生成 Javascript 以返回 site1 的控制器路由。
- 返回的 JS 末尾包含一个 POST 请求，该请求返回到 mysite.com，其中包含 URL、浏览器等以及 site1 页面访问者的详细信息。
我可以在 JS POST 请求的接受控制器中很好地读取 POST 参数，但是，我想知道是否有必要将防伪令牌添加到参数列表中。
如果是这样，我必须在初始请求中生成它，并将其作为返回到 site1 的 JS 中的 JS 变量传递回来，然后在第二个请求中将其与表单 POST 一起传递回来。
由于只有在找到有效帐户的情况下才会在 mysite.com 上进行任何处理，因此这样做有什么意义吗？
如果是这样，我将如何在控制器级别生成防伪令牌？
Through several threads I can see that the use of the MVC antiforgery token is overkill on areas of a site where a user is not authenticated.
I have an application that posts some information to mysite.com from site1, site2, site3, etc. Each site has a unique identifier that gets sent in the POST request through an asynchronous Javascript POST. The Javascript that is executed on site1-3, is generated on mysite.com, then returned to the sites with some Javascript variables populated.
So the lifecycle is as follows:
- A page on site1 has a Javascript reference to mysite.com.
- That link reference is to a controller route that generates Javascript to return to site1.
- The end of the JS that is returned contains a POST request that goes back to mysite.com containing Url, browser, etc., details for the visitor of the page on site1.
I can read in the POST parameters just fine in the accepting controller from the JS POST request, however, what I wanted to know is if there is any point in adding an antiforgery token to the parameter list.
If so, I would have to generate it on the initial request, and pass it back as a JS variable in the JS returned to site1, then pass it back along with the form POST in the second request.
Since any processing on mysite.com will only occur if a valid account is found, is there any point in going through this?
If so, how would I generate the antiforgery token on at the controller level?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想说这取决于所发布数据的敏感性。如果其他用户可以通过伪造请求并提交请求来造成伤害（或烦恼），那么我会说这是适当的。听起来您只是在收集一些使用信息，因此情况不可能如此。
一次性随机数可能是更好的解决方案。这将使伪造请求变得困难，并防止错误的多次提交，例如用户使用缓存副本的情况。在 mysite.com 上生成一个随机值（GUID 可能有效），将其插入数据库并将其标记为未使用。通过 POST 将其发回。检查是否已被使用。如果未使用，则将其标记为已使用并执行日志记录操作。如果已使用，则将请求作为重复提交丢弃。
请注意，为此您不需要 POST，带有 URL 参数的简单 GET 就足够了，因为随机数将防止它被意外重复。
I would say that it depends on the sensitivity of the data that is being posted. If another user could cause harm (or annoyance) by crafting forged requests and submitting them, then I would say that it would be appropriate. It sounds like you're just collecting some usage information so that's not likely to be the case.
A one-time, random nonce might be a better solution. That would make it difficult to forge a request and prevent erroneous multiple submits, say from the user using a cached copy. Generate a random value (a GUID might work) on mysite.com, inserting it in the database and marking it as unused. Send it back with the POST. Check whether it has been used or not. If not used, then mark it used and perform your logging action. If it has been used already, discard the request as a duplicate submission.
Note that you wouldn't need a POST for this, a simple GET with URL parameters would be sufficient since the nonce will prevent it from being accidentally repeated.