您好,
我有一个机器人用户,它通过 API 执行大量任务。该用户是受信任用户且拥有管理员权限,但本周却因某种原因被两次停用。我在员工操作日志或错误日志中均未发现任何能提示用户被停用原因的线索。
您能否提供帮助?无论是告知应查看哪些日志,还是说明系统停用用户的潜在原因,都感激不尽。
此致
Pekka
您好,
我有一个机器人用户,它通过 API 执行大量任务。该用户是受信任用户且拥有管理员权限,但本周却因某种原因被两次停用。我在员工操作日志或错误日志中均未发现任何能提示用户被停用原因的线索。
您能否提供帮助?无论是告知应查看哪些日志,还是说明系统停用用户的潜在原因,都感激不尽。
此致
Pekka
我想可能是 InvalidateInactiveAdmins 脚本导致的,看起来它不会生成日志条目。有人能确认一下吗?因为我对源代码的具体细节不太熟悉。
是的,没错。我们确实应该为此添加一条日志——如果您不了解该功能,这可能会非常令人困惑。我会将其列入我的待办事项清单。
如果您运行的是最新版本的 Discourse,那么我们最近已在停用管理员账户之前增加了一些额外的检查:
如果该用户已发布帖子,或关联了最近使用过的 API 密钥,则不会将其停用。请注意,该 API 密钥必须专门关联到该用户,而不是“所有用户”密钥。
是的,我看到了,可惜我还在使用较早的版本。
我建议进行更新,但如果无法更新,您还有几个选择:
“模拟”该账户,这样它就不会在一年内被停用
将 invalidate_inactive_admin_email_after_days 设置为更高的数值,或设置为 0 以禁用该功能
我们做了第二个,等待几天看看是否会再次发生,根本原因判断错误。
上次更新时,关于标记机制的问题引发了大量争议,因此除非别无选择,我们将不再进行更新。
希望你喜欢安全漏洞,哈哈:rofl
我意识到不更新会带来一些问题:我们对 Discourse 的使用方式并不标准,而且实际 Discourse 服务器并未被用户直接访问,仅作为后端使用,因此我认为目前我们暂时没问题。
但更大的问题在于,用户因行为变更而感到不满,而团队又不愿添加选项以恢复旧版行为,导致我们无法撤销这一变更。