嘿！你好吗！？
我一直在围绕基于当前用户信息的逻辑安全开展工作，比如“如果 topic.creator.username 等于 User.current().username"，我就允许用户编辑或删除该主题。
问题的关键在于，我需要确保某些操作基于用户会话来执行！但我已经进行了一些测试，所以现在来向各位请教。
通过网页浏览器中的 JavaScript（即使在生产模式下），我也可以执行 Discourse.User.current().set(‘username’, ‘sometestename’)。这样一来，仅凭这一更改，系统中的一些操作就会被启用。我知道这并不是 99% 用户的目的，但除此之外，各位是否知道有什么方法可以确保用户无法篡改用户信息？
此致，
Felipe
如果你在本地浏览器中修改信息，这并不会对后端产生任何影响。
用户是通过身份验证令牌登录的，我相信是这样，因此你无法在后端冒充其他任何人：
由于无法欺骗服务器，你将无法以其他用户的身份进行任何更改。
一旦你刷新浏览器，本地的更改很可能会被清除。最坏的情况是，你可能会搞乱 JavaScript 应用状态，不得不清除缓存。
嘿！没错！
正如你所说，最好的做法是始终从后端服务器获取当前用户的会话。
这样一来，浏览器中的缓存更改就无法产生影响！你知道哪里可以确认逻辑安全是基于后端服务器的用户会话，而不是基于 PreloadStore 吗？
如果我理解有误，请随时指正！感谢 Robert 的帮助！
此致，
Felipe
我并非安全专家，只是一名应用开发者，但所有持久化更改都只能在服务器端进行。在 EmberJS 中浏览器端发生的一切，都是为了用户便利和更优质的使用体验，例如缓存以提升速度、自动实现类应用界面的交互行为。但这并不改变一个事实：最终所有持久化更改都必须与 Rails 服务器协商，且在此过程中，仅允许执行已登录用户的操作。
所有数据检索亦是如此——Rails 服务器只会向已登录用户发送其有权访问的数据。
我认为你无需为此担心，因为如果有人试图绕过这一机制，他们会在第一道关卡就失败：无法欺骗 API。
你的具体顾虑是什么？
您应首先在后台开发所有安全措施。
Rails 序列化器决定了哪些数据会被发送。
Guardian 负责保护允许执行的操作。
所有这些都由 Rails 控制器进行管理。
无论前端发送了何种无效数据或请求获取什么内容都无关紧要，因为这些元素会保护服务器。
您可以在前端行为中镜像这一机制，但前端并非守门人。
查看一些较大的插件，您就能看到序列化器的示例以及 Guardian 的使用方式。
谢谢你，Robert，我正好需要这些反馈！
我一定会仔细查看！
此致，
嘿，Robert！
我一直在分析关于帖子控制（操作）的插件代码和代码库，以评估我在安全性方面能做出哪些改进。
正如分析所示，在前端有若干步骤用于确保用户是否有权编辑帖子，例如：
不过，即使前端被篡改，一旦请求被发送到后端服务器，在 posts_controller.rb 的 update 方法中：
def update
Rails 会再次获取帖子，进行最终的检查：
感谢你的见解！
这真是太棒了。
干得漂亮。很高兴你能坚持下来并深入挖掘 