Functionality discussion

[zephray]

List and discuss the functionality here.

[ntzyz]

刚刚拍大腿想的数据库设计：Gist

在数据迁移的过程中我们要把板块和分区转成两个 Tag，抛弃掉 Discuz 的结构，目前就想到这么多了。

[zephray]

如果密码用hash(hash(pw)+salt)的方法存储的话，salt也应该保存在用户的属性里面吧。 另外是否有必要给topic增加一个subscriber字段，subscriber内的会收到关于topic的email通知。

[ntzyz]

subscriber 可以有，比较实用。 salt 方面之前是想全局统一的，如果要每个用户不一样就加到用户属性里去，不过感觉没必要？ 另外我好像漏了屏蔽关键词/正则的表了，明天补上。

[zephray]

discuz用的是每个用户不一样的，因为激活时需要进行md5(md5(pw)+salt)的鉴权，所以每个用户的原salt肯定得存一份，至于新站是否有必要就不一定了。 之前提到过的分区内按主题时间排序的抗挖坟办法，去掉分区功能后显然就是没有用了。不过……那不是意味着，新的资源站？

[ntzyz]

那就独立个新的资源站吧，单页写起来应该也不会太困难（Flag），大不了让老司机用 React 写一个（雾 顺便需不需要对 Discuz 的数据库转入的数据做适当裁剪？毕竟生肖星座这些有的没的感觉没什么意义。

[zephray]

肯定得做裁剪。这些星座生肖什么的也不要了。然后在考虑安全问题的事情，有一部分原先在Discuz设置了登录安全问题，在考虑激活新账号的时候是否需要认证，个人感觉意义不大不如直接扔了。 另外每个单独的discussion是不是可以增加赞和踩的字段，把原来Discuz的加分和扣分就这样导入过来。积分系统暂时没想好是不是应该废除。

[ntzyz]

刚刚更新了 Gist，增加了 votes 字段，ACL 控制，更新了凭据的存储方式。看看有没有猫饼什么的。

[kasora]

。。难道不应该是member么。。member里面加个唯一的username？邮箱登录似乎不是很讨喜。username登录比较方便一点。attachment里面挂个id？找起来会方便一点吧。

[kasora]

discussion既然有赞和踩。要不要做个折叠？

[ntzyz]

uid 的话是要继承 Discuz 的数据库，如果直接抛掉可能会有不少麻烦。 折叠这个的话要实现也应该放在前端去了，数据库这儿似乎不怎么需要变动？

[ntzyz]

啊我的妈啊疯狂 typo……之前文件名还拼错了一次 QAQ 现在转换器大概能把 Discuz 的用户数据变成这样一个 JSON：

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" : "nbzwt@126.com",
        "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" : "ljy99041@163.com",
        "regip" : "114.232.38.5",
        "regdate" : 1335761157,
        "lastlogintime" : 1351950694,
        "device" : "Nspire CX CAS",
        "credentials" : {
                "password" : "//",
                "type" : "discuz",
                "salt" : null
        }
}

似乎论坛从 5d6d 迁出前的用户 salt 都是空，这些用户凭据验证又是怎样的？两次 MD5？ 还有就是注册日期和 IP 需要保留么？

[zephray]

是的，salt如果为空的话就是两次md5，注意都是32位小写（毕竟如果大写了第二次md5出来就不对了）。 注册日期和ip需要保留吧。

[ntzyz]

感觉用户部分这样就行了？ 下午我开始处理帖子数据吧。

[ntzyz]

顺便附件不单独做 ID 我是觉得直接用 href/URL 做定位，然后只有上传者可以编辑，如果别人想引用可以直接附上超链接这样。所以加个 attachment_id 是否有必要？ 顺便如果直接用 Mongo 的 ObjectId 可以么（

[kasora]

Mongo的ObjectID需要转录。他用的不是字符串，需要特殊处理一下。

const ObjectID = require('mongodb').objectID;
MongoID = new ObjectID(stringID);

另外就是Mongo的ID太长了。所以还是用数字ID比较好。

[kasora]

附上超链接的话还是比较麻烦的。同名之类的问题，md5处理图片也算是耗时操作了，卡你个一两秒不是问题。还是全部走id比较稳吧。

[ntzyz]

附件的超链接我是想的比如这样：

//asserts.cncalc.org/:uid/:href?v=version

