之前在看 Nginx 的 location 匹配规则的时候，参考了一些网上的文章，但是这些文章，要么不全，要么就是有问题的，后面打算结合我自己的实践，自己写一篇算了。
本次实践的环境:
Nginx 的 location 规则匹配的变量是 $uri, 所以不用管后面的参数 $query_string (或者 $args)
格式主要是这个:1
2
3location [空格 | = | ~ | ~* | ^~ | @ ] /uri/ {
...
}
其实上面分为三部分:
首先安装 nginx 的教程，网上到处都是，其实真没有为这个写 blog 的必要，当然之所以还是要写的原因无非是当初自己在安装的时候，虽然照着教程安装，但是还是有遇到了一些神奇的情况，当然后面都解决了，不过还是记一下比较好，后面自己要安装的时候，省的再去找网上的文章，自己看自己的 blog 它不香吗 ↖(^ω^)↗
安装 nginx 有两种:
这种方式很简单，直接执行一条指令就可以了:1
docker run -d -p 80:80 --name webserver nginx
这样子就可以了，其中 -p 是端口映射， -d 就是以守护态运行
之前在测试 nginx 的 location 的匹配规则和优先级的时候，有测试了这么一种情况:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15location /images/test.png {
return 200 'config1';
}
location ^~ /images/test.png {
return 200 'config2';
}
location ~ \/images\/test\.png$ {
return 200 'config3';
}
location ~ /images/ {
return 200 'config4';
}
然后我每次执行的时候:1
2
3[root@VM_156_200_centos conf]# sudo systemctl reload nginx.service
[root@VM_156_200_centos conf]# curl http://127.0.0.1/images/test.png
config4
神奇的情况发生了， 执行结果竟然是 config4, 怎么看都觉得是 config2 才是对的。 因为如果普通匹配和正则匹配都存在的话， ^~ 的匹配如果是最长的话，那么肯定是以 ^~ 为准的。 那么为啥是 config4 ????
前段时间又看到别人家的 blog 有看板娘了， 觉得挺好看的。 所以也打算搞起来。
参照这个第三方库来操作也很简单。 Live2D Widget
1 | $ git clone "https://github.com/stevenjoezhang/live2d-widget" themes/next/source/live2d-widget |
meta 标签是 html 标记 head 区的一个关键标签，它位于HTML文档的 <head> 和 <title> 之间（有些也不是在<head>和<title>之间）。它提供的信息虽然用户不可见，但却是文档的最基本的元信息。meta 标签用来描述一个 HTML 网页文档的属性，例如作者、日期和时间、网页描述、关键词、页面刷新等。
从官方文档来看 : The Document-level Metadata element, 这个标签有四个属性:
charset 属性规定 HTML 文档的字符编码。 它是 HTML5 中的新属性，且替换了1
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
虽然仍然允许使用 http-equiv 属性来规定字符集，但是使用新方法可以减少代码量。
常用的值有:
UTF-8 - Unicode 字符编码ISO-8859-1 - 拉丁字母表的字符编码在理论上，可以使用任何字符编码，但并不是所有浏览器都能够理解它们。某种字符编码使用的范围越广，浏览器就越有可能理解它。 如需查看所有可用的字符编码，请访问 IANA 字符集。
最近在做业务的时候，有遇到了一个问题，就是用户的连接记录在库里面存放的是 UTC 时间，但是在前端显示的时候，却要根据用户的本地时间来显示对应的数据。
举个例子，比如用户在前端选择查询 2020-08-20 和 2020-08-25 这段时间的连接记录。 假设这个用户当前用的是 北京时间， 也就是东八区，那么这时候， 在 mysql 进行查询的，应该就是查询 2020-08-19 16:00:00 和 2020-08-24 16:00:00 这段时间的连接记录, 因为减掉 8 小时，才是库里面真正存的 UTC 时间。
所以具体的连接记录展示是没问题的。 但是还有另一个需求， 就是用户想知道 2020-08-20 和 2020-08-25 这段时间每天连接了多长时间， 这个就不太好处理了，因为涉及到 group by date, 而这个 date 字段在库里面存放其实是 UTC 时间，那么 group by 其实只是按照 UTC 时区来的，而不是按照本地时区的 GMT 时间。 所以我们要先把它转换为 GMT 时区，然后再 group by。
之前有用户反馈我们的服务接口请求速度慢，比如一个请求从请求到响应用了 1.5s， 但是我通过 nginx 日志来看的话，这一条请求处理的时间只有 0.2s， 也就是 http 请求在往返途中其实消耗了 1.3s。 所以如果要优化接口速度的话， 其实就是优化请求线路。
通常我们经常用的有以下三种:
这个也是绝大部分网站经常用的，就是通过 CDN 的边缘节点，进行静态资源的缓存，然后优先走最近的节点，从而节省请求时间。 各大云厂商都有提供这种服务，比如 aws 的 cloudfront。
所谓的动态内容加速，是指用户在请求一些动态内容时，如网站中的 .asp、.jsp、.php和.cgi接口、API接口等，不直接请求源站，而是由基于地理位置的DNS调度，请求最靠近用户的云服务节点，再由云服务节点通过优化过的传输网络（公网，但比普通BGP更优化的链路），转发请求到源站，达到优化和加速的目的。当然这其中有很多其他的传输层面的优化，比如访问链路优化、传输内容压缩合并、智能选路、链路复用等技术。
之前看到别人的 blog 上面有一个黑色的 github 的 fork 入口，觉得还挺好的。 打算在自己的 blog 也搞一个。
操作很简单，可以参照这个博文 Hexo博客NexT主题右上角添加fork me on github入口
将这一串代码复制到 themes/next/layout/_layout.swig 文件中<div class="headband"></div>下面一行即可
我之前在 pc 上浏览我的 blog 的时候，发现旁边留白太多了，这样在浏览代码块时经常要滚动滚动条才能阅读完整，体验不是很好，同时觉得也不太美观。 所以想调整内容区域的宽度。
我参照这个文章调整: NexT | 修改内容区域的宽度
NexT 对于内容的宽度的设定如下：
如果需要修改内容的宽度，同样需要编辑样式文件。 而样式文件的位置在于
我们通常用的 webrtc 技术其实是一对一的 call，也就是 peer to peer。
ClientA 和 ClientB 如果能够顺利建立 P2P 的连接，则可直接通过 P2P 互相交换数据。如果由于某些网络环境原因，无法成功打通 P2P 连接的话，则可以通过一台 TURN Server 来中转数据给对方。
但是有时候我们会有一对多的情况，比如视频直播之类的(视频直播还有另一种技术: 推流 rtmp - cdn)， 甚至是多对多的情况，比如多方会议。 这时候是没法满足的。所以我们需要对 webrtc 技术延伸出 一对多，甚至 多对多的 架构形式。结合网上的资料 (以下的资料和总结大量参考了文章底部列出的参考资料)。 要实现多方的 webrtc，有以下三种选择：
有时候在使用 docker 容器的时候， 容器会默认没有安装 vim， 比如前段时间我在测试 kerento 的时候，要在容器中修改某一个配置文件，然后再重启，这时候在修改的时候，就会提示:1
2root@f596838cdaaf:/etc/kurento/modules/kurento# vim WebRtcEndpoint.conf.ini
bash: vim: command not found
这时候就会提示 命令不存在。 这个是因为在创建 docker 镜像的时候，并没有把 vim 也放进去， 其实这个是非常常见，因为很多的 docker image 的创建都是基于那个最白版的 Ubuntu 系统，那个里面就没有 vim 命令，只有一些最基础的，比如 ls, cat 之类的，我们可以去 /bin/ 查看一下，当前所支持的 shell 指令:
因为自己的团队会定期进行好文好站的分享，发现一些文章或者站点非常有意思，又能学习，又不会枯燥，所以就记下来备忘一下。后续要学习或者推荐的时候，可以直接从这里拿
推荐理由: 学不会设计模式，是因为你还没用过这个神奇的网站。图文并茂的方式讲设计模式，个人觉得这种方式更加利于记忆，也更加有趣。网站有包括中文在内的五种语言翻译，以及八种编程语言的代码示例
推荐理由: 如果你觉得学习 Git 很枯燥，那是因为你还没玩过这款游戏！什么？玩游戏也能学git？是的，亲测简单又有趣，学习效果还真好，十分炫酷。大家一起来通关吧。
推荐理由: 很多技术人员耳熟能详的基础知识，但是你有深究为啥要这么设计吗，比如为啥 js 中 0.1 + 0.2 不等于 0.3 吗? 为什么 Mac 地址不需要全球唯一 ? 为什么总是需要无意义的 ID ? 这些设计理念当初都是怎么来的 ? 这个是一个开始看就停不下来的站点
作为一个站点，肯定少不了那些好心的 researcher 给你的站点或者服务提出各种各样的安全缺陷, 让你去修改，并且适当的给他们一点奖励。 所以如何评价安全漏洞的危害性就显得很重要, 毕竟你也不希望一个小安全问题就给一大笔现金奖励吧，钱多也不是这么花的。 而且除了对安全漏洞评分之外， 还需要根据不同的危害性给予不同的奖励。 比如我们就是以 CVSS 3.0 标准来对安全漏洞进行级别划分，并且根据以下级别进行奖励:
0 –> 没有奖励0.1 - 3.9 –> 我们产品的一年 vip 使用权限4.0 - 6.9 –> $xxx 现金奖励7 - 10 –> $xxxx 现金奖励接下来接下来讲一下 CVSS 3.0 是一个怎么样的标准:
前段时间一位好心的白帽子发了一封邮件过来:1
2
3
4
5
6Hi team,
I found another potential bug on your site.
Description
The application fails to prevent users from connecting to it over unencrypted connections. An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection. The sslstrip tool automates this process.
To exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defences such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.
大意就是说我们的站点虽然有强制 https 请求，但是并没有添加 Strict-Transport-Security，所以有可能会遭受 SSL 剥离攻击。 建议我们赶紧加上。
最后 POC 附上 hstspreload 检测截图
前段时间，有位好心的白帽子给我们发了一封邮件，讲了一个关于 A 标签target=”_blank”的安全问题:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16Hi team,
I am security researcher and i found this vulnerability in your website
https://www.example.com/en/
Vulnerability report: Tab nabbing
`
Issue lies Here :
< a class="item-social-icon item-social-icon-twitter" href= "http://twitter.com/#!/Team" target="_blank" data-type="footerNav-goTwitter" >
Here i can see you are using target=_blank and no more rel tag.
Here , target=_blank means it will open in another new tab but due to tab nabbing it can change parent tab as well .
FIX & MITIGATION :
To mitigate this issue we need to use rel="nofollow noopener noreferrer" as follows:
吓的我赶紧检查了一下，这个问题确实存在，我发现官网的部分外链的 A 标签是通过 target="_blank" 来跳转的，所以就会存在这个安全问题。 万幸的是， 我们官网的外链大部分都是我们自己的内部网站。只有少部分是真正的外链, 比如 facebook，Twitter， YouTube 我们的主页，不过这些大的站点一般也不会太大的危害，但是当务之急还是将这些外链的这个安全问题修复一下。
之前有个好心的白帽子有发了一个邮件过来:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15i am a security researcher and i founded this vulnerability in your website.
I have found that you are leaking via the referrer the reset password link. I am attaching the photo as proof of concept that the site is indeed leaking the reset password link via the referrer.
Proof of concept:
图片1
图片2
图片3
Thats when someone loads the reset password link and decided to click on external links.
Impact
Password Reset Token will be leaked by the Server to that third party site and that token can be used by third parties to reset the password and take over the account.
Thanks
他说我们的忘记密码功能的重置密码链接，会加载第三方统计，这时候带过去的 referer 头部就会将这个页面的 url 带过去，从而暴露了重置密码的 token。
我分析了一下，发现重置密码这个页面，确实在加载第三方统计的时候，referer 头部会将整个 url 当做值带过去, 也就是这些第三方程序是可以在用户进入这个重置密码页面的时候，通过 referer 头部来得到这个重置密码的链接，比如下图：