treehollow / treehollow-backend Goto Github PK

View Code? Open in Web Editor NEW

167.0 4.0 47.0 400 KB

T大树洞的Golang后端

Home Page: https://thuhole.com/

License: GNU Affero General Public License v3.0

Go 100.00%

treehollow-backend's Introduction

treehollow-v3-backend

第三代树洞后端

安装文档：https://github.com/treehollow/install-doc

License

AGPL v3

treehollow-backend's People

Contributors

Stargazers

Watchers

treehollow-backend's Issues

树洞回复时出现错乱

问题#1350下 #6552 #6553应该是两个人发的，但都认证为[Isabella]

【Feature request】链接预览

可以利用 https://linkpreview.net/ 的 API 实现洞文中链接的预览。
目前虽然洞文总量大，附加链接的洞文比例不高，免费版的 60请求/小时应该已能满足需求。

期待能允许官方校友邮箱用户参与注册树洞

毕业生毕业后一段时间（最多半年？）后就无法再通过 @mails.tsinghua.edu.cn 邮箱收件，但毕业时也会收到一个学校统一授予的官方校友邮箱 @tsinghua.org.cn 。考虑到 @tsinghua.org.cn 同样具有甄别校友身份的官方属性，可否允许持有 @tsinghua.org.cn 的用户参与注册树洞？

图片目录应分为多级目录，尽量保证一个目录下的文件数量不超过1000

禁言功能的支持

预计支持的功能：
1 因举报过多被删除的洞主，禁言一定时间
2 禁言时间与历史禁言次数有关
3 满足一定条件永久封禁

加密函数变为sha256(salt+sha256(email))的更新计划

更新计划如下：
1 同时写好数据库migration代码和后端代码
2 production数据库复制一份变为test数据库
3 在test数据库中测试migration代码和后端代码
4 在某日树洞使用的低峰时段，停机更新，fallback server显示错误提示信息为“正在进行系统维护”。迁移前，备份production数据库。如果数据库加密升级成功（没有错误提示信息），那么万事大吉。如果出错，恢复数据库备份，revert后端代码。

欢迎大家对此更新计划提供建议。

【使用说明】的制订

看起来很多人还不会使用一些功能，包括但不限于:

点击树洞号可以“复制全文”
Chrome和Safari里可以安装应用到桌面。
现在好像很多人还在用微信浏览器
Token用于多客户端登录

回复内可以打tag

【Privacy Policy】的制定

i.e. 隐私政策

关于信息泄露的问题

https://thuhole.com/services/thuhole/api.php?action=getone&pid=1
通过这个url无需登录即可查看树洞信息，可能被校外人士利用。
本人不太懂网站搭建，偶然发现，不知能否解决？

进入树洞app便黑屏

可以见到一瞬间树洞，然后就变成如图所示的黑屏情况。

关注状态有时显示不正确

身份认证服务与树洞API服务分离为2个程序

此issue是#20 的一部分。

为了优化后端数据安全与用户注册信息安全，现有一种优化方案是，将身份认证服务与树洞API服务分离为2个程序。

目前，在pkg/route/route.go中，现有程序提供如下HTTP服务：

	r.POST("/api_xmcp/login/send_code", sendCode)
	r.POST("/api_xmcp/login/login", login)
	r.GET("/api_xmcp/hole/system_msg", systemMsg)
	r.GET("/services/thuhole/api.php", apiGet)
	r.POST("/services/thuhole/api.php", apiPost)