重名问题限制在用户内，应该可以避免掉的。 还有刚刚想到的，帖子的第一个内容如何处理？ 第一种：

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 有点奇怪，换个什么名字？ 另外就是 discussion 需不需要 ID？ 我之前是想的 API 之类的走 MongoID 来拉取某个帖子的详细信息的，不知道后台处理起来方便不？ 数字ID的话自增会比较麻烦，毕竟没了 AUTO_INCREMENT 这种好用的东西

[zephray]

第二种让我想到了百度贴吧的做法（楼主位可能被吞），reply有点奇怪的话……用posts？另外别忘了帖子置顶精华一类的问题。直接用MongoID当discussion的id？等等，如果没有AUTO_INCREMENT的话……用户注册时UID如何分配？

[kasora]

官方提供的自增方法是这样的。

function counter(name) {
    var ret = db.counters.findAndModify({
        query: {
            _id: name
        },
        update: {
            $inc: {
                next: 1
            }
        },
        "new": true,
        upsert: true
    }); // ret == { "_id" : "users", "next" : 1 } 
    return ret.next;
}
db.users.insert({
    _id: counter("users"),
    name: "Sarah C."
}) // _id : 1 
db.users.insert({
    _id: counter("users"),
    name: "Bob D."
}) // _id : 2 //repeat

但是官方建议用MongoID。。还是算了。GTMD MongoID。

[kasora]

看起来第二种好一点。整理起来也方便。

[ntzyz]

官方的自增方法也不清真啊 [黑脸] 要不先用 MongoID 苟着，如果实在坑的不行再搞自增数字 ID

至于 UID 的话，要不转换的时候直接去掉全用 MongoID？（死

[kasora]

行吧。用 MongoID 的话看起来效率上会更高一些，Express 上加一层转换也就马马虎虎够用了。主要就是什么帖子 AV 号啊，用户 ID 之类的不好交流。

[ntzyz]

目前大概已经完成了用户和帖子的内容迁移了（除了那个爆了 16MB 的签到帖……） 大概还需要处理附件和PM？其他我好像暂时想不到……

[zephray]

嗯，附件PM处理完就该开始头疼转discuz encode的问题了吧（

[ntzyz]

感觉还是应该处理一下那个签到帖，考虑去掉一些字段（vote 之类的空字段），然后再把这个 discussion 给 lock 了禁止操作？

[ntzyz]

discuz 的转码我等会儿给 kasora 一份 mongodump，然后他先开始肝。 然后就是 discuz 的对特定楼层回复是硬编码的：

