GZTimeWalker/GZCTF

Misc: 在校赛中发现的问题和建议

xiongsp opened this issue · 3 comments

xiongsp commented

加油，浅浅赞助了一点
截屏2023-06-10 21 58 07

之前提交过的issue不再赘述

新发现的Bug和不成熟的建议：

  1. 系统日志、比赛监控内的实时刷新的列表会出现错乱的情况。例如监控中的提交记录，若选择“AC”筛选，刷新时会有“WA”或其他的条目刷新进来。不过无伤大雅啦
  2. 动态附件目前似乎只支持附件人数比大于等于1的情况，否则会有队伍分配不到附件。不知道是否考虑增加10个人用9个附件这样的情况，即在反作弊和占用空间二者取得平衡
  3. 目前上传动态附件似乎有总大小的限制。例如对于3MB左右的附件一次只能上传约13个左右，导致效率偏低。是否考虑通过读取本地文件？例如通过Volume映射一个本地位置，在此放置动态附件。既提高了效率又避免了前端上传文件大小限制
  4. 是否考虑提供一个接口以方便管理员通过自动化程序接入接口实现对用户比赛的审核。例如提供一个接口A返回所有用户的个人信息、封禁状态等；B返回待审核的用户的个人信息；C用于提交审核结果，例如通过或驳回。我们还是很希望能从报名到导出成绩全在平台完成，无需借助在线表格，但目前来看可能还是会有点麻烦
  5. 反作弊检查棒了大忙！在提交记录的“CD”栏可以看到作弊者的信息，但是只有一个队伍。通常来说封禁应当是封禁两者的，导致封禁时需要在“事件监控”和“提交记录”两个位置来回切换，找到对应的用户信息。是否考虑完善之，例如
队伍 用户 相关队伍 题目 操作
A A1 B 1 （封禁按钮）
A A1 B 1 （封禁按钮）

一不小心逼逼叨叨讲了这么多哈哈哈跟老奶奶的裹脚布一样，不过总之还是希望能看到GZCTF越变越好，早日看到破k stars的那天

GZTimeWalker commented

回复一下且记录一下这几个问题及可能的原因，留给我以后修或添加：

  1. 接收到 signalr 的实时日志后没有做过滤处理
  2. 听起来像是一个大于号的问题，但是一般预期的使用是生成队伍数量 * 2 份动态附件的
  3. 总大小的限制的话应该不是 GZCTF 的问题，之前遇到这个问题是因为 nginx
  4. 封禁和审核都是基于队伍的，这套系统有设计，做全部完善的事件 webhook，但这个目前也是卡在设计阶段
  5. emmm 确实可以考虑添加这一功能，很好的建议！
  • 👍1
GZTimeWalker commented

follow-up:

  1. 提交的 signalr 现在做了过滤
  2. 提交记录的作弊检查相关功能操作打算新增一个页面
  3. “动态附件目前似乎只支持附件人数比大于等于 1 的情况” 经过排查大概率是由于并发冲突导致，所以才不会建议分配这么少的 动态 flag
GZTimeWalker commented

Done in #116