现考虑将/api_xmcp/*与/services/thuhole/api.php分离为2个程序：

身份认证程序：提供3个接口
- /api_xmcp/login/send_code, /api_xmcp/login/login与原先功能保持不变
- 用户邮箱有关的的单向加密全部在此程序中完成，此程序中的salt或key应只存在于内存之中，salt或key由https://github.com/thuhole/shamir-key-sharing 生成，分发给管理员。超过半数持有shamir key share的管理员一起才可以解密出salt或key。
- 此程序需要保持高可用，如非特殊情况不重启，重启服务需要超过半数持有shamir key share的管理员参与。
- 用户邮箱的加密函数，视升级难度，可以考虑选为sha(salt+sha(email)), AES(email, key), AES(sha(salt+sha(email)), key)中的一种。
树洞API程序：和原先/services/thuhole/api.php, /api_xmcp/hole/system_msg所提供的功能一致。

这2个程序不一定要在同一台服务器中运行，可以分离，分离后仍然最好共用SQL服务器中的user_info和banned表，如果不共用这两个SQL表，则需要多增加接口维护这两个表的同步。

目前可以想到的此方案主要困难在于，维护身份认证程序的高可用。因为，每次重启将会非常麻烦。这对程序的可靠性、服务器提供商的可靠性要求都非常高。

欢迎大家讨论。

电脑版网页有时候“查看系统消息”不可见

暂时没法复现所以没截图

增加功能：管理员置顶树洞

期待树洞出两种排序，一个是现在这样，另一个是最新回复的洞可以被顶上来

在#1856号洞看到的提议，发到这里希望管理员可以考虑一下~

建立完整的用户举报+管理员轮流值班+脏话屏蔽+管理员复核举报的机制

在寝室的电脑，登录树洞显示Error：网络错误401

登录错误提示不完善

如果没有补充邮箱地址@前面的部分，输入正确的验证码登录时，会提示验证码错误而不是提示邮箱地址格式不对

搜索关键词"tag"无法搜到任何内容

彻底的【代码重构】和【SQL数据库结构重构】

由于第一次发布的版本为敏捷开发方式，SQL数据表有许多地方设计欠妥，代码更是丑陋不堪，仅仅是勉强满足了用户需求。

待树洞管理完善后，计划于2020年7月底之前彻底重构代码和数据库，选择某一天的树洞低峰时段（凌晨5点）进行彻底的系统升级。

此帖用于落实重构细节，欢迎所有人来讨论！

树洞移动客户端

受PKU Helper启发，我从半年前开始开发一款类似的APP，这是仓库链接，现已做出Android版本，并计划在暑假将其迁移至React Native。（但由于一直没有返校，也一直没有推广的机会。）
现在看到我们也有自己的树洞了，我打算借此机会将两者融合一下（类似PKU Helper），不知是否妥当？
（当然，如果是这样，我可以考虑加快我这里开发与迁移的进度。）

为提升图片访问速度，考虑使用GitHub+jsdelivr作为图床

【Feature request】建议加入区间查找功能

在树洞里的第1500条发表后，我打算开始研究树洞的早期演变，然而，批量查询较早的洞问比较困难，如果可以按序号访问一个区间里的所有洞问，将会很有帮助。

对@pku.edu.cn开放注册的TPLINK树洞

隔壁同学看起来对T大树洞热情很高。
未来考虑以某种方式使树洞同时对@pku.edu.cn和@mails.tsinghua.edu.cn开放。

后端校验 TOKEN

目前非注册用户在 localStorage 里随便加一条 TOKEN 就可以浏览树洞。不知道是不是有意为之。

期待与闭社能有某种联动甚至账号互通

别再像北大一样树洞和bbs完全分开了😂

关注列表按“最后回复时间”排序

增加一个column叫last_reply_timestamp即可

【突发重大舆情事件和集体公众情绪的应急预案】的制定

为了T大树洞的未来发展，此预案应尽早制定。欢迎大家提供建议和想法。

Greetings

http://树洞.世界三流大学.com and http://hole.世界三流大学.com now point to https://thuhole.com via domain redirect.

Good luck!

iOS+Chrome 邮箱栏只能输入数字

Attention数据表的更新计划

在#34 中讨论到的这个风险，预计在近日尝试更新修复。
更新计划如下：
1 同时写好数据库migration代码和后端代码，在本地测试无bug
2 production数据库复制一份变为test数据库
3 在test数据库中测试migration代码和后端代码
4 在某日树洞使用的低峰时段，停机更新，fallback server显示错误提示信息为“正在进行系统维护”。迁移前，备份production数据库。如果Attention数据表升级成功（没有错误提示信息），那么万事大吉。如果出错，恢复数据库备份，revert后端代码。

欢迎大家对此更新计划提供建议。

数据库 attentions 字段风险问题

涉及代码

从 init_db.sql 可以看到 user_info 的 attentions 字段的的定义如下：

create table user_info
(
    email_hash CHAR(64) NOT NULL,
    token      CHAR(32) NOT NULL,
    timestamp  INT      NOT NULL,
    attentions VARCHAR(10000),
    PRIMARY KEY (email_hash),
    INDEX (token)
) DEFAULT CHARSET = ascii;

而关于这个长度上限为 10000 的字符串 attentions 的核心解析如下：

func charToInt(c int) int {
	if c <= '9' {
		return c - int('0')
	} else {
		return c - int('a') + 10
	}
}

func hexToIntSlice(str string) []int {
	rtn := make([]int, len(str)/8)

	res := int(0)
	for i, r := range str {
		res = res + charToInt(int(r))<<(4*(7-(i%8)))
		if (i+1)%8 == 0 {
			rtn[i/8] = res
			res = 0
		}
	}
	return rtn
}

func intSliceToHex(array []int) string {
	var rtn string
	for _, n := range array {
		rtn += fmt.Sprintf("%08x", n)
	}
	return rtn
}

潜在风险

如果我没理解错的话，这个设定有以下问题：

在没有必要用 VARCHAR 的场合使用它，对数据库空间利用率不高；
在查询、添加关注时，都需要对 attentions 字符串进行遍历与解析，效率不高；
当前树洞已经有近四千条，不出几日即可达到万规模，而这个设定下最多仅能容纳 1250 条，且用的是栈式结构，如果数据库用的是 mysql 的 ANSI 模式，将会在第 1251 个关注时由于记录截断而出现关注失败的情况。

建议

老老实实建立多对多关系表吧
我不知道现在关注最多到了什么量级，从个人使用来看不会特别多，因为目前仅发帖和回复会关注，但是倘若出现增长速率过快导致优化结构前达到 1250 的水准，可以考虑把栈式结构改为队列结构，对用户而言就不会有bug体验。

[Feature Request] "允许的邮箱后缀"作为可配置项?

如题, 既然是AGPL协议开源, 那么理论上是欢迎外校搭建/外校开发者做出贡献的. 但是现有的代码中, 可选的邮箱后缀是hard coded的, 不方便外校开发者贡献/调试/搭建. 是否考虑将允许的邮箱后缀作为可配置项?

如果接受的话, 我可以写个pr.

关于树洞匿名性的讨论

根据树洞里的公告:

出于对用户隐私的保护与尊重，后台不会记录任何您的个人信息，单向加密的技术手段确保了没有人可以从一条树洞号查出发送树洞的邮箱。同时，T大树洞不会向用户收取任何费用，也没有植入任何的商业广告。

我对于这个表述产生很大的质疑。根据后端 https://github.com/thuhole/thuhole-go-backend/blob/master/src/db.go 可见后端存储发帖人信息的逻辑是根据 email_hash 字段:

	doPostIns, err = db.Prepare("INSERT INTO posts (email_hash, text, timestamp, tag, type ,file_path, likenum, replynum) VALUES ((SELECT email_hash FROM user_info WHERE token=?), ?, ?, ?, ?, ?, 0, 0)")
	fatalErrorHandle(&err, "error preparing posts sql query")

根据 email_hash 属于 user_info 表可知，每一个用户的 email_hash 是唯一的。因此开发者 可以非常容易地通过查阅 posts 和 email_hash 表了解到发帖人信息，T大树洞完全是单向匿名的，管理员可以查看所有树洞的真实信息。

并且，这一hash的构造过于简单，根据 utils.go:

func hashEmail(user string) string {
	h := sha256.New()
	h.Write([]byte(user))
	return hex.EncodeToString(h.Sum(nil))
}

在用户量小到可以忽略的条件下（甚至所有学生都注册的条件下，也不过是几万个email）这个hash形同虚设，对于开发者想要重新生成所有的邮箱对应的hash只需要几毫秒，因此树洞发帖人可以轻易查询。

我们对于树洞公告中做出的 ”具有迷惑性“ 的陈述鼓励用户自由发帖，和这显著没有考虑用户匿名性的代码设计产生极大的怀疑。

希望开发者公开回应我们的质疑，赢得用户的信任。

希望树洞提供富文本支持

目前的官方置顶是一份裸markdown,如果能够渲染是不是更棒?
加入latex支持也许会增添更多乐趣(

Markdown文档

帮助新手学会Markdown基本用法

与第三方爬虫合作实现热榜功能

我们允许与我们合作的爬虫对我们每天的树洞进行热度排序。如果有人现在做好了爬虫，欢迎开源之后与我们商讨合作事宜。

一个 typo

https://github.com/thuhole/thuhole-go-backend/blob/87fb4e8eb5c48463f08f5791fb6633f82709bbed/pkg/route/routeApiPOST.go#L273

应该是「关注失败」而非「举报失败」

源码结构按功能重构

目前src下文件结构有问题，稍显混乱，也不利于后续添加单元测试。

如下按功能划分package的结构可能更好：

- cmd
  - main.go
- pkg
  - utils
    - utils.go
    - utils_test.go
  - config
    - config.go
    - config_test.go
...

这个issue是 #20 的一部分

treehollow / treehollow-backend Goto Github PK

treehollow-backend's Introduction

treehollow-v3-backend

License

treehollow-backend's People

Contributors

Stargazers

Watchers

Forkers

treehollow-backend's Issues

涉及代码

潜在风险

建议

Recommend Projects

Recommend Topics

Recommend Org

Jobs