[quote][color=#999999]imath 发表于 2017-4-10 20:22[/color]
[color=#999999]建议行动中的“7”加入更多仿真细节[/color][/quote]

剧情完之前的7还是剧情完之后的7？

这个我们怎么处理，继续硬编码？ 如果要改成楼层引用的话又如何标记引用，在 posts 中的位置还是再加个 ObjectID？

[zephray]

flarum、nodeBB一类的是怎么实现的？其实硬编码感觉上问题不大，毕竟通知消息只是在发帖时送出一遍，然后用户应该也没有查询自己帖子被引用记录的需求

[ntzyz]

Flarum 好像也是硬编码，参考简易站的这个正则。 但是我们至少需要稍微简化一下，目前这个实在是不好看（雾

[zephray]

我记得phpBB也是硬编码。这么做的主要原因应该是引用不一定全文引用，这样硬编码可以多次引用，一次只引用一句，方便进行长篇批斗（雾

[ntzyz]

还有附件/图片之类的资源问题，我的想法是对图片检验 refererer 并做好 cache control，不做访问数量限制；对附件要求用户必须登录，对用户和IP同时进行计数并做限制。 问题是限制策略如何决定，对下载次数限制还是对下载流量限制？限制的边界应该是多少？ 还有就是这个想法有没有什么漏洞什么的（（

[ntzyz]

附件下载的次数还需要统计么（

[zephray]

附件下载数量可以统计下，但是也不是非常必要。 下载流量限制吧，边界……难定了

[ntzyz]

现在数据库那儿已经基本能跑了（除了老司机负责的 Discuz 排版转 HTML 需要大量测试） 然后就是两个问题：

1. Vue.js 和 React.js 都支持服务端渲染，如何选择？
2. 前端设计谁来？

另外似乎我们还缺个 webpack 配置工程师（

[zephray]

大佬似乎应该还是倾向于Vue的感觉？ 等等你不是前端么（

[kasora]

我的转 HTML 你们可以跑跑看。我写了测试，你们npm test就能看到还有哪些标签没处理。有一些我也不知道处理成什么样比较好。

[kasora]

还有就是似乎原来论坛的搜索功能不怎么好用。。一搜就爆炸。所以我也不知道有些标签处理之后是什么效果。。

[ntzyz]

其实转 HTML 我本来觉得直接调用它的 PHP 代码应该就可以了的，但是 Discuz 的代码……

[ntzyz]

基本上开工了吧，第一发 commit 有一个假模假样的网页和一点点只读 API。界面目前整体上先向 flarum 看齐，其他的部分一点一点慢慢加。 顺便有不带传入限制的公网 IP 是真的爽（雾

[ntzyz]

现在有一个比较尴尬的问题，就是选择了若干标签后，如何去筛选对应的 discussions。 与的思路就是选择若干标签，选出所有文章标签是选中标签的超集的文章，比如选择 CASIO 和 函数机，就能查到所有卡西欧的函数机，不会出现卡西欧的图形机或德州仪器的函数机。 或的思路就是选择若干标签，选出所有至少一个标签匹配的 discussions，例如选择 TI 和 CASIO，就能查看所有这两个品牌相关的讨论。 个人认为这两个模式都应该存在，但是网页上往哪放是个麻烦。

[kasora]

我觉得应该是与思路比较正常。Tag 检索类的网站一般都是这么处理的（比如 ehentai 啊，你输个 full color chinese 肯定是想精确定位某一块） 如果对或有需求的话可以一个个标签点过去。 我觉得最后处理的话可能就像知乎那种设定了。自己设定偏好然后首页给你推荐或的标签。

[ntzyz]

关于账号迁移的问题，我实现了一个我自己的想法，整个过程分为两步：

1. 将待迁移的账户信息 POST 至 /api/v1/migration/verify，已验证旧帐户拥有者身份，若密码无误则生成一个 20 字符长的迁移 token，10 分钟有效。
2. 将用户提供的新用户名、密码、邮箱地址和之前的迁移 token POST 至 /api/v1/migration/perform，检查用户名和邮箱无重复之后，执行变更。 这个方法执行下来会有什么问题么

[kasora]

现在的流程是这样的。 用户注册，如果邮箱或者用户名存在。那么提示验证邮箱并迁移，或者修改名称使不重复。 迁移接口 /api/v1/migration/verify 将token发送到邮箱。跳转到验证token界面。 用户输入token。验证通过后进入修改资料界面。修改完成并提交到 /api/v1/migration/perform 数据验证通过后算作迁移成功。

[ntzyz]

那这样的话发 token 不如直接像主流网站的激活一样，直接发送一个带 token 的超链接，但是这样就要求每个旧用户都绑定了邮箱。如果邮箱无效或者是没有绑定不久 GG 了么（

[kasora]

直接发超链接这个我之前考虑过。 因为一般如果出现404的情况很可能是走了前端路由。所以默认是返回主页的。你那里可能要多处理一下？ 第二个如果发超链。给人的感觉更像是激活这个操作。但实际上我们发完超链之后需要验证用户名和修改密码，都合法才算迁移成功。如果别人不想改或者直接F5可能会比较困扰？ 当时我也没细想。只是觉得可能发修改验证体验更好？

没有邮箱的事情。总之之前怎么登陆的现在就怎么登陆吧。或者登陆完成后个人页面给出迁移按钮应该也可以。

[kasora]

有空去文档里面补充一下类型和文本说明

[ntzyz]

目前帖子/讨论的 URL 名称都是其实例的 MongoID，个人感觉不够友好，或许改用 Base64 而不是 hex 来编码会好一些……？ 比如 /d/59423e06ed4418798379a5e7，转成 Base64 后是 /d/WUI+Bu1EGHmDeaXn，会不会相对好一些？

[ntzyz]

还有就是对于几个特别分区（比如机要处，内部版块）的隐藏，应该如何实现？ 如果允许自定义 Category 那就应该直接建立一个隐藏列表（黑名单），只对管理员可见。 如果不允许自定义的话那么直接把现在这里定义的列表当做白名单就行了。 我之前想的是分区可以自定义，但是除了首页、个人页和相同分区名的帖子作为入口以外无法被索引，且没有分区简介和分区自定义头图、颜色等，所以不推荐自定义分区名，然后如果确实有这个需求可以创建并@管理，把他 pin 到分区列表里即可。

[zephray]

Base64确实看起来舒服些。 我觉得不需要允许自定义。因为保留这个没有头图 没有颜色的自定义分区设定 一来看起来会比较像一个bug而不是feature 二来感觉并不能make多少sense 所以不如直接不允许自定义。

[ntzyz]

所以就是，除了 pinned 以外的分区全部都设为仅管理员可见？

[zephray]

嗯 我是这么觉得的