前段时间，运营人员有反馈在钉钉邮箱收到我们服务的邮件的时候， 有显示一个代发 字样, 在问能不能去掉， 而且不仅仅是钉钉邮箱， 国内的 qq 邮箱， 163 邮箱，都会有这个 代发 提醒，类似于
看样子是显示 010001819d4f0433-21f905e9-ad1a-48a0-8177-9966cbc581a0-000000@amazonses.com 这个代发，跟我们实际的发送邮件的 发件人邮箱 no-reply@example.com 不是同一个域。
所以刚开始怀疑是因为这两个域不一样导致的
可以在 SES 后台自定义这个发件人邮箱的 mail from 域，配置也很简单，这样子就配置好了
这段时间一直在处理浏览器 webrtc 投屏的事情，不管是其他端(android, ios, win, mac) 投给浏览器， 还是浏览器自己投给浏览器, 都会涉及到双向语音。
在这期间有踩了一些坑， 干脆就记录一下。
webrtc 浏览器要发送语音，那就是要启用麦克风来收集音频，然后传给对方。 因为浏览器可以作为投屏的投屏端(source)，以及接受投屏的客户端(node), 这两种情况下的处理方式是不一样的，所以就分开讲。
本文不是科普文，所以对于 webrtc 的一些技术，不在这边进行基础讲解
浏览器作为客户端(node)启用麦克风将语音传给对方，在我的实作中， 其实有 3 种:
前段时间测试人员在测试一个新的站点的时候， 有发现在旧的 ios 上，会出现页面加载失败的情况， 会报 ssl 错误:1
The certificate for this server is invalid.
但是在其他的比较新的 ios 或者 android 上， https 的页面又显示正常。 而且证书看起来也没有过期。
后面查了一下，因为这个站点，我们那时候用的是 Let’s Encrypt 签发的免费证书， 而这个证书在一些比较旧的系统上，比如 iOS < 10 , macOS < 10.12.1 会有证书的不信任问题。
接下来我们简单的盘一下为啥会这样子
在说到 Let’s Encrypt 这个 CA 机构之前，我们得先了解一下什么是 CA 机构。 而在讲 CA 之前，要先了解一下 HTTPS 的加密方式， 这一部分资料网上很多， 我这边长话短说
前段时间，有运营的同学反馈有一个不应该被 google 搜索收录的站点，被收录了， 并且在 google 搜索结果中，可以看到搜索结果。
正常情况下，我们如果站点不想被 搜索引擎 爬虫进行收录的话， 是会在根目录下的 robots.txt 设置 disallow。
所以我检查了这个站点的 robots.txt 文件，看是否有配置这个文件，或者这个路由(有些是没有实体 txt 文件的，而是在 nginx 那边根据 robots.txt 路径来进行返回)1
2
3[kbz@centos156 ~]$ curl https://example.com/robots.txt
User-agent:*
Disallow: /
检查了一下，确实有配置所有的爬虫都是 disallow。 那么为啥还会被收录呢， 会不会是 robots.txt 的语法有问题?
为了检查 robots.txt 的语法是否有问题，我就采用了一些第三方工具来进行验证
刚开始用 百度的 robots 工具 来检查 robots 文件是否存在以及合法性
前段时间有个需求， 就是我们有做一个 web 的投屏端， 可以将另一个客户端(比如 android，ios，win，mac) 投屏到 web 站点来。 但是期间因为涉及到引流， 所以针对投屏的客户端是否在同一个局域网下要做不同的判断，如果在同一个局域网下，那么就可以免费使用，如果不是的话，就会有其他的引导。
所以我们得到客户端的 ip 地址之后，需要判断当前浏览器是否跟这一台客户端在同一个局域网下。 有几种判断方式
以下的测试数据，都是基于 chrome 98 的浏览器， 早期的浏览器可能会有不同的表现
最简单的方式就是让这个客户端开启一个本地端口，就是类似于 ip+port 的方式，可以是 http ，也可以是 websocket 的方式。 然后让浏览器去请求这个端口。
如果可以请求成功，那么就说明是在同一个局域网。 不过这边有几个问题:
前段时间运营需要对投递发送的邮件进行更详细的追踪用户行为分析，包括邮件发送的成功率，是否有被退回，反弹，是否有被打开，以及打开之后，是否有点击邮件里面的链接，点击的是哪个链接。
其实关于在邮件里面进行用户行为分析的话，早期的话，有用 ga 的方式试过:
这个的好处就是适合各种的邮件发送服务厂商， 坏处就是只能统计邮件打开率， 其他的比如退回，拒绝，反弹都不行。
不过我们用的邮件发送服务是 AWS 的 SES 服务，他其实是有匹配的邮件监控事件机制的。 甚至我们之前还结合另一个通知服务 SNS 来统计邮件的反弹率:
本身邮件的反弹率就是邮件监控事件的一部分了，所以那时候就有 touch 到这个点了。
关于 nginx 设置 CORS 跨域的事情，其实在我之前的一些文章都或多或少都有提到，比如:
但是都没有比较详细的代码，导致我有时候要写的时候，都要自己查自己写的文章，所以就自己写一个比较通用的范例， 后面用的时候，直接抄就行了。
至于 CORS 原理就不再多说了，网上到处都是。 这边给出的通用范例要符合以下标准
Access-Control-Allow-Origin 我不会设置为 *, 因为除了不安全之外，还会与设置携带 cookie 的这个 Access-Control-Allow-Credentials 有冲突Access-Control-Allow-Origin 会有一个默认值，但是为了对开发环境更友好，也会有一个白名单的二级域名，只要在这个二级域名下的子域名，也都是可以符合所以具体配置如下:
之前在对项目进行安全渗透测试的时候，有发现我们有一个图片上传接口，有暴露出一个 任意文件上传 的安全缺陷问题。 这个是一个高危的漏洞。
后面查了一下代码，发现原来只在前端有对上传的图片进行 图片的后缀名校验， 服务端是没有校验文件类型的。 所以如果是在 postman 中进行上传操作的话(有拿到合法的 session 的情况下)， 是可以绕过前端验证，直接上传任意文件的，包括 .php 文件。
一般情况下文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。
文件上传本身是web中最为常见的一种功能需求，关键是文件上传之后服务器端的处理、解释文件的过程是否安全。
前段时间公司有请了安全服务公司来给公司的项目做 安全渗透， 尤其是 web 应用的安全渗透。 其中可测试点非常多。
其实关于 web 安全方面， 我之前也写了一些文章: 分类 - web 安全, 但是更多的是各种的安全的案例以及对应的解决方案。好像还没有从大的方向上来总结和归纳。
所以本次我也想总结一下 web 安全渗透到底是什么，为什么要做， 以及怎么做?
渗透测试（Penetration Test）是指安全工程师尽可能完整地摸拟黑客使用的漏洞发现技术和攻击手段，对 目标网络/系统/主机/应用 的安全性做深入的探测，发现系统最脆弱的环节的过程，渗透测试能够直观的让管理人员知道自己网络面临的问题。
前段之前产品有个需求， 想要对一个申请页面的修改进行 A/B 测试, 从而判断出是哪个页面的转化率会比较高。 所以需要前端人员针对原先的 申请页面 进行 A/B 测试。
简单的来说就是:1
2
3
4
5
6
7用户访问的还是同一个入口: mobile-device-management-free-trial/index.html
然后 A 用户 得到的是旧页面: mobile-device-management-free-trial-old/index.html (这边为了区分，将旧页面的路由改成 old)
然后 B 用户 得到的是新页面: mobile-device-management-free-trial-new/index.html
而且还会有多语言，比如: zh-cn/mobile-device-management-free-trial/index.html
然后 A 用户 得到的是旧页面: zh-cn/mobile-device-management-free-trial-old/index.html
然后 B 用户 得到的是新页面: zh-cn/mobile-device-management-free-trial-new/index.html
然后新旧页面的各自流量是一半。
nginx 的 ngx_http_split_clients_module 可以满足这种需求，可以用来实现流量的分流 (当然也可以实现负载均衡)。 而且该模块是默认就载入的，不需要额外再载入。
之前官网重构的时候，为了保证原页面的 seo 权重，就有针对一些旧页面路由进行 301 重定向到新路由。 具体看 nginx 通过 301 跳转将旧页面的 seo 权重转移到新页面上， 但是后面又提了一个新需求， 就是针对一些路由进行目录结构上的调整。
比如原先是 a.html 后面会移动到 product/a.html， 而且 html 的名称还不能变。 所以这时候从用户访问来看就是:1
2
3访问 www.foo.com/a.html --> 301 重定向 --> www.foo.com/product/a.html
考虑到大部分是有小语种路径的，比如 zh-cn，那么就是
访问 www.foo.com/zh-cn/a.html --> 301 重定向 --> www.foo.com/zh-cn/product/a.html
如果是原先这种方式的话:1
2
3if ($request_uri ~* "a.html") {
rewrite ^/(.*)a.html$ /$1product/a.html permanent;
}
就会发现其实重定向后的 url 也是符合这个规则的，就会导致 nginx 无限重定向。 所以这样子是不行的
之前有处理过 nginx 转发代理 wss 和 https (目标程序是 ws 和 http), 后面发现我们的服务还有一些是 tcp 长连接，而且还是支持 tls 的 tcp 长连接。 这个也是非 80 和 443 端口的。 后面也需要用 nginx 转发代理一下。
nginx 1.9 开始支持 tcp 层的转发，通过 stream 实现的，而 socket 也是基于 tcp 通信，跟 ws 和 wss 不一样， 本质上 ws 虽然也是长连接， 但是他是基于 http 的协议上去进行协议升级的，所以可以写在 http 指令串里面。
但是 tcp 不支持，而且依赖的模块也不一样，他依赖的是 ngx_stream_core_module， 这个模块也是要单独安装的。而且这个 stream 块， 只能放到 nginx.conf 文件中，不能放到 site-avaliable 目录中， 不然就会变成 http 的。
安装 nginx，stream 模块默认不安装的， 通过 /usr/local/nginx/sbin/nginx -V 查找
事情是这样子的， 我们现在 golang 版本是 1.13, 并且采用了 Go Module 作为第三方包管理工具: 初试 Go Module, 正常情况下我们有一个内部的公共库，比如叫 igong， 存放一些公共抽象出来的方法， 供各个程序去调用。
有一次，我正常给 igong 包打 tag 之后，tag 版本号为 v1.8.7, 这时候我们的具体程序去更新这个 igong 包的时候， 却报错了:
1 | F:\example_code\gopush-air>go get -u gitlab.example.com/example-utils/iGong |
发现在更新这个 igong 包版本的时候， 获取某一个依赖的时候， 一直报错。 好像一直去下载一个不存在的资源 https://github.com/qiniu/bytes， 这个包在 github 上已经找不到了。
后面去 igong 包看了一下，发现 igong 项目的 go.mod 确实是有间接引用这个包，不过之前是因为这个包已经不在 github 上面了， 所以就用 replace 将下载地址引入到我们自己的内部私有库，让其可以下载并应用:1
replace github.com/qiniu/bytes => gitlab.example.com/qiniu/bytes v0.0.0-20191012100200-92558a444c07
前段时间有用户反馈我们的一个服务有问题， 查了一下，发现我们的一个 wss 的长连接服务被挡掉， 后面原因是因为这个 wss 的长连接服务的端口因为不是常见端口，导致被有些公司内网的路由策略屏蔽掉了。 而如果是常见的 443 的 tls 端口的话， 大部分都是跟 80 一样默认开放的，也就不会有这些问题。
1 | C:\Users\Marco\Downloads\paping_1.5.5_x86_windows\paping_1.5.5_x86_windows>paping.exe 192.xx.xx.162 -p 9088 -c 4 |
而且还有遇到过 联通/电信的物联网卡的问题, 这种卡对 tls 加密通道以及对应走的端口其实是有限制的:
但是问题来了，因为我们的这种 wss 的长连接服务比较多，有时候一个服务器就要部署好几个， 而一台服务器的 443 端口只能被一个程序接管， 如果这个 wss 程序接管了， 那么同一台服务器的另一个 wss 程序就无法接管了。
然后就想到我们的一台服务器同时部署多个 https API 服务， 然后统一由 nginx 这个程序来托管并代理 443 端口。 这样子就大家都可以用 443 端口的 https 服务了。 因此 wss 应该也是类似的。
所以我们本次实验要实现两个效果:
前段时间，有用户反馈 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 开源的是一整套日志体系，包括日志的收集存储，上报分析以及可视化展示。它提供了五个组件，包括端上日志收集存储 、iOS SDK、Android SDK、Web SDK，后端日志存储分析 Server，日志分析平台 LoganSite。并且提供了一个 Flutter 插件Flutter 插件。
相关资讯这边不再说，本文也不是科普文，而是实操文，具体资料可以看:
早在 2020-06-19 的时候，就有安装了 webrtc 的 SFU 开源框架 Kurento: 初试 webrtc SFU 开源框架 - Kurento, 那时候 node demo 脚本， kurento 服务， turnserver 是属于 3 台机器的。 本次搞了一个 16 核 32 G 的竞价型 云服务器。 打算在裸机的基础上， 直接在这台服务器上全部部署，并应用起来。 直接在这台性能比较强的机器上， 开个直播看看， 看看性能怎么样。
16 核 32 G CentOS 7, 裸机
安装过程中，有些需要翻墙 (比如 docker， node 的安装)，所以要先把 翻墙环境搞定。 所以首先应该先处理翻墙环境， 参照我以前的教程: CentOS7 配置 shadowsocks 全局代理
