一、token 有一个刷新有效期的，这个有效期过了，是无法进行刷新的。
二、用户反馈账号被盗后，应该要禁止用户登录。
三、将当前有效期内的 token 全部列入黑名单。

呀，楼主也做过区块链的啊，我也是咦，我接过 Bitcoin 、OmniToken 、BitcoinCash 、UnitedBitcoin 、Litecoin 、Decred 、Ethereum 、EthereumClassic 、Grin 、Beam 等各种币种，能谈谈你的感受吗？
我自己做这个感觉好累，不太想做这行了，主要是因为，经常叫你接新币种，大部分是国外的，英文文档，本人英文又不太好，有一些币种，文档又不全、难找。
然后我们做这个，安全性要求又高，压力好大，里面动不动几千万，我真怕哪天钱不见了找我赔。
还有就是做这个，一些有些客户的业务总是带一点灰色的，大钱又不是我赚，我真怕哪天我钱没赚到，人还进去了。

用 Tampermonkey 扩展吧，https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo
这个能编写自己的 js 脚本，自己写个脚本反覆盖回去就好了。

timestamp 接受一个时间字符串。
建议用 int 吧，我做了这么多项目，都是一直用的 int

这确实是个问题，需要今晚好好研究下

我劝你不要多管闲事 0 0 ！你举报了我们看什么

@daijinming 一两个域名，直接在 /etc/hosts 加一下挺方便的

参考 k8s，k8s 的内部集群通讯的域名解析，就是通过内置一个 dns 服务器实现的。

@abcbuzhiming 会删除 A 文件的，这是完全没有问题的，因为你自己说了，你解决 hotfix 的办法就是删除了 A 文件。那么 A 文件的存在就是一个 BUG，所以你希望的 dev 分支也解决掉这个 BUG，那你就是要删除了 A 文件，如果说，不删除 A 文件也能解决 BUG，那么就说明你前面为了解决 BUG 而删除 A 文件的行为不是最优解。

这里我再补充一点，只有非常紧急的 BUG，才走上面的一个流程。
正常修复普通不紧急的 BUG，个人建议最好还是走平时的正常流程（开分支->修复->测试->上线）。
git 是鼓励你频繁创建分支以及删除分支的，因为你线上使用的总是 master 分支，所以你的其他分支是无需合并本次 bug 修复的，因为该分支在开发完，就会被你删除，而后的新东西，你总是从 master 切个新分支出来。

或者你还有一个持久存在的 dev 分支，那么你的 dev 分支，应该总是不定时的从 master 分支获得修复反哺。

我们可以从优秀的项目身上借鉴经验，让我们来看一个案例，前段时间（ 4 月 15 日），以太坊柏林硬分叉，openethereum 节点进行 Berlin hotfix 的一个案例：

- https://github.com/openethereum/openethereum/pull/366

- https://github.com/openethereum/openethereum/commits/dev

我们观看上面两个链接的 git 工作流，可以看到他的 hotfix 流程大致是这样的：

- Merge branch 'berlin_hotfix' into release/v3.2.1
- Merge branch 'release/v3.2.x' into main
- Merge branch 'main' into dev

从这里相信你能看出，当出现一个紧急严重的 bug 的时候，你首先应该做的是第一时间、最短时间解决线上的漏洞，抛开一切繁琐的影响你解决问题的因素（不要再去想其他分支的事情了，你已经没有时间了）。

你首先应该从当前发布版本切出一个 hotfix 分支，修复后，第一时间将该修补提交合并到新的发布版本，这时候你已经完成了你最应该做的，最紧急的事情，接下来，你就可以按部就班的，逐步将该修复合并到其他分支。


当然，我们现实项目中，可能少了像开源项目有发布版本这个 tag，我们的线上可能就是 master 分支，但是原理是一样的。

@br00k 比如，我们正常希望前端给我们传一个这样的 URL 资源地址：/110/images/a.png ，结果他构造了这样一个地址：/110/images/a.png#disabledFeatures=[]&enabledFeatures=%20[]&indicatorsFile=data:application/javascript,alert(1)

我们应该如何去防范他？

@br00k 这种做法也行，和我那个效验指定域名的行为差不多，我就是想知道，他后面一部分相对路径的 URL，有没有可能构造出一个有攻击漏洞的 URL ？

@THESDZ 好的，谢谢

@learf 这个也可以，多了一步效验，感觉这样安全很多。

@THESDZ 诶，这个方案安全性很高咦，请问阿里云支持这个方案吗？有没有相关文档地址啊，感谢！

@imdong 上传是到了阿里的 OSS，不用我自己保管了，盗链也不用担心，阿里直接有防盗链功能。

@lazycat353 没有办法和途径获取到其他用户的临时 TOKEN 吧？如果有的话，那也是系统有其他漏洞造成的吧？而不是说这个授权模式存在问题。

@kongch 有用户登录的，存储空间问题不大，目前还不考虑限制用户，有效期内可使用，是没问题的，其他 APP 也是这样做的，因为这个临时 TOKEN，你自己的也只有你自己知道，用 APP 上次和你用脚本上次，最终结果是一样的，服务端效验好文件的合法性就好了。