这仅在安全上传时被调用。我猜你过去曾配置过它,但后来移除了。
这段代码返回什么?
./launcher enter app
rails c
> Upload.where('secure').count
cc @martin
(另外,site_setting.rb:157:in absolute_base_url' 中存在一个命名错误,它应该被称为 s3_absolute_base_url)
这仅在安全上传时被调用。我猜你过去曾配置过它,但后来移除了。
这段代码返回什么?
./launcher enter app
rails c
> Upload.where('secure').count
cc @martin
(另外,site_setting.rb:157:in absolute_base_url' 中存在一个命名错误,它应该被称为 s3_absolute_base_url)
嘿,Sam,
非常感谢你花时间查看这个问题!
据我所知,我们并没有启用安全上传功能。但由于我不是唯一的管理员,所以无法完全确定。如果我的理解没错,如果该功能从未被启用过,你的查询结果应该返回 0 对吧?但实际情况远不止 0 哦
235 条记录呢 ![]()
返回结果如下:
[1] pry(main)\u003e Upload.where('secure').count
=\u003e 235
[2] pry(main)\u003e
有什么我可以做的来修复这个问题吗?
我应该停用 seucure media allow embeded images in emails 这个设置吗?
或者,先启用 secure media 然后再停用它,这样值得尝试一下吗?
非常感谢你在这里尽力帮忙!
如果您当前未启用安全媒体,则无需启用。鉴于您拥有大量安全上传内容,该功能必定曾在某时启用。请尝试运行 uploads:secure_upload_analyse_and_update Rake 任务;该任务将遍历您的所有上传内容,并根据站点设置将其标记为安全或不安全(如果您已禁用安全媒体,则所有上传内容均会被标记为不安全)。
嘿,Martin,
非常感谢。我今晚就会尝试一下。
只是想跟你确认一下。我们目前启用了:
我们是否也需要切换这个选项?还是说这不会影响标记过程?
另外,为了明确起见,在执行 rake 命令后,我需要重新构建应用吗?还是说这并非必要,但可能建议这样做?
非常感谢!
此选项默认启用,但除非启用了 Secure Media,否则不会生效。
我认为重新构建并非必要,我已在生产环境中运行过此操作,未出现任何问题。
非常感谢!
我试试看,明天汇报结果。
谢谢谢谢!
我猜,回溯信息看起来像是在尝试序列化消息列表或来自消息的信息列表,但在序列化某张特定图片时失败了。这张图片很可能是用户的头像。目前只有一个账户受到影响,因此这张有问题的图片可能属于仅与该受影响账户进行过交流的用户。
也许导致失败的列表构建是针对最近 N 条消息的。或许你可以向该受影响账户发送 N 条消息(使用不同的主题标题),这样列表中就只包含正常的消息了?
Martin,再次感谢你的提示。
我尝试运行 rake uploads:secure_upload_analyse_and_update,但输出显示:
此任务仅适用于外部存储。
于是我尝试启用“激活安全媒体”选项。但不幸的是(或者说,为了避免管理员操作失误),该选项只能通过配置 Amazon S3 存储桶来启用。而我非常确定,从来没有人做过 S3 配置。
因此,由于没有可用的 S3 存储,我无法运行该 rake 脚本,也就无法判断它是否会影响 pry(main)> Upload.where('secure').count 的结果。
我很疑惑:既然从未启用过 S3,为什么我们仍然存在一些安全上传(secure uploads)?
对此有什么线索吗?
不过实际上,
这个方法奏效了。所以我目前没问题。尽管我仍然不清楚为什么会遇到这种行为。我很乐意了解其他可能的原因。
提前感谢,也感谢你们已经付出的所有时间。
好吧,Ed_S,除了这句话我还能说什么呢:
事实上,你那个小小的提示起了作用。我只是写了一条新消息,又发布了另一个回复,然后错误就消失了。
即使你现在是我的英雄,也不能免除我继续提问的责任
希望你愿意让我更深入地理解这里到底发生了什么。
首先,为了让我更好地理解如何阅读日志。我是说,你的猜测太棒了。是什么让你想到序列化问题可能是导致故障的原因?
lib/url_helper.rb:90:in `cook_url'
app/models/topic.rb:126:in `image_url'
app/serializers/listable_topic_serializer.rb:34:in `image_url'
为什么不是 cook_url,或者我不知道,其他什么地方呢?
其次,你的经验是什么?我是否需要留意再次遇到这类问题?或者可能是其他用户也会遇到?
你觉得有没有办法缩小范围,找出是哪条消息、哪个用户或哪张图片导致了这个问题?除了……逐条点击消息并希望在某条私信帖子中产生效果之外,还有其他办法可以查看吗?
有趣的是,一些管理员刚刚做了完全相同的事情,比如向受影响的账户发布新消息(主题),但我们并没有观察到其他异常行为。不知为何,我发给该受影响账户的最后一条消息起了作用。
最后,我可以要你的电话号码以便将来紧急联系吗?开玩笑的! ![]()
但说真的,非常感谢,非常非常感谢,超级超级感谢。我真的在这里卡住了,非常高兴我们的用户——正如我提到的,是我们的一位管理员——能够重新回到正轨。谢谢你,Ed_S!
猜得非常棒!
哈哈,看来我运气不错。堆栈跟踪的特点是从具体到一般——它不仅仅是一个事物列表,而是一幅从通用代码到具体机制的嵌套交互图。因此,“图像”这个想法显得很有趣,因为消息列表中只有头像。而且我认为我们以前也遇到过头像相关的奇怪问题。
不过,如果你从未使用过安全存储,我完全不明白代码为何会去检查它。
我怀疑可以通过数据库查询列出在这种情况下会被获取的图像,但我不确定如何找到那个异常的头像。如果这确实是堆栈跟踪背后的原因的话。
有一个 rake 任务可以修复此问题:
./launcher enter app
rake uploads:secure_upload_analyse_and_update
建议您运行该命令。
嘿,Sam,
非常感谢你仍然将此事列入待办清单。我很高兴能继续得到你的协助,以确保问题得以解决。
我尝试了:
但实际输出的结果是一样的,提示该命令仅适用于外部 S3 存储。由于我们尚未配置外部存储,我现在有点不知所措。
以下是我的控制台输出:
./launcher enter app
rake uploads:secure_upload_analyse_and_update
This task only works for external storage.
我是否遗漏了什么?还是这是一个 bug,在关闭 secure media 后本应可以正常运行?
感谢你的专业指导。
其实,有时候正是运气让我们得以幸存,对吧?
不过还是要谢谢你。我确实有点沮丧,删除所有消息真的是最后才考虑的选择。
也许你能给我一些关于这些话题的提示。对我来说,作为 Docker 和 Discourse 的新手,你建议执行数据库查询让我有些摸不着头脑。Discourse 使用的是什么数据库?我能不能这样做:
./launcher enter app
mysql select bla
还是用的是 MongoDB?不过,进入容器并在其中执行查询至少是正确的方向,对吧?
另外,有没有字段或属性的列表可以参考,或者类似的东西,让我能据此构思出正确的查询语句?
但为了明确一点:即使我成功获取了收件箱列表中所有头像的列表,是否仍然没有建议来缩小范围,判断哪一个是“坏人”,或者即使找到了也不知道该怎么做?对此你有什么想法吗?
此外,我有点惊讶头像问题竟然如此常见。有没有相关主题可以阅读,以便更深入地了解这一点?或者有没有关于如何处理头像、限制使用等方面的指南,以避免此类问题?
Ed_S,非常感谢你一直陪伴我。
我对数据库方面了解不多,但我推荐使用 Data Explorer 插件,这是一个官方支持的插件,以及 这个主题。(如果有新问题,最好开启一个新主题——这样其他人也能从讨论中受益,而且一个合适的主题标题能吸引更多帮助。)
编辑:也可以参考
其中包含了一些关于其机制的线索,以及你可能如何对其进行查询。
嘿,Ed_S,
非常感谢你的提示。Data Explorer 插件太棒了!对于进一步分析来说,这绝对是一个绝佳的起点!
关于丢失头像的提示也很有帮助。我检查了一下,看起来一切正常。再次感谢你分享这些见解。
目前一切运行良好,我非常满意。希望它能一直顺利下去 ![]()
再次感谢 Ed_S 持续的帮助。
如果其他人也遇到类似错误,请告诉我你们的经历,或者有什么方法可以预防此类问题。
感谢各位的阅读。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.