博客作者通过排查网络请求，发现Gitalk评论功能的403错误源于公共CORS代理服务限制。通过查找GitHub仓库和Issue，找到了替代的CORS代理，并了解到应避免直接修改开源代码。最终通过配置Gitalk的proxy参数解决此问题，恢复了评论功能。
这是「进击的Coder」的第 343 篇技术分享
作者：崔庆才
来源：崔庆才丨静觅
“
阅读本文大概需要 3 分钟。
”事情是这样的，最近发现我的博客 cuiqingcai.com 的评论功能出现了问题，登录功能不好用了。经过一番排查，我找到了一些解决方案，在这里记录一下问题排查过程。
另外这个排查过程中可以总结出一些思路，大家如果碰到类似的问题，也可以按照类似的思路来排查。
友情提示：大家一定要读到最后或者直接拉到最后，最后内容的可能对你更有价值。
起因
我的博客最近刚换上了 hexo 框架，于是评论功能就换成了 Gitalk。但最近发现登录功能不好用了，点击使用 GitHub 登录总是失败。
就点击这个按钮的时候，始终登录不上去：
于是我就想着手解决一下这个问题。
思路
这里就记录一下我在排查过程中碰到的一些坑和解决思路。
首先，登录失败的问题，第一时间应该去排查的就是网络请求，打开控制台，查看 Network 面板，出现类似的结果：
网络请求直接 403 了，拿不到 token 了，于是就登录不上了。
观察下，这个链接 cors-anywhere 似乎是用来解决跨域限制的，后面还跟了一个 GitHub 的 Access Token 获取地址，那没跑了，前面这个就是一个反向代理，后面是真实的请求 URL。
OK，看着这个也没啥思路啊，然后接着怎么办？
那就接着去搜这个 cors-anywhere.herokuapp.com，因为 herokuapp 很眼熟嘛，就是一个公用的网址 Host 平台，类似于 AWS、Azure 之类的，那么前面这个可能包含某些信息。万一是开源的那就好办了。
接着搜，cors-anywhere，然后就搜到了这个：https://github.com/Rob--W/cors-anywhere
介绍如下：
“CORS Anywhere is a NodeJS proxy which adds CORS headers to the proxied request.
The url to proxy is literally taken from the path, validated and proxied. The protocol part of the proxied URI is optional, and defaults to "http". If port 443 is specified, the protocol defaults to "https".
This package does not put any restrictions on the http methods or headers, except for cookies. Requesting user credentials is disallowed. The app can be configured to require a header for proxying a request, for example to avoid a direct visit from the browser.
”
真是一个开源框架，和我猜的一样，就是一个解决跨域问题而生的反向代理。
然后我就在它的 README 中看到了这个：
好家伙，这不就是我刚才用到的链接吗？
那肯定是这个玩意出了什么毛病。
咋看呢？这个果断就是找 Issue 了：
一看，太明显了：
“PSA: Public demo server (cors-anywhere.herokuapp.com) will be very limited by January 2021, 31st
”
意思就是从今年 1.31 开始这个网站的访问会受限，点进去看看：
“The demo server of CORS Anywhere (cors-anywhere.herokuapp.com) is meant to be a demo of this project. But abuse has become so common that the platform where the demo is hosted (Heroku) has asked me to shut down the server, despite efforts to counter the abuse (rate limits in #45 and #164, and blocking other forms of requests). Downtime becomes increasingly frequent (e.g. recently #300, #299, #295, #294, #287) due to abuse and its popularity.
To counter this, I will make the following changes:
”
The rate limit will decrease from 200 (#164) per hour to 50 per hour.
By January 31st, 2021, cors-anywhere.herokuapp.com will stop serving as an open proxy.
From February 1st. 2021, cors-anywhere.herokuapp.com will only serve requests after the visitor has completed a challenge: The user (developer) must visit a page at cors-anywhere.herokuapp.com to temporarily unlock the demo for their browser. This allows developers to try out the functionality, to help with deciding on self-hosting or looking for alternatives.
好吧，意思就是说这个网站本来是演示用的，但是现在已经被滥用了，然后从 1.31 开始用户手动必须手动先访问这个网站获取临时的访问权限，然后才能使用。另外推荐开发者自己来维护一个网站。
接着下面的评论第一个就更滑稽了：
这个人直接艾特了 gitalk，哈哈哈，因为 Gitalk 就如刚才所说的那样，也用了这个。
那就顺便去 Gitalk https://github.com/gitalk/gitalk，逛一下 issue，看看是不是也有人遇到了同样的问题，果不其然了：
最近几个 issue 都是关于 403 的，真热闹。
点进去看看，有个大收获，里面有个好心人说：
“这次直接去嫖了一个CORS proxy,把gitalk.js的6794行改为 proxy: 'https://netnr-proxy.cloudno.de/https://github.com/login/oauth/access_token', 就可以了。具体能用多久我也没普，且用且珍惜。
”
真是得来全不费功夫，本来还想着自己部署着，这次那就换了就行了。
然而，这样不行，得需要改 gitalk.js 的源码，并不太好吧。
好，这时候就遇到了一个问题，要修改某些开源软件的源码应该怎么办？
首选的思路当然不是硬改，改了之后还要自己 host 一个新的 js 文件，那显然是很费精力的。
其实一半程序在编写的时候应该是预留一些接口和配置的，我们应该能很轻易地通过某些配置就能实现某些配置的复写。
那就接着看看吧，既然要改，那就得先看看 Gitalk 是怎么用的吧。
看文档，Gitalk 调用方式如下：
const gitalk = new Gitalk({
clientID: 'GitHub Application Client ID',
clientSecret: 'GitHub Application Client Secret',
repo: 'GitHub repo', // The repository of store comments,
owner: 'GitHub repo owner',
admin: ['GitHub repo owner and collaborators, only these guys can initialize github issues'],
id: location.pathname, // Ensure uniqueness and length less than 50
distractionFreeMode: false // Facebook-like distraction free mode
})
gitalk.render('gitalk-container')
看来这个在声明的时候是有参数的，那刚才 URL 配置没看到在哪里配啊，既然如此，那就看看 Gitalk 这个对象支持多少参数吧。
接着就去找 Gitalk 的构造参数说明，找到这么一个：
proxy：
String
Default: https://cors-anywhere.herokuapp.com/https://github.com/login/oauth/access_token.
果然找到了，所以这里如果我们要修改，那就改 proxy 参数就行了，初始化 Gitalk 的时候复写掉 proxy 就行。
OK，基本思路有了，那我怎么改到我的源码里呢？
我的博客是基于 Hexo 的 Next 主题的，根据经验，Gitalk 是 Next 主题自带的，所以 Gitalk 的声明应该就在 Next 主题源码里面。
那怎么找呢？
这时候就需要借助于一些搜索技巧了，搜什么？既然要用 Gitalk，那一定有刚才初始化的调用，那就搜 Gitalk 这个关键字就行了。另外还需要缩小一下搜索范围。
于是我就把范围限定到了 next 主题目录，搜索 Gitalk。
简直不要太舒服，一搜就有了，文件是 themes/next/layout/_third-party/comments/gitalk.swig。
这里我们只需要把 proxy 参数加上不就行了，值是什么呢？仿照写就行了，配置风格保持统一，那就加一条：
proxy : '{{ theme.gitalk.proxy }}',
OK，那这个配置的值很明显是主题配置文件，那就把配置文件里面加上 proxy 这个参数就好了。
找到 themes/next/_config.yml，添加行：
proxy: https://netnr-proxy.cloudno.de/https://github.com/login/oauth/access_token
结果如下：
好了，大功告成！
重新部署 Hexo，现在评论又能重新使用了，问题就解决了！
测试地址：https://cuiqingcai.com/message/，大家来给我留言吧～
好了，这就是我排查问题的整个过程，做一下记录。
经验
另外，其实这篇文章的用意不仅仅是单纯解决这个问题，因为这个问题大家可能并没有遇到过，因此这个解决方案仅仅是给极少数遇到这个问题的朋友提供的。
但是，这并不代表这篇文章没有价值，因为其中有的思路是通用的，在这里稍微做一下总结，希望对大家有帮助：
当遇到网页功能异常的时候，排查问题就主要看两个——控制台、网络请求，这里面往往能找到主要问题。
结合一些基本知识进行合理的推断，比如刚才我就推断了 cors- anywhere 的作用并结合 herokuapp 推断这个可能还会是个公用的服务。
当碰到没有思路或者不确定的时候，去谷歌它！不要百度，另外还可以在 GitHub 或者 Gitee 上搜。
如果找到对应的 GitHub 仓库，Issue 区往往能找到一些有效答案，比如刚才我就在 Issue 区找到了一个可替代的 cors 网站。
修改代码功能的时候要想着尽量复写，也就是 overwrite，而不是直接改，前者更具有灵活性，而且某些情况下会省去一些麻烦。
复写的时候去找一些参数配置，比如找一些初始化参数、默认参数配置，看看能否实现改写的需求。
找不到入口的时候善用全局搜索功能，比如刚才 Gitalk 找哪里调用的时候，就直接全局搜索。
根据功能限制某些搜索范围，比如刚才我就知道 Gitalk 这个功能是 Next 主题提供的，所以我就直接限制搜索范围是 Next 主题的源码。
以上步骤多尝试，熟能生巧。
作者：崔庆才丨静觅
隐形字
在这些地方分享自己的一些经验、想法和见解。
好文和朋友一起看~
扫一扫
291
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
