【用户脚本】【更新离线版】用麻将脸回应泥潭吧！S1 Reaction 帖子回应服务

Junakr

既然都觉得用 S1 账号登录验证不太合适，那就更新一个剥离后端服务的离线版好了。
所有数据保存在本地，网络请求只有一个通过官方接口获取麻将脸 JSON。
功能上也会比在线版要丰富一些。

https://greasyfork.org/scripts/495710

1. 打开弹窗直接选择麻将脸，可以随同表情附上一段文字标记。



2. 一个帖子还是只能标记一次，重复提交会刷掉之前的记录，红叉移除。



3. 用户个人资料页只会展示你对他的标记了，可在这里删除，也能通过“#”符号跳转到被标记的帖子。



---

本来前几天就完成的差不多，结果准备发布的当天泥潭开始维护……索性就拖延了几天。
刚好论坛系统升级也就顺便适配了一下新版本，好在也没有太多需要调整，就当作开服庆祝发一帖好了。

这个浏览器用户脚本的作用简单来说就是给泥潭的帖子回复增加类似 GitHub、Discord、Bangumi 等网站评论的表情回应功能，但是麻将脸。
它是具备云端数据库的，所以是在线服务，由 Cloudflare 免费账号倾情提供有限的使用量，用超了就原地倒闭。

有时懒得回帖也出于各种原因不想对帖子进行评分影响鹅数和死鱼，那么你可以点一个表情 +1，有限且相对宽容地对帖子进行表态，就这样用。
（遇到经常钓鱼的楼主，也请不要吝啬表情对他进行标记，方便别人识别）

服务需要登录你的 S1 账号，同时也要保证账号至少存在一条历史回复用于验证用户信息有效，当然，只是看看是不用登录的。
放心，虽然需要登录账号，不过回应的数据在前台是始终匿名的，别人不会看到谁对什么帖子做出过什么回应，只会显示该层已回应麻将脸的总数。

另外需要重点注意的是，回应服务验证用户账号的过程需要使用到你的登录状态（Session ID），这是非常敏感的数据。
服务虽然可以保证不会收集或滥用任何超出必要的用户信息（目前仅记录 UID 用于和帖子绑定），如果还是介意的话就不要使用登录功能了。

更多和用户验证相关的技术细节请访问项目的开源地址：

https://github.com/rkanuj/s1-reaction

前端 Svelte 框架构建用户脚本保证代码体积和功能的平衡，后端使用 OpenAPI 规范提供接口接入，MIT 授权请随意享用。

用户脚本发布及自动更新地址：https://greasyfork.org/scripts/494721

暂时处于半公开状态，PC 区人少先在这里展示一段时间让我估算一下大概用量、看看到底有没有人用，等准备的差不多再考虑转到公开。
另外服务试运行阶段会有一些 Bug，有空就修，也欢迎提供使用反馈。

最后展示几个功能截图：

1. 用户个人资料会展示送出及收到的回应。



2. 麻将脸选择和账号列表（支持多账号登录切换）。



3. 简单的登录表单。



4. 加号快捷复读 +1，红叉移除，点击绿底小透明打开弹窗。

pgain2004

这几天刚好有点空，看情况在NUX里给适配一下
增加的内容最好有独特网页标识

schneehertz

为什么是用S1账号密码登录的方式做用户识别而不是其他方式？
（我也是前端，仅技术探讨）

—— 来自 Xiaomi 2203121C, Android 14上的 S1Next-鹅版 v3.0.0-alpha

Junakr

pgain2004 发表于 2024-5-21 08:11
这几天刚好有点空，看情况在NUX里给适配一下
增加的内容最好有独特网页标识 ...

如果是给回应框增加一个用户可见的 label 表明这是一个插件元素，确实值得考虑，UI 我没有太上心设计。
如果是给代码用于识别插件元素，这点已经考虑过了，脚本挂载的父元素类名是 s1-reaction。

移动端 APP 我也考虑过开发者的适配成本。
服务后端通过 OpenAPI 规范开放所有接口调用，有详尽字段类型约束和注释说明，对开发者友好。
还可以通过 OpenAPI Generator 快速生成不同语言框架的接口调用代码，方便客户端接入。
实际上，我的前端用户脚本调用后端接口的代码就是自动生成的。

SwaggerUI 文档：
https://s1-reaction.beepers-topaz-0c.workers.dev/
ReDocUI 文档：
https://s1-reaction.beepers-topaz-0c.workers.dev/redocs

Junakr

schneehertz 发表于 2024-5-21 08:21
为什么是用S1账号密码登录的方式做用户识别而不是其他方式？
（我也是前端，仅技术探讨）

如何验证识别用户我考虑了很久，详细手段和部分技术细节写在 GitHub 仓库的 README。

1、我不想维护一个自己的用户数据库，所以采用签发无状态 Token 的方式做验证（简化的 JWT）。
2、为保证服务端签发 Token 时的用户信息负载真实有效，需要在本地通过官方接口登录获取 sid，服务端再用 sid 去请求官方接口查询该用户的历史回复匹配 uid，同时验证登录有效和不盗用他人 uid。
3、服务端并不获取 S1 账号的用户名密码，只会短暂拿到用户的 Session ID，用完会立马在本地调用官方登出接口注销。

这方面有是一定隐私问题的，我已经从技术方面尽可能将风险降到最低，不过确实也没有什么更好的手段，我倒是想给泥潭上 OAuth，可是没有。

schneehertz

Junakr 发表于 2024-5-21 09:33
如何验证识别用户我考虑了很久，详细手段和部分技术细节写在 GitHub 仓库的 README。

1、我不想维护一个 ...

github的readme我看过了

这里我觉得是"易用性/隐私安全"和防滥用的取舍，对于一个重点在用户间的交互的第三方插件，这两点的平衡并不容易。现在使用账号密码登录的方式就是着重在防滥用上，牺牲了易用性/隐私安全，userscript的使用门槛本来就较高，需要用户自己安装”用户脚本管理器“，经过这一层筛选后的用户，对隐私安全的重视程度会比普通用户要高，我认为除非有其他验证方式，不然可以预见这个插件的使用量不会很高

如果是我设计类似的功能，防滥用我会放在一个比较次要的位置，使用浏览器指纹或者单纯在localStorage中放置一个标记作为用户识别，甚至防重放也可以在前端做。如果进一步需要验证，使用邮箱收取jwt或者手机收取验证码的方式，相比使用S1账号密码在隐私上也更为友好

当然以上只是我的个人意见

Nanachi

和S1NUX的兼容性不太好

Junakr

schneehertz 发表于 2024-5-21 10:13
github的readme我看过了

这里我觉得是"易用性/隐私安全"和防滥用的取舍，对于一个重点在用户间的交互的 ...

感谢建议，我也想到会有很多用户注重隐私和账号安全会觉得这个脚本有风险（毕竟泥潭账号也不便宜），所以才会尽可能将所有信息公开消除信息差，交由用户自己权衡是否登录使用（不登录也可以使用查看功能，并非不能用）。
希望我这个账号在泥潭这么多年的表现值得支撑起这么一点用户信任。

因为是免费服务，所以如何防止滥用是我最优先考虑的事（看到接口还有小黑屋功能应该就能知道我有多少防御性代码了）。
也不太可能为了它给云服务充钱，为了维持服务长期存续就稍微提高一些门槛吧，毕竟也不知道泥潭什么时候又又又又倒闭。

