前言

前段时间，有用户反馈 chrome 最新版本，无法在我们的远程站点连接本地的设备。 后面查了一下， 发现控制台有报了这个错误:

1

Access to script at 'http://192.168.197.81:8888/sdctl/comm/ping/?product=intl&des=1&callback=_jqjsp&_1633681289908=' from origin 'http://example.com' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `private`.

而且有些用户的 chrome 更奇葩， 请求 google 机器人校验的验证码的 api.js 也报了这个错:

1

index.html:1 Access to script at 'https://www.recaptcha.net/recaptcha/api.js' from origin 'http://example.com' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `local`.

排查

后面查了一下， 是 chrome 新版本 94 的问题， 他不允许线上远端的站点请求 本地local 的地址，比如 ip 地址，所以会报 CORS 错误。

但是为啥我们的一些 chrome 94 没有问题， 猜测应该是 A/B 测的原因。

前言

前段时间有一个好心的白帽子给我们反馈了一个安全问题，就是官网登录之后的重定向 url 存在安全隐患，导致有可能会泄露用户的 oauth token。

具体是这样子操作的, 因为我们的好多产品线，都是同一个地方做单点登录的(其实就是在官网), 然后登录之后，会根据不同的产品，然后在登录校验成功之后，返回对应产品线的 oauth token。 并拼接到 redirect url 后面。

正常情况下， 我们当然会在登录成功之后， 校验 redirect url 的合理性。 但是这个校验是有漏洞的:

1

/^http[s]?:\/\/.+\.example.com/ig.test(redirectUrl)

因为只判断域名是否有包含 .example.com 域名。并没有去判断一定是要 .example.com 域名结尾的。 导致最后被 biz.example.com.com 这种冒充的域名给通过了。

所以我如果是黑客的话， 我只要搞一个类似的 biz.example.com.com 的域名， 然后将这个我构建出来的登录页面 url 发送给受害者，让受害者去登录， 那么这个 oauth token 就会带到我的站点上来了。

1

https://my.example.com/en/signin/?redirect=https%3A%2F%2Fbiz.example.com.com

前言

我们的业务有上传服务，不管是我们自己的文件，还是用户生成的文件， 都会传到第三方的存储云服务中。 如果是国内用户，我们用的是七牛云服务， 如果是国外用户，我们用的是 aws 的 s3 存储服务。

如果是存放用户上传文件，一般我们建立的 bucket 就是私有桶。 正常情况下如果上传成功的话，一般文件都是完整的。 但是不排除网络丢包的情况， 那么我们怎么去保证我们上传的文件，一定是完整的呢。

最简单的方法，就是在上传到云服务之前，先把本地的文件进行 md5 计算，得到一个 md5 的 hash 值。 然后上传到云服务之后， 再去云服务请求这个文件的 md5 的值，两者对比，如果一致的话，那么文件就是完整的。

前言

前段时间，业务要上线一个 web 的业务，他是使用 webrtc 的技术去远程控制手机的。 但是使用 webrtc 连接过程中， 会涉及到大量的信息交互， 比如接口交互， signal 交互， ice 交互， sdp 交互。 有时候出现连接失败的情况， 需要开发人员去排查到底卡在哪一个环节。 但是 web 不像其他客户端，可以让用户提供某个目录下的某一个日志文件。 他在浏览器跑的， 一般关掉浏览器， log 也就没有了。 而且我们也不希望线上的产品，在浏览器的 console 控制台上输出一堆的 log， 显得很不专业。 而且也没有哪个用户会在运行的时候，打开 console 控制台的。

因为将这些连接失败的 log 上抛到服务端是必要的，虽然可以借助 indexDB 或者 localstorage 之类的 浏览器存储来暂时存放。 但是如果一整套都要自己做的话，真的太累了。 所以就萌生了直接找第三方开源解决方案的想法。 刚好有找到一个 美团点评开源的前端日志系统: Logan

Logan

Logan 开源的是一整套日志体系，包括日志的收集存储，上报分析以及可视化展示。它提供了五个组件，包括端上日志收集存储 、iOS SDK、Android SDK、Web SDK，后端日志存储分析 Server，日志分析平台 LoganSite。并且提供了一个 Flutter 插件Flutter 插件。

相关资讯这边不再说，本文也不是科普文，而是实操文，具体资料可以看:

• Logan
• Logan Web SDK
• 美团开源 Logan Web：前端日志在 Web 端的实现

前言

早在 2020-06-19 的时候，就有安装了 webrtc 的 SFU 开源框架 Kurento: 初试 webrtc SFU 开源框架 - Kurento, 那时候 node demo 脚本， kurento 服务， turnserver 是属于 3 台机器的。 本次搞了一个 16 核 32 G 的竞价型 云服务器。 打算在裸机的基础上， 直接在这台服务器上全部部署，并应用起来。 直接在这台性能比较强的机器上， 开个直播看看， 看看性能怎么样。

本次部署云服务器

16 核 32 G CentOS 7, 裸机

前置安装软件

安装翻墙软件

安装 shadowsocks

安装过程中，有些需要翻墙 (比如 docker， node 的安装)，所以要先把 翻墙环境搞定。 所以首先应该先处理翻墙环境， 参照我以前的教程: CentOS7 配置 shadowsocks 全局代理

前言

前段时间有位好心的 researcher 发了一封邮件过来，说我们有一个域名存在 子域名接管(subdomain tokeover) 的安全缺陷， 让我们赶紧处理。

还附上了他的 POC 截图

后面查了一下，确实这个我们的域名被接管了， 里面的 index.html 是 researcher 的。

前言

之前有个好心的白帽子有发了一个邮件过来，说我们有一个 aws s3 的桶有索引泄露的安全缺陷，让我们赶紧处理一下。

吓的我赶紧试了一下，按照他的 POC 截图来操作，结果还真是泄露了索引:

1
2
3
4
5

$ aws s3 ls s3://someCdnBucket
2015-08-15 11:01:02     276216 xxx.js
2015-09-01 20:26:19     101945 xxx2.js
2017-03-10 09:15:02      31751 xxx.css
...

确实可以通过 s3 的 cli2 的命令行工具，然后随便注册一个私人的 aws 账号，就可以通过 aws s3 ls s3://{bucketName} 来得到我这个项目的 bucket 里面的所有的文件索引了。

这个确实很严重， 因为如果知道了文件索引， 意味着这个公开桶的所有资源都可以被下载下来， 不幸中的万幸就是， 这个 bucket 是一个作为静态 CDN 源的公开桶， 只需要知道文件的 url 就可以访问， 里面的文件并没有用户的隐私数据。

而且这个 researcher 还表示了一个担忧， 既然我可以下载这些文件， 那么我可以上传或者从这个 bucket 删除文件吗?? 带着他这个疑问， 我这边也开始了排查。

前言

之前有 researcher 给我们发邮件说我们的一些站点的 tls 加密还支持 tls 1.0 和 tls 1.1 的协议。 这个是很不安全的。

而且会导致站点的评分会被降低， 可以用 ssltest 站点来测试, 而从安全性来评估的话，因为 tls 1.0 和 tls 1.1 的加密方式已经可以被破解了， 所以很容易招到攻击，比如以下攻击方式:

• BEAST Attack
• CRIME Attack
• Heartbleed
• FREAK Attack

所以不管是从站点评分上， 还是安全性考虑上， 我们都应该剔除掉 tls 1.0 和 tls 1.1 的加密方式，只采用 tls 1.2 的加密方式。 之所以为啥是 tls 1.2 而不是 tls 1.3， 也是因为 tls 1.2 是最广泛应用的。

前言

之前有针对图片的模板匹配有做了一个优化的版本: 使用 gocv 进行图片的模板匹配优化之 - 批量多模板匹配, 但是还不够，还需要再优化两个点:

1. 直接从 origin 文件夹里面读取原图，从 template 文件夹里面读取模板图，随后如果有匹配的话，将匹配圈出来的原图输出到 output 文件夹
2. 配置是否启用同步缩放匹配 (好处就是匹配速度很快， 坏处就是如果模板图信息太少的话，会出现匹配度太低的情况)

第一点优化很好理解，如果 原图很多， 模板图也很多的话， 肯定要变成直接读取，然后遍历文件夹的方式， 匹配结束之后，如果有匹配上，然后统一输出到另一个文件夹中

第二点是考虑到如果原图 size 很大，匹配的过程就会很耗费 cpu，而且时间会比较长。 所以可以设置缩放因子，将原图和模板图按照固定的比例进行缩放， 然后再匹配。 这样子做的好处就是因为双方的像素点变少了，所以匹配的速度就会很快， 坏处就是如果模板图的可识别区域比较少，再加上压缩之后，就会出现匹配度太低，导致我们认为无法 match 的情况。

所以最好模板图的尺寸不能低于 30px。 而且缩放的比例也不能高于 0.5， 这样子速度才会快。

前言

之前有针对图片的模板匹配有做了一个简单的版本: 使用 gocv 进行图片的模板匹配, 接下来针对做一下优化:

1. 之前代码写在一起， 现在当然要抽象出来
2. 允许多个原图进行多个模板来匹配
3. 最后输出的效果图，如果有多个模板匹配的话，都要全部圈出来

实操

首先 原图就两个 (1.jpg 和 2.jpg)， 然后模板图有3个 (分别是从 1.jpg 扣下一块， 从 2.jpg 扣下两块)。 最后奉上代码:

前言

之前成功安装了 gocv: CentOS 7 安装 GoCV, 今天就写个 demo 来测试一下。

demo 逻辑

逻辑如下， 在一张原图中， 从中截一个小片段出来，然后去匹配， 看看匹配度是多少， 然后在原图中圈出要匹配的模板的位置。

比如我从这一张原图中，截取艾斯右手燃烧的部分出来。

前言

前段时间， 业务上有需要用到图像识别的功能， 用的是开源的 OpenCV, 刚好我们的服务端语言 golang 有支持 OpenCV 这个开源库的库: GoCV

所以就在服务器上进行安装, 服务器环境就是 CentOS 7

操作之前

既然是 golang 的库，当前要先安装 golang:

1

yum install golang

安装后的版本是:

1
2

[root@VM-16-29-centos ~]# go version
go version go1.15.5 linux/amd64

开始安装

官方有 linux 的安装教程的: linux install

首先安装 GoCV 的包:

1

go get -u -d gocv.io/x/gocv

然后到目标目录:

1

cd $GOPATH/src/gocv.io/x/gocv

然后在该目录下执行安装就行了:

1

make install

如果一切顺利的话，最后打印应该是版本号:

1
2

gocv version: 0.26.0
opencv lib version: 4.5.1

所以就完啦 ??? 那写个毛线 blog， 没见过这么水字数的。 所以不出意外， make install 应该是报错了:

前言

前段时间有一个 php 的业务接口，响应时间很长， 超过了 10s， 然后 php-fpm 就显示超时了，然后 nginx 就返回 502 了。

虽然后面通过配置 php-fpm.conf 的这个设置，将其改为 20s (之前是设置为 10s)

1
2

[kbz@ip-10-1-2-146 ~]$  cat /usr/local/php/etc/php-fpm.conf | grep te_timeout
request_terminate_timeout = 20s

然后让前端的超时时间也改成 30s。 这样子接口是可以跑了， 但是还是慢。

后面发现是这个接口会去执行一些很复杂的运算逻辑，而且涉及到一些库操作。 但是在这之前需要返回给前端的数据都已经有了。

所以这一块执行时间比较长的运算逻辑其实是可以做成异步。 而我们目前项目的异步都是通过抛消息队列去处理的。 但是因为这一块逻辑涉及的相关联的函数比较多， 所以在消息队列那边再写一套也不现实。 如果是抛送 curl 单独执行这一部分逻辑的话，一旦响应时间超过了 20s， 也会 502。

前言

前段时间我们的官网上了新版本， 有将一些对 seo 不友好的旧页面的路由变成了新页面的路由。 比如将 bizHome.html 换成 business/, 但是其实内容是一样的。

刚开始为了保证旧页面不失效，在构建的时候，是将新页面和旧页面的内容都构建成一样的。 但是这样子一来， seo 的权重就被割裂了。

所以为了保证新页面的 seo 权重能够继承旧页面的权重。就要换成将旧页面的访问全部变成 301 的永久跳转到新页面上。

nginx 进行 301 跳转

如果要进行 301 永久性跳转的话，是没办法在前端层面上进行的。 只能在服务端上进行， 而我们用的是 webserver 是 nginx， 所以要在 nginx 上面配置。

假设我们这次要调整的页面有以下:

前言

之前有发生过一个比较奇葩的问题， 就是我们的测试人员有发生过， 移动端的 chrome 点击下载链接失效的情况。 但是 pc 端的 chrome 是正常的。 并且移动端的非chrome 浏览器， 比如 Firefox 或者 Safari 也是正常的。

排查

后面调试了一下，发现这个跳转用的是 window.open 语法:

1

window.open(url)

我们知道 window.open 的触发必须得有用户点击触发才行(具体可以看: 部分浏览器事件如果不是用户手动触发的话，会被浏览器block), 所以我们也是绑定到 click 事件中的。 所以应该不是这个问题， 因为如果是这个问题，其他浏览器也是不行的。

而且通过调试，我发现窗口是有弹出来的，但是一直卡在一个空的页面，并没有完整的跳转过去。 所以应该是 chrome 检测到这次的跳转不安全，所以禁止了。

而关于 window.open 还真有一个安全隐患，那就是子窗口可以得到父窗口 opener 句柄, 从而在用户不知道的情况下， 对父窗口的导航栏进行重定向， 这个其实对用户来说是一个安全隐患的， 我之前有写过这方面的安全和应用方法，具体可以看:

• web 安全之 - A 标签target=”_blank”的安全问题及解决办法
• window.open() 打开的子页面往跨域的主页面传参问题

他虽然是一个安全隐患，但是他并不是毫无用处的， 还是有其他用处的， 但是对于本例来说， 可能确实有这种问题，所以我就改成

1
2
3

var newWnd = window.open();
newWnd.opener = null;
newWnd.location = url;

改成这样子，果然 移动端的 chrome 浏览器就可以正常了。

当然如果只是点击下载的问题，那么可以不使用 window.open， 改成 a 标签跳转 或者 iframe 下载也是可以的。

前言

我们往往会在不同的网站上使用相同的密码，这样一旦一个网站账户的密码泄露，就会危及到其他使用相同密码的账户的安全。没错, 就是撞库行为, 往往你的站点的安全机制没有问题，但是架不住你的用户使用的密码跟其他被脱库的站点使用的密码一致(现在免费的社工库很多，随便写个简单的暴力碰撞程序(记得挂上代理)，就可以试出一堆可以正常使用的用户名和密码), 导致很容易通过撞库的行为从而知道这个用户在你站点的用户名和密码。 为了解决这个问题，一些网站在登录时要求除了输入账户密码之外，还需要输入另一个一次性密码。

而这个输入的一次性密码，其实就是我们所说的两步验证，这不是什么新奇的技术，国内都使用了N多年了，比如说银行用的动态令牌

再说一个大家比较有情怀的东西，就是早期网易的将军令(爷春回) 也是用的这个技术:

虽然不是什么新技术，不过早期因为手机的不普及，更多的是用硬件的方式来实现 (这玩意儿一旦没有电，就必须重新换一个，因为他没办法联网同步时间，不过这个耗电量极低，一个可以用好几年)。 但是随着手机的普及，以及大家的安全意识的提升。 越来越多的站点都用软件的方式来实现(比如 Evernote， Google， 以及我所在团队的站点)，而且成本很低。

前言

之前有出现过一种情况，就是我们的静态站点是有国内和国外加速的(这个是在 aws 的 router 53 服务配置的)，比如:

• 如果是国内访问的，那么就引导到腾讯云的 COS 存储服务 + CDN 服务
• 如果是国外访问的，那么就引导到 aws 的 S3 存储服务 + Cloudfront CDN 服务

正常的文件当然没问题，但是有时候会出现如果 url 后面不输入 index.html，直接子目录斜杠结尾，比如 https://m.foo.com/cast/ ，这时候腾讯云表现是正常的，因为他会索引到 https://m.foo.com/cast/index.html, 但是 aws 的 cloudfront 就不行，会直接报错， 显示获取 S3 对象失败:

1
2
3

[kbz@VM_16_9_centos ~]$ curl https://m.foo.com/cast/
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>QABCT7FCM4M3T4AR</RequestId><HostId>VnPLeZeR2KQkIMDrFhukmVLUGp+RBWbZO/V8qHeS0dGKLa1N8KOTbWvwNW/J2NKbQWqQXyP5wdw=</HostId></Error>

更有甚者，如果我连子目录的斜杠都没有写全，直接子目录的话，比如 https://m.foo.com/cast， 这时候腾讯云的表现也是对的，他如果找不到 cast 这个文件的话，就会将其当做一个子目录，再去检索这个子目录下的 index.html 文件。所以你用 curl 请求的话，会返回一个 302 跳转，然后 location 头部就会带上 https://m.foo.com/cast/, 这时候就会跳转到正确的页面:

前言

前段时间有遇到比较奇葩的需求，就是正常情况下，我们站点在进行第三方登录的时候，会通过 window.open 的方法，打开一个服务端的接口页面，然后这个服务端的接口去判断当前是否有授权行为，如果有的话，就写入 cookie，然后关闭当前窗体， 如果没有的话，就跳转到第三方的授权页面，然后在授权结束，回调的时候，写入 cookie，然后关闭当前窗体，前端会监听当前的窗体，当发现已经关闭的时候，就会去请求自动登录的接口，这时候，因为 cookie 信息已经让服务端写入了，所以这时候就可以正常登录，这时候前端还会读取服务端的某一个 token cookie， 然后生成当前一次性令牌 token， 以供服务端进行校验。

正常情况下是没有问题的，但是由于 chrome 浏览器在新版本的时候，cookie的默认设置会有 SameSite=Lax，这时候就会导致前端读取不了服务端的 cookie (chrome 默认 cookie 的 SameSite=Lax，导致 http 模式的站点的第三方 cookie 无法进行跨域传输)， 从而无法生成一次性访问 token 令牌， 这时候再去请求自动登录的接口，就会出现校验失败。

所以这边的想法是，服务端在生成 cookie 的时候，能不能在窗口关闭之前，往前端传 当前的一次性令牌的 token。这样子前端就可以带上这个 token 去进行自动登录的校验。

所以这边就会涉及到 window.open() 打开的子页面， 往主页面传参问题。

前言

之前有用户遇到一个问题，就是在访问一个我们的站点的时候，https 模式下没有问题，但是用 http 模式下(因为某些特殊原因，要保留站点的 http 模式的访问)，就会出现接口报错的情况，导致用不了。

而且都是 chrome 才有， 其他浏览器都正常， 而且 chrome 的版本还是比较新的， 87 或者 88。 我自己本身 86 好像挺正常的。 为了验证一下，也将 chrome 版本也升级到 88， 结果还真重现了。

SameSite 的问题

发现是登录接口的时候，原本要写进去的 cookie 虽然写了，但是再访问其他接口的时候，这些 cookie 根本不会带过去， 这样就导致没办法进行 cookie 校验了。 因为 cookie 在跨域的时候，并不会随着请求过去。

前言

我们知道一般无论是 CDN 还是 服务端的接口(nginx 配置gzip以优化站点资源加载速度)，在响应返回的时候，都会配置 gzip 来压缩响应数据，以达到减少体积，加快网络传输的效能。 但是 gzip 压缩只用于 response 的响应数据，一般来说针对 pc 端的站点来说，足够了。

但是有时候针对手机 app 来说，光是 response 用 gzip 压缩还不够， 因为 request 请求的时候，如果有时候 body 体带上很多数据的话，还是会导致体积很大，从而消耗流量。 手机的流量可比 pc 的流量贵多了。 因此对于有些比较注重流量消耗的 app 来说，最好也要做到 request 请求的时候，也用上 gzip 来压缩数据，然后服务端在 nginx 或者程序的网关那边，再根据请求头 Content-Encoding 是否为 gzip 来判断是否要对请求的数据进行 gzip 解压缩。