不只是杠精。 @wheat0r
---

Troll 行为的特点包括：

造谣和散布虚假信息：Troll 可能刻意发布不真实的言论或信息，以引起困惑、争议或恼怒。
挑衅和攻击性：Troll 通常使用冒犯性、侮辱性或攻击性的言辞来激怒别人，引发争吵和紧张气氛。
脱离主题或无意义的回应：Troll 可能故意发表与主题无关或没有意义的回复，以干扰和破坏正常的讨论。
持续干扰和诋毁：Troll 可能会不断重复相同的问题或评论，或者对其他用户进行无端指责和侮辱，以干扰和破坏讨论的秩序和和谐。

功能远不如 inoreader 强大

用 mac+愿意折腾， 大概率是做技术的人，这些人有需求的少，毕竟还有很多人会选择玩 docker ，而愿意玩这些人又大概率知道宝塔之类的管理面板。。。所以用户当然寥寥无几。

@billlee 老师说， 你研究过移动一键登录 SDK 吗？研究一下看看你 APP 有没有这种能力吧

@shijingshijing 你的意思是： “淘宝 App 能通过联通 SDK 拿到 135****8888 这种形式的不完整本机号码的” 这个过程，APP 能从联通 SDK 读到这串数据是吗？ 确定这不是 SDK UI 显示的数据吗？

@maleclub 较个真： 双卡你测过吗，通常一键登录 sdk 只会切 4G 网后与网关通信，双卡双待手机只取当前流量卡号啊，难不成你两张卡都能同时识别？

@shijingshijing “每次 App 都会通过运营商 SDK 拿到联通的号的前三和后四位” 这描述是不准确的。
因为不论是移动还是电信，SDK 都是开放平台提供的，能力是官方（即运营商）封装好的，在未授权时应用接入方面（即 APP 端）是拿不到的。虽然你可以见到，但是并不意味着 APP 可以拿到。

当然如果杠一下说：程序截屏啊、0day 啊啥的，当我没说 😓

如果接口已经使用了 HTTPS(HTTP over TLS/SSL),那么参数签名的必要性会降低一些:
HTTPS 本身就可以防止中间人攻击,数据传输在加密通道内,参数不易被篡改。
但 HTTPS 无法防止客户端篡改参数后再发送请求的情况。此时参数签名可以作为最后防线,检测参数是否被篡改。

一些特殊攻击如重放攻击,HTTPS 也无法直接识别和防护。参数签名可以识别非法重复请求。
如果应用很关注请求参数的完整性,并且接口对传入参数做进一步校验使用,那么签名依然可以作为辅助手段。
所以,如果仅仅考虑传输安全性,在使用 HTTPS 的前提下,参数签名的防护效果会受到一定程度的冲减。

但总的来说,参数签名作为一种应用层的安全机制,它的价值并不完全取决于传输层是否使用 HTTPS 。
如果成本允许,最稳妥的做法是:
- 使用 HTTPS 加密传输
- 加上参数签名的验证
- 合理限制接口调用频率
- 以获得最全面深度的防护效果。这种多层防护的合作也是 RESTful 接口安全设计的一个好习惯。

静态页面哪有这么复杂，写个 bash 脚本几行命令解决 scp 、登陆操作文件指令、退出。bash 搞不明白再不济就用 python fabric 写个脚本。

@maleclub 不需要 IMEI 的，你的 SIM 卡联入运营商网络的后信令通信过程运营商已经获取到了

@hellomynameis 果手机里插了 86 卡还尝试用+1 注册 ？ 你不国际开漫游就取不到你美国的号码 😊这是网关取号，与 3G Wap 门户时代的认证同一个道理。

为啥禁止，这是网关取的数据不是从你本机。你不授权是不会取号的。

更换 license 为 MIT 或 Apache ，star 会更多

一般的用途，是能用的。如果二次开发加入一些什么，风险可能大了点

统一配置：ansible
查看资源：cockpit