-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Functionality discussion #1
Comments
刚刚拍大腿想的数据库设计:Gist 在数据迁移的过程中我们要把板块和分区转成两个 Tag,抛弃掉 Discuz 的结构,目前就想到这么多了。 |
如果密码用hash(hash(pw)+salt)的方法存储的话,salt也应该保存在用户的属性里面吧。 |
subscriber 可以有,比较实用。 |
discuz用的是每个用户不一样的,因为激活时需要进行md5(md5(pw)+salt)的鉴权,所以每个用户的原salt肯定得存一份,至于新站是否有必要就不一定了。 |
那就独立个新的资源站吧,单页写起来应该也不会太困难(Flag),大不了让老司机用 React 写一个(雾 |
肯定得做裁剪。这些星座生肖什么的也不要了。然后在考虑安全问题的事情,有一部分原先在Discuz设置了登录安全问题,在考虑激活新账号的时候是否需要认证,个人感觉意义不大不如直接扔了。 |
刚刚更新了 Gist,增加了 votes 字段,ACL 控制,更新了凭据的存储方式。看看有没有猫饼什么的。 |
。。难道不应该是member么。。member里面加个唯一的username?邮箱登录似乎不是很讨喜。username登录比较方便一点。attachment里面挂个id?找起来会方便一点吧。 |
discussion既然有赞和踩。要不要做个折叠? |
uid 的话是要继承 Discuz 的数据库,如果直接抛掉可能会有不少麻烦。 |
啊我的妈啊疯狂 typo……之前文件名还拼错了一次 QAQ db.common_member.find({username: { $in: ['.zyz', 'ZephRay'] }}).pretty()
{
"_id" : ObjectId("58f2275d2efffc0a4a05f79a"),
"uid" : 102815,
"realname" : "你们应该都已经知道了吧",
"birthyear" : 1998,
"msn" : "\t",
"site" : "http://www.zephray.com",
"bio" : "QAQ",
"username" : "ZephRay",
"email" : "[email protected]",
"regip" : "115.216.110.24",
"regdate" : 1308374344,
"lastlogintime" : 1351506240,
"device" : "Nspire/Nspire CX",
"credentials" : {
"password" : "//",
"type" : "discuz",
"salt" : null
}
}
{
"_id" : ObjectId("58f2275d2efffc0a4a05f7b9"),
"uid" : 105077,
"gender" : 2,
"birthyear" : 1996,
"birthmonth" : 8,
"birthday" : 14,
"qq" : "914714146",
"site" : "https://www.ntzyz.cn/",
"bio" : "弱菜",
"username" : ".zyz",
"email" : "[email protected]",
"regip" : "114.232.38.5",
"regdate" : 1335761157,
"lastlogintime" : 1351950694,
"device" : "Nspire CX CAS",
"credentials" : {
"password" : "//",
"type" : "discuz",
"salt" : null
}
} 似乎论坛从 5d6d 迁出前的用户 salt 都是空,这些用户凭据验证又是怎样的?两次 MD5? |
是的,salt如果为空的话就是两次md5,注意都是32位小写(毕竟如果大写了第二次md5出来就不对了)。 |
感觉用户部分这样就行了? |
顺便附件不单独做 ID 我是觉得直接用 href/URL 做定位,然后只有上传者可以编辑,如果别人想引用可以直接附上超链接这样。所以加个 attachment_id 是否有必要? |
Mongo的ObjectID需要转录。他用的不是字符串,需要特殊处理一下。
另外就是Mongo的ID太长了。所以还是用数字ID比较好。 |
附上超链接的话还是比较麻烦的。同名之类的问题,md5处理图片也算是耗时操作了,卡你个一两秒不是问题。还是全部走id比较稳吧。 |
附件的超链接我是想的比如这样:
重名问题限制在用户内,应该可以避免掉的。 discussion: {
title: '[公告] cnCalc 论坛改版计划说明',
uid: 102815,
datetime: 1234567,
content: {
encoding: 'html',
text: '各位坛友,<br/>首先感谢各位一直以来对cnCalc团队的支持,...',
allowScript: false
},
votes: [],
status: null,
reply: [
{
uid: xxx,
encoding: 'html'
text: '厉害了,感觉未来是要拥抱Nodejs的节奏?<br/>现在用阿里云+Docker?',
allowScript: false
votes: [],
status: null,
}
]
} 第二种 discussion: {
title: '[公告] cnCalc 论坛改版计划说明',
uid: 102815,
datetime: 1234567,
reply: [
{
uid: 102815,
encoding: 'html',
text: '各位坛友,<br/>首先感谢各位一直以来对cnCalc团队的支持,...',
allowScript: false
votes: []
status: null,
}, {
uid: xxx,
encoding: 'html'
text: '厉害了,感觉未来是要拥抱Nodejs的节奏?<br/>现在用阿里云+Docker?',
allowScript: false
votes: []
status: null,
}
]
} (似乎第二种用 reply 作 key 有点奇怪,换个什么名字? |
第二种让我想到了百度贴吧的做法(楼主位可能被吞),reply有点奇怪的话……用posts?另外别忘了帖子置顶精华一类的问题。直接用MongoID当discussion的id?等等,如果没有AUTO_INCREMENT的话……用户注册时UID如何分配? |
官方提供的自增方法是这样的。
但是官方建议用MongoID。。还是算了。GTMD MongoID。 |
看起来第二种好一点。整理起来也方便。 |
官方的自增方法也不清真啊 [黑脸] 至于 UID 的话,要不转换的时候直接去掉全用 MongoID?(死 |
行吧。用 MongoID 的话看起来效率上会更高一些,Express 上加一层转换也就马马虎虎够用了。主要就是什么帖子 AV 号啊,用户 ID 之类的不好交流。 |
目前大概已经完成了用户和帖子的内容迁移了(除了那个爆了 16MB 的签到帖……) |
嗯,附件PM处理完就该开始头疼转discuz encode的问题了吧( |
感觉还是应该处理一下那个签到帖,考虑去掉一些字段(vote 之类的空字段),然后再把这个 discussion 给 lock 了禁止操作? |
discuz 的转码我等会儿给 kasora 一份 mongodump,然后他先开始肝。
这个我们怎么处理,继续硬编码? |
flarum、nodeBB一类的是怎么实现的?其实硬编码感觉上问题不大,毕竟通知消息只是在发帖时送出一遍,然后用户应该也没有查询自己帖子被引用记录的需求 |
Flarum 好像也是硬编码,参考简易站的这个正则。 |
我记得phpBB也是硬编码。这么做的主要原因应该是引用不一定全文引用,这样硬编码可以多次引用,一次只引用一句,方便进行长篇批斗(雾 |
还有附件/图片之类的资源问题,我的想法是对图片检验 refererer 并做好 cache control,不做访问数量限制;对附件要求用户必须登录,对用户和IP同时进行计数并做限制。 |
附件下载的次数还需要统计么( |
附件下载数量可以统计下,但是也不是非常必要。 |
现在数据库那儿已经基本能跑了(除了老司机负责的 Discuz 排版转 HTML 需要大量测试)
另外似乎我们还缺个 webpack 配置工程师( |
大佬似乎应该还是倾向于Vue的感觉? |
我的转 HTML 你们可以跑跑看。我写了测试,你们 |
还有就是似乎原来论坛的搜索功能不怎么好用。。一搜就爆炸。所以我也不知道有些标签处理之后是什么效果。。 |
其实转 HTML 我本来觉得直接调用它的 PHP 代码应该就可以了的,但是 Discuz 的代码…… |
基本上开工了吧,第一发 commit 有一个假模假样的网页和一点点只读 API。界面目前整体上先向 flarum 看齐,其他的部分一点一点慢慢加。 |
现在有一个比较尴尬的问题,就是选择了若干标签后,如何去筛选对应的 discussions。 |
我觉得应该是与思路比较正常。Tag 检索类的网站一般都是这么处理的(比如 ehentai 啊,你输个 full color chinese 肯定是想精确定位某一块) 如果对或有需求的话可以一个个标签点过去。 |
关于账号迁移的问题,我实现了一个我自己的想法,整个过程分为两步:
|
现在的流程是这样的。 |
那这样的话发 token 不如直接像主流网站的激活一样,直接发送一个带 token 的超链接,但是这样就要求每个旧用户都绑定了邮箱。如果邮箱无效或者是没有绑定不久 GG 了么( |
直接发超链接这个我之前考虑过。 没有邮箱的事情。总之之前怎么登陆的现在就怎么登陆吧。或者登陆完成后个人页面给出迁移按钮应该也可以。 |
有空去文档里面补充一下类型和文本说明 |
目前帖子/讨论的 URL 名称都是其实例的 MongoID,个人感觉不够友好,或许改用 Base64 而不是 hex 来编码会好一些……? |
还有就是对于几个特别分区(比如机要处,内部版块)的隐藏,应该如何实现? |
Base64确实看起来舒服些。 |
所以就是,除了 pinned 以外的分区全部都设为仅管理员可见? |
嗯 我是这么觉得的 |
刚想到网页字体族的问题,是像现在这样使用浏览器默认,还是硬点一套黑体? |
目前迁移的过程是这样的,在这里记录一下方便查阅:
目前一致认为不应该开放用户 ID 的变更,因此账户迁移将被作为唯一一次修改 ID 的机会。 |
目前的密码修改及重置流程,记录/查询:
|
discussion 表中 posts.index 字段是否可以删除? |
看了一下,应该是没什么大问题,你就当他不存在好了,过两天我去把转换工具改一下。 |
防止posts中index的冲突问题。排序采用时间正序排序,时间相同则按照mongoID正序排序 |
List and discuss the functionality here.
The text was updated successfully, but these errors were encountered: