picgo-plugin-coding
picgo-plugin-coding copied to clipboard
zytomorrow
不能用了
2020-12-02 09:17:29 [PicGo INFO] Before transform
2020-12-02 09:17:29 [PicGo INFO] Transforming...
2020-12-02 09:17:29 [PicGo INFO] Before upload
2020-12-02 09:17:29 [PicGo INFO] beforeUploadPlugins: renameFn running
2020-12-02 09:17:29 [PicGo INFO] Uploading...
2020-12-02 09:17:29 [PicGo INFO] {"msg":{"oauth_user_scope_error":"当前的 scope 不支持访问此 API"},"data":{},"code":3015}
2020-12-02 09:17:29 [PicGo SUCCESS]
undefined
官方目前屏蔽了使用token上传文件的接口，现在有两个方案可以实现继续使用图床.
- 使用无头浏览器获取cooklie，然后再去请求接口--这个方式相对来说开销较大
- 作为备份库。使用github作为源库，然后源库配置workflow再推到coding的库，但是取coding的链接作为图床链接，这样保证了图片的打开速度。但是会消耗github资源。
方案2其实可以废弃该项目。只需要配置下github就行。 方案1不知道是否可以接受，可以接受的话，准备按这个方式修改。
比起方案二方案一的体验感知很小的。 但是毕竟是需要使用到无头浏览器，内存和cpu的消耗肯定比之前高出很多
主要是传 Github 上传时间较长...
但看起来方案一时间开销也不小？
主要是传 Github 上传时间较长... 但看起来方案一时间开销也不小？
比起方案二方案一的体验感知很小的。 但是毕竟是需要使用到无头浏览器，内存和cpu的消耗肯定比之前高出很多
原本一次post现在要变成一次get+一次post+调用headless browser？不过相比方案二是好很多
cpu和内存的消耗可能并不是很要紧...PicGo本身就好不到哪去(╥╯^╰╥)
走浏览器获取授权的版本发布了，大家可以尝试下。电脑上有新版的chrome或者firefox可以使用 picgo-plugin-coding-lite （这个版本我没测，尽可能还是使用标准版吧）。理论上来说，性能可以接受的。
主要是传 Github 上传时间较长... 但看起来方案一时间开销也不小？
比起方案二方案一的体验感知很小的。 但是毕竟是需要使用到无头浏览器，内存和cpu的消耗肯定比之前高出很多
原本一次post现在要变成一次get+一次post+调用headless browser？不过相比方案二是好很多
cpu和内存的消耗可能并不是很要紧...PicGo本身就好不到哪去(╥╯^╰╥)
可以在picgo的安装路径下执行 npm install [email protected]指定安装最新版本（现在直接升级可能还自动获取不到这个版本）
有问题反馈我
刚刚乱点点了个上传，没想到竟然上传成功了。
但是成功一次后又遇到了同样的问题，感觉应该是bug导致的。
尝试使用完整版吧，完整版目前我没出现过问题。你使用完整版有问题吗
刚刚乱点点了个上传，没想到竟然上传成功了。 但是成功一次后又遇到了同样的问题，感觉应该是bug导致的。
尝试使用完整版吧，完整版目前我没出现过问题。你使用完整版有问题吗
这个是使用完整版的时候出现的问题，Lite 一直不能用。
emmm，上传的时候把代理取消掉呢，刚没看见错误截图。你这个是页面等待超时了，默认的30s超时。
我尝试了上传8M的图片，耗时在17s左右。
有需要的话我把超时加大吧，后面版本会拦截请求，提高加载速度。
感觉不是代理引起的问题。
我连续上传若干张图片，第一张能上传成功，第二张及以后的图片则不能。
感觉有点玄学，但确实好多次这样，再等待若干时间后才能上传。不知道是不是 Coding 方面的限制。
另外超时有可能不是响应时间的问题，之前曾经把配置文件填错，也是同样的报 timeout。
upd：
检查了一下，并没有开代理。
且开关代理实验了一下，都会出现这样的现象。
~~呜终于考完学考了~~，来看了下大佬的代码。
https://github.com/zytomorrow/picgo-plugin-coding/blob/dd18265c8b872875980dda00cc6e98fbe0caab9e/src/index.js#L29-L38
timeout 应该是这一段的 page.waitForNavigation() 抛出的
观察了一下前半部分如果不能正常登录（如已经登录），就不会触发页面跳转，导致抛出超时。辅助这个推测的原因还有：
- 如果输入的账号密码或其他配置不正确，会抛出同样的 timeout 错误；因为这种情况下浏览器不会进行页面跳转
- 关于上文我描述的问题，“两次可以正常上传”的时间间隔，差不多刚好是 Coding 判定登录态过期的时间间隔
个人觉得我们可以先调用 upload 接口以判断 cookie 是否过期，如果过期再调用 getCookies() 函数，这样应该能解决问题，且在连续上传图片时也节省了大量时间开销
但是我不懂 PicGo 的插件怎么在多次调用间储存 cookie 数据（初步猜测可以直接存到内存里，还没有尝试过），希望大佬指教一下，谢谢！
如果猜想正确应该加入一段
await page._client.send('Network.clearBrowserCookies');
就能正常使用（参见 #16 ），但还是会有以下问题：
- 效率低
- 多次调用登录结构会被要求输入滑动验证码
所以还是应该寻求一个比较合理的解决方案（如上文所述），我尝试在本地写了一个，但没有调试出来，加上触发了滑动验证码，就咕咕咕了
~呜终于考完学考了~，来看了下大佬的代码。
https://github.com/zytomorrow/picgo-plugin-coding/blob/dd18265c8b872875980dda00cc6e98fbe0caab9e/src/index.js#L29-L38
timeout 应该是这一段的
page.waitForNavigation()抛出的观察了一下前半部分如果不能正常登录（如已经登录），就不会触发页面跳转，导致抛出超时。辅助这个推测的原因还有：
- 如果输入的账号密码或其他配置不正确，会抛出同样的 timeout 错误；因为这种情况下浏览器不会进行页面跳转
- 关于上文我描述的问题，“两次可以正常上传”的时间间隔，差不多刚好是 Coding 判定登录态过期的时间间隔
个人觉得我们可以先调用 upload 接口以判断 cookie 是否过期，如果过期再调用
getCookies()函数，这样应该能解决问题，且在连续上传图片时也节省了大量时间开销但是我不懂 PicGo 的插件怎么在多次调用间储存 cookie 数据（初步猜测可以直接存到内存里，还没有尝试过），希望大佬指教一下，谢谢！
把cookies写入配置文件是可以的，看了下过期时间，实际上可以保持48小时使用。但是效率还是低。
逆向了下整个过程：
- 第一步是任意界面拿去XSRF_TOKEN和eid
- 手动登录触发统一登录认证，把XSRF_TOKEN和eid放入cookie进行post请求
- 之后XSRF_TOKEN和eid关联同时生效，就可以正常使用API了
目前存在一个问题，手动登录请求发送的密码的加密方式还未找到处理方法。统一认证的的密码是经过了MD5加密。
我尽可能看下该加密方式行不行，可行的话效率可以提升到和之前一个级别，不可行的话就得输入两次密码，一次原始密码一次编码后的密码放进配置文件
如果猜想正确应该加入一段
await page._client.send('Network.clearBrowserCookies');就能正常使用（参见 #16 ），但还是会有以下问题：
- 效率低
- 多次调用登录结构会被要求输入滑动验证码
所以还是应该寻求一个比较合理的解决方案（如上文所述），我尝试在本地写了一个，但没有调试出来，加上触发了滑动验证码，就咕咕咕了
先去上班干活了，不摸鱼了，再摸鱼会被打死了。 方便的话可以加我联系方式，讨论下方案。多谢