通过 S1 账号验证的一个好处就是帖子的回应数据可以和用户保持关联，不会因为我换个浏览器或清空本地数据就丢失对之前做过标记的更新权限。
你的账号还能登录就始终拥有服务上自身账号数据的更新权限，这点也是我在不为它单独设计一个用户系统的情况下进行权衡后的结果。
至于邮箱和手机收验证码就太增加开发负担了，我并不准备给这个简单的脚本投入过多开发时间，相对用户操作更麻烦也会暴露给服务更多用户个人信息，隐私风险反而更大。
说到底，服务并不接收 S1 账号密码，只是会拿到一次性使用并且会在短短几秒内完成注销的 sid，可被恶意利用的窗口其实很小。

另外，如果试运行测试发现免费额度完全够支撑泥潭的用户量的话，会考虑放开账号限制同时升级成浏览器插件的形式发布。

Junakr

Nanachi 发表于 2024-5-21 10:19
和S1NUX的兼容性不太好

看了一眼 S1 NUX 的样式，我这边脚本可以做兼容给父级 tbody 和下面所有 tr 行加 class 帮助样式匹配或绕过对回应栏的元素隐藏。

1. #postlist .plhin > tbody > tr:nth-child(3), #postlist .plhin > tbody > tr:nth-child(4) .pls {
   
2.     display: none
   
3. }

复制代码

@pgain2004

win8

需要登录帐号糟糕透了。感觉还不如利用私信机制，需要发送的内容走你帐号的私信，server根据收到的私信update数据库

pgain2004

Junakr 发表于 2024-5-21 11:42
看了一眼 S1 NUX 的样式，我这边脚本可以做兼容给父级 tbody 和下面所有 tr 行加 class 帮助样式匹配或绕 ...

如果你加了新网页元素，最好加个特殊的ID和class，这样定位起来会方便很多

Junakr

pgain2004 发表于 2024-5-21 12:26
如果你加了新网页元素，最好加个特殊的ID和class，这样定位起来会方便很多 ...

我当然加了自己的类名，问题是原来布局里的兄弟元素没有 class，而你的样式是通过序号索引 tbody 下的子元素。
我的网页元素必须插到这些子元素当中并列，这会破坏你的序号索引。
所以我的建议是，我用脚本除了给自身上 class，也给父级 tbody 加个用于识别的 class，方便你的样式绕开做特殊处理。
要么就使用相对较新的 has 伪类，那我这边就没什么要做兼容的了。

Junakr

win8 发表于 2024-5-21 12:15
需要登录帐号糟糕透了。感觉还不如利用私信机制，需要发送的内容走你帐号的私信，server根据收到的私信upda ...

这个方案不太可行，可用性和响应速度都太差了，而且让脚本替用户自动发私信也让我无法接受，有些越界。
既然这么抗拒登录账号的话，我晚上可以发个数据都在本地保存的无需登录离线版，可以支援文字标记。

Junakr

更新离线版脚本：https://greasyfork.org/scripts/495710
示例截图放在了主楼，这下总没有隐私问题了吧。

库德里尔

好玩。主要还是没人用，比较遗憾。

Junakr

库德里尔 发表于 2024-6-16 22:41
好玩。主要还是没人用，比较遗憾。

这两天准备移除登录限制，随便发个一次性 Token 作为用户验证（本来计划端午更新，拖了）。
没人用其实我也无所谓（我自己也不用（不是，接口利用率不到 0.001% 吧。
本来目的就是测试到 Cloudflare 的无服务框架方便我做其它事，收到的反馈太少我也没什么动力继续维护这个服务。

ajsh

有点酷，试试看

千千千千鸟

网页版安装之后，帖子每一行的长度会收到限制有点难受

dvd6

是不是我打开方式不对？就这个帖子里也没看见别人的表情标记。还是说离线版就是自己测试给自己看的？

Nanachi

dvd6 发表于 2024-6-17 17:05
是不是我打开方式不对？就这个帖子里也没看见别人的表情标记。还是说离线版就是自己测试给自己看的？ ...

离线版恰恰没有共享标记功能吧

dvd6

Nanachi 发表于 2024-6-17 17:17
离线版恰恰没有共享标记功能吧

理解错了，换成在线版看看