发信人: IronBlood (agile), 信区: BMY_Dev
标 题: Re: BMYBBS 新版界面发布说明
发信站: 兵马俑BBS (Wed Apr 21 13:31:20 2021), 本站(bbs.xjtu.edu.cn)
技术相关的内容可能会略显枯燥，我尝试用通俗的方式，按照名称、背景、当前改动的顺序
来介绍。
一、登录相关的补充说明
之所以放在最开头，是因为我觉得信息安全是比较重要的，正如前文所说，本次改动引入了
新的风险。在原先的登录方式中，登录后浏览器里出现的是这样的形式：
http://bbs.xjtu.edu.cn/BMYXXXXXX_Y/
这里 XX...XX 是一串代表用户身份的临时信息，BMYBBS 在处理类似发布帖子、发送站内信
件的时候会校验 IP，因此这串临时信息即便泄漏别人也不一定能用（除非ta和你有同样的
出口 IP）。这有一些弊端，比如：
1) 你主动切换了设备的网络，比如电脑从办公室带回了家
2) 无法确定设备的出口 IP，比如使用手机访问 BBS
这些都会导致在使用中时常出现掉线的糟糕体验。
这次改动将临时信息改动到了 cookie 中，这不是产生风险的主因，移除了 IP 校验才是。
这意味着如果有人获得了你的 cookie，他就可以使用你的身份发帖，而 BMYBBS 非常难以
判断。对此的应对措施有：
1) BMYBBS 通过技术限制，阻止第三方脚本从您的浏览器中窃取 cookie。
2) 强烈建议使用 https 方式浏览 BMYBBS（并且留意浏览器给出的警告信息）。https 是
一种加密传输方式，在证书正确的情况下能够确保在您访问 BMYBBS 的时候，您的密码和
cookie 不会被第三方捕获到。
由于目前还在积极向学校申请开通 https 校外访问，目前我还不能将所有的 http 请求自
动重定向到 https 方式。（时机成熟的时候我再补上这个漏洞）
二、新 Web 的实现方式
前端使用 vue.js 3 + bootstrap 5，配合一系列的库。后端基于 onion，一个 C 编写的
http 服务器库开发，输出 json 格式。Onion 的开发风格有点像 Java Servlet。
老的 web 在开发的时候，web 技术还很不成熟，每一个字符都是 C 里 printf 输出的，维
护的难度，算了，我们聊下一个话题。
三、代码结构
目前 BBS 的构建已经从 Makefile 变更成了 cmake，同时库的头文件也都移动到了
include 目录，因此如果您手上有一份早期版本的代码，打算提交一些补丁，请务必切换到
主线版本。
这个变动有两个原因：
1. 可以分离源代码和编译产生的中间文件，保持代码目录的整洁。虽然 Makefile 可以在
单独的目录里构建，或者 .gitignore 忽略文件，不过这个配置太麻烦了，且相对于第二点
。
2. cmake 可以生成 compile_commands.json，clangd 配合这个文件可以提供 LSP
(Language Server Protocol) 服务，采用一个支持 LSP 前端的编辑器，比如 VSCode、
Vim、CLion，可以获得不错的 IDE 体验。维护 BMY 代码再也不用两眼一黑了。
四、代码重构
除了目录结构、工具的改变外，代码自身的变动也非常多。大体上是两方面的意图：
1. 提取重复的部分作为库函数，或者库函数自身出于可读性、健壮性的。
兵马俑的功能实现现在有三部分，提供 telnet/ssh 服务的 bbs/sshbbsd （这两个使用的
一套代码），提供旧 web 服务的 nju09，以及新开发的提供新 web、小程序后台服务的
api。前两个部分其实都是属于独立开发，然后把 nju09 拼接了进来，所以不少功能里逻辑
和界面耦合比较紧密，或者干脆两段同样的代码。重构成库函数可以减少以后的维护工作，
且如果一个界面服务出错（比如 www），另一个服务大概率也会出错，这样问题可以比较早
的暴露出来。
2. 依据静态代码检查（Coverity Scan）和编译警告修正代码。
这项工作有个独立的状态跟踪页面
https://github.com/bmybbs/bmybbs/projects/8中高风险从 909 降到了 487，消除了大概 60% 的编译警告。这里有很多常见的 C 编程错
误，比如像缓冲区使用、资源泄漏、未初始化的变量等等，当然也有一些属于误报，比如创
建的缓冲区过大（也就是实际只使用了很小的部分）导致后面缓冲区拷贝的时候给出警告，
比如使用了 rand 函数生成发帖来源部分的随机颜色。总的说起来，这些改变未必能察觉到
，但是检查一遍这些代码，对系统整体的健壮性更有信心。
技术部分先聊这么多，以上。
--
FROM 122.225.220.*