chatgpt-web-dev / chatgpt-web

A third-party ChatGPT Web UI page built with Express and Vue3, through the official OpenAI completion API. / 用 Express 和 Vue3 搭建的第三方 ChatGPT 前端页面, 基于 OpenAI 官方 completion API.
https://chatgpt-web.dev
MIT License
1.6k stars 440 forks source link

fix: 5xx error when open index page before login #440

Closed ccjaread closed 5 months ago

ccjaread commented 6 months ago

Fixes #435 Fixes #436 Fixes #438 Fixes #442 Fixes #446 Fixes #447

Urmi10799 commented 6 months ago

sorry to say, but the codes changes seems more vulnerable than previous commit.

  1. default useAmount is sent from frontend and calculates on backend.
  2. backend reports useAmount value at no-login situation (unnecessary API calls and data)
  3. useAmount is read by frontend on separate route (additional API call)
  4. 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.
  5. Can't see any frontend code to manage or generate Gift card
ccjaread commented 6 months ago

sorry to say, but the codes changes seems more vulnerable than previous commit.

  1. default useAmount is sent from frontend and calculates on backend.
  2. backend reports useAmount value at no-login situation (unnecessary API calls and data)
  3. useAmount is read by frontend on separate route (additional API call)
  4. 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.
  5. Can't see any frontend code to manage or generate Gift card

thank you for the opinions, some of those I had considered

  1. about default useAmount what you see in frontend, I was intended to maximum reuse the user-edit api and front page instead of adding a new page to calc usage amount after redeem, and the mix of user info update and redeem has the defect of making things fuzzy(i.e reading useAmount from user info or the gift card info). I think it's right to set the default useAmount through user-register api and set a new page for the redeem function in the future, so all the amount calc would be hold by the backend
  2. at no-login situation backend useAmount reports actually won't happen, the useAmount is read when the general setting page is mounted which won't happen if no-login. and in other situations the useAmount information is synchronously read because it is included in the userinfo, thus no additional read operation is generated.
  3. as explained in 2,useAmount information is synchronously read by userinfo, no additional api calls for this situation. But the read of useAmount from the redeem card part is additional, and I think this action is at a low frequency, so it shouldn't affect the performance much
  4. about the scope of effectiveness of limit_switch I have no idea which is better. But the switch_tag is also in user info , so no huge additional I/O traffic is made. But I also noticed that the original code of getting user info by the function getUserById and the update of room/chat/info to the DB maybe not suitable for huge traffic situations as those function are called repeatedly by every conversation.
  5. I am sorry for the un convenience for now, I just simply thought personal users won't need the gift card system. And I think it's better to generate and manger the giftcard data by other tools. As an example, you can load a csv by the free MongoDB Compass GUI, the csv just needs data which contains cardno,amount and redeemed tag.
Noah-Wu66 commented 6 months ago

抱歉要说,但这次代码更改似乎比之前的提交更容易受到攻击。

  1. 默认的 useAmount 从前端发送并在后端计算。
  2. 后端报告在无登录情况下使用金额值(不必要的API调用和数据)
  3. useAmount 在前端通过单独的路由读取(额外的 API 调用)
  4. 限位开关应该全局影响,而不是每个用户。每个用户的默认使用量应该具有无限制的值(类似于0表示无限制,向前端报告为 unlimited ,而>1将计算使用量)- 这将减少对mongoDB的大量I/O操作。
  5. 看不到任何前端代码来管理或生成礼品卡

谢谢您的意见,其中一些我已经考虑过

  1. 关于前端显示的默认使用金额,我本意是尽可能地重复使用用户编辑API和首页,而不是在兑换后添加新页面来计算使用金额,用户信息更新和兑换的混合会导致事情变得模糊(即从用户信息或礼品卡信息中读取useAmount)。我认为通过用户注册API设置默认的useAmount并在将来为兑换功能设置一个新页面是正确的做法,这样所有金额计算将由后端处理。
  2. 在无登录情况下,后端使用量报告实际上不会发生,使用量是在挂载常规设置页面时读取的,如果没有登录,这种情况不会发生。在其他情况下,使用量信息是同步读取的,因为它包含在用户信息中,因此不会生成额外的读取操作。
  3. 如2中所解释,useAmount信息由userinfo同步读取,对于这种情况不需要额外的api调用。但是从兑换卡部分读取useAmount是额外的,我认为这个操作频率较低,所以不应该对性能产生太大影响。
  4. 关于限位开关的有效范围,我不知道哪个更好。但开关标签也在用户信息中,因此不会产生大量额外的I/O流量。但我也注意到,通过getUserById函数获取用户信息和将房间/聊天/信息更新到数据库的原始代码可能不适用于大量流量的情况,因为这些函数会被每次对话重复调用。
  5. 对于目前的不便,我感到抱歉,我只是简单地认为个人用户不需要礼品卡系统。我认为最好通过其他工具生成和管理礼品卡数据。例如,您可以通过免费的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的问题,结果我登出再登录发现输出变成完整的了,这是什么情况呢?

Noah-Wu66 commented 6 months ago

抱歉要说,但这次代码更改似乎比之前的提交更容易受到攻击。

  1. 默认的 useAmount 从前端发送并在后端计算。
  2. 后端报告在无登录情况下使用金额值(不必要的API调用和数据)
  3. useAmount 在前端通过单独的路由读取(额外的 API 调用)
  4. 限位开关应该全局影响,而不是每个用户。每个用户的默认使用量应该具有无限制的值(类似于0表示无限制,向前端报告为 unlimited ,而>1将计算使用量)- 这将减少对mongoDB的大量I/O操作。
  5. 看不到任何前端代码来管理或生成礼品卡

谢谢您的意见,其中一些我已经考虑过

  1. 关于前端显示的默认使用金额,我本意是尽可能地重复使用用户编辑API和首页,而不是在兑换后添加新页面来计算使用金额,用户信息更新和兑换的混合会导致事情变得模糊(即从用户信息或礼品卡信息中读取useAmount)。我认为通过用户注册API设置默认的useAmount并在将来为兑换功能设置一个新页面是正确的做法,这样所有金额计算将由后端处理。
  2. 在无登录情况下,后端使用量报告实际上不会发生,使用量是在挂载常规设置页面时读取的,如果没有登录,这种情况不会发生。在其他情况下,使用量信息是同步读取的,因为它包含在用户信息中,因此不会生成额外的读取操作。
  3. 如2中所解释,useAmount信息由userinfo同步读取,对于这种情况不需要额外的api调用。但是从兑换卡部分读取useAmount是额外的,我认为这个操作频率较低,所以不应该对性能产生太大影响。
  4. 关于限位开关的有效范围,我不知道哪个更好。但开关标签也在用户信息中,因此不会产生大量额外的I/O流量。但我也注意到,通过getUserById函数获取用户信息和将房间/聊天/信息更新到数据库的原始代码可能不适用于大量流量的情况,因为这些函数会被每次对话重复调用。
  5. 对于目前的不便,我感到抱歉,我只是简单地认为个人用户不需要礼品卡系统。我认为最好通过其他工具生成和管理礼品卡数据。例如,您可以通过免费的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的问题,结果我登出再登录发现输出变成完整的了,这是什么情况呢?

登出再登录我发现没必要,只要刷新页面就会显示出完整的答案。

BobDu commented 6 months ago

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?