Closed ccjaread closed 5 months ago
sorry to say, but the codes changes seems more vulnerable than previous commit.
unlimited
and >1 will count useAmount) - this will reduce huge amount of I/O operation on mongoDB.sorry to say, but the codes changes seems more vulnerable than previous commit.
- default useAmount is sent from frontend and calculates on backend.
- backend reports useAmount value at no-login situation (unnecessary API calls and data)
- useAmount is read by frontend on separate route (additional API call)
- limit_switch should affect globally not by every user. default useAmount of every user should have unlimited value (something like 0 means unlimited, which reports to frontend with
unlimited
and >1 will count useAmount) - this will reduce huge amount of I/O operation on mongoDB.- Can't see any frontend code to manage or generate Gift card
thank you for the opinions, some of those I had considered
抱歉要说,但这次代码更改似乎比之前的提交更容易受到攻击。
- 默认的 useAmount 从前端发送并在后端计算。
- 后端报告在无登录情况下使用金额值(不必要的API调用和数据)
- useAmount 在前端通过单独的路由读取(额外的 API 调用)
- 限位开关应该全局影响,而不是每个用户。每个用户的默认使用量应该具有无限制的值(类似于0表示无限制,向前端报告为
unlimited
,而>1将计算使用量)- 这将减少对mongoDB的大量I/O操作。- 看不到任何前端代码来管理或生成礼品卡
谢谢您的意见,其中一些我已经考虑过
- 关于前端显示的默认使用金额,我本意是尽可能地重复使用用户编辑API和首页,而不是在兑换后添加新页面来计算使用金额,用户信息更新和兑换的混合会导致事情变得模糊(即从用户信息或礼品卡信息中读取useAmount)。我认为通过用户注册API设置默认的useAmount并在将来为兑换功能设置一个新页面是正确的做法,这样所有金额计算将由后端处理。
- 在无登录情况下,后端使用量报告实际上不会发生,使用量是在挂载常规设置页面时读取的,如果没有登录,这种情况不会发生。在其他情况下,使用量信息是同步读取的,因为它包含在用户信息中,因此不会生成额外的读取操作。
- 如2中所解释,useAmount信息由userinfo同步读取,对于这种情况不需要额外的api调用。但是从兑换卡部分读取useAmount是额外的,我认为这个操作频率较低,所以不应该对性能产生太大影响。
- 关于限位开关的有效范围,我不知道哪个更好。但开关标签也在用户信息中,因此不会产生大量额外的I/O流量。但我也注意到,通过getUserById函数获取用户信息和将房间/聊天/信息更新到数据库的原始代码可能不适用于大量流量的情况,因为这些函数会被每次对话重复调用。
- 对于目前的不便,我感到抱歉,我只是简单地认为个人用户不需要礼品卡系统。我认为最好通过其他工具生成和管理礼品卡数据。例如,您可以通过免费的MongoDB Compass GUI加载一个csv文件,csv文件只需要包含卡号、金额和已兑换标记的数据。
您好,非常感谢您修复了500的问题,我使用了您的pull,在每次完成对话后,后台会报错:
MongoServerError: Cannot apply $inc to a value of non-numeric type. {_id: ObjectId('65db464c729646046450dd6a')} has the field 'useAmount' of non-numeric type null
at
at
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
index: 0,
code: 14,
[Symbol(errorLabels)]: Set(0) {}
}
还有一个问题,就是对话输出可能会不完整,我以为是API的问题,结果我登出再登录发现输出变成完整的了,这是什么情况呢?
抱歉要说,但这次代码更改似乎比之前的提交更容易受到攻击。
- 默认的 useAmount 从前端发送并在后端计算。
- 后端报告在无登录情况下使用金额值(不必要的API调用和数据)
- useAmount 在前端通过单独的路由读取(额外的 API 调用)
- 限位开关应该全局影响,而不是每个用户。每个用户的默认使用量应该具有无限制的值(类似于0表示无限制,向前端报告为
unlimited
,而>1将计算使用量)- 这将减少对mongoDB的大量I/O操作。- 看不到任何前端代码来管理或生成礼品卡
谢谢您的意见,其中一些我已经考虑过
- 关于前端显示的默认使用金额,我本意是尽可能地重复使用用户编辑API和首页,而不是在兑换后添加新页面来计算使用金额,用户信息更新和兑换的混合会导致事情变得模糊(即从用户信息或礼品卡信息中读取useAmount)。我认为通过用户注册API设置默认的useAmount并在将来为兑换功能设置一个新页面是正确的做法,这样所有金额计算将由后端处理。
- 在无登录情况下,后端使用量报告实际上不会发生,使用量是在挂载常规设置页面时读取的,如果没有登录,这种情况不会发生。在其他情况下,使用量信息是同步读取的,因为它包含在用户信息中,因此不会生成额外的读取操作。
- 如2中所解释,useAmount信息由userinfo同步读取,对于这种情况不需要额外的api调用。但是从兑换卡部分读取useAmount是额外的,我认为这个操作频率较低,所以不应该对性能产生太大影响。
- 关于限位开关的有效范围,我不知道哪个更好。但开关标签也在用户信息中,因此不会产生大量额外的I/O流量。但我也注意到,通过getUserById函数获取用户信息和将房间/聊天/信息更新到数据库的原始代码可能不适用于大量流量的情况,因为这些函数会被每次对话重复调用。
- 对于目前的不便,我感到抱歉,我只是简单地认为个人用户不需要礼品卡系统。我认为最好通过其他工具生成和管理礼品卡数据。例如,您可以通过免费的MongoDB Compass GUI加载一个csv文件,csv文件只需要包含卡号、金额和已兑换标记的数据。
您好,非常感谢您修复了500的问题,我使用了您的pull,在每次完成对话后,后台会报错:
MongoServerError: Cannot apply $inc to a value of non-numeric type. {_id: ObjectId('65db464c729646046450dd6a')} has the field 'useAmount' of non-numeric type null
at (/app/node_modules/.pnpm/mongodb@5.9.2/node_modules/mongodb/src/operations/update.ts:154:44)
at (/app/node_modules/.pnpm/mongodb@5.9.2/node_modules/mongodb/src/operations/command.ts:173:14)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
index: 0,
code: 14,
[Symbol(errorLabels)]: Set(0) {}
}
还有一个问题,就是对话输出可能会不完整,我以为是API的问题,结果我登出再登录发现输出变成完整的了,这是什么情况呢?
登出再登录我发现没必要,只要刷新页面就会显示出完整的答案。
MongoServerError: Cannot apply $inc to a value of non-numeric type. {_id: ObjectId('65db464c729646046450dd6a')} has the field 'useAmount' of non-numeric type null
ping @ccjaread Can you please take a further look at this feedback?
Fixes #435 Fixes #436 Fixes #438 Fixes #442 Fixes #446 Fixes #447