Zach Ke's Notes

Quick notes


  • 首页

  • 关于

  • 标签

  • 分类

  • 归档

  • 搜索

Nginx 的 location 匹配规则总结

发表于 2020-09-16 | 分类于 nginx相关 | | 阅读次数:

前言

之前在看 Nginx 的 location 匹配规则的时候,参考了一些网上的文章,但是这些文章,要么不全,要么就是有问题的,后面打算结合我自己的实践,自己写一篇算了。

本次实践的环境:

  • 系统: CentOS 7
  • Nginx 版本: 1.18.0

location 匹配的变量

Nginx 的 location 规则匹配的变量是 $uri, 所以不用管后面的参数 $query_string (或者 $args)

location 匹配的种类

格式主要是这个:

1
2
3
location [空格 | = | ~ | ~* | ^~ | @ ] /uri/ {
...
}

其实上面分为三部分:

  1. 最前面的字符 (location modifier) 匹配规则
  2. 后面 uri 的匹配规则 (location match)
  3. 大括号内的路由转发
阅读全文 »

CentOS 7 安装 Nginx

发表于 2020-09-15 | 分类于 nginx相关 | | 阅读次数:

前言

首先安装 nginx 的教程,网上到处都是,其实真没有为这个写 blog 的必要,当然之所以还是要写的原因无非是当初自己在安装的时候,虽然照着教程安装,但是还是有遇到了一些神奇的情况,当然后面都解决了,不过还是记一下比较好,后面自己要安装的时候,省的再去找网上的文章,自己看自己的 blog 它不香吗 ↖(^ω^)↗

安装 nginx 有两种:

  1. 直接系统安装,本文主要讲这种
  2. 使用容器安装,比如 docker

使用 docker 安装

这种方式很简单,直接执行一条指令就可以了:

1
docker run -d -p 80:80 --name webserver nginx

这样子就可以了,其中 -p 是端口映射, -d 就是以守护态运行

阅读全文 »

CentOS 7 systemctl reload nginx.service 不检查配置文件的问题

发表于 2020-09-15 | 分类于 nginx相关 | | 阅读次数:

前言

之前在测试 nginx 的 location 的匹配规则和优先级的时候,有测试了这么一种情况:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
location /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 ????

阅读全文 »

github建站系列(16) -- 为你的 blog 添加看板娘

发表于 2020-09-11 | 分类于 github建站系列 | | 阅读次数:

前言

前段时间又看到别人家的 blog 有看板娘了, 觉得挺好看的。 所以也打算搞起来。

参照这个第三方库来操作也很简单。 Live2D Widget

操作

1. 下载这个库到对应的目录

1
2
3
4
5
6
$   git clone "https://github.com/stevenjoezhang/live2d-widget" themes/next/source/live2d-widget
Cloning into 'themes/next/source/live2d-widget'...
remote: Enumerating objects: 423, done.
remote: Total 423 (delta 0), reused 0 (delta 0), pack-reused 423
Receiving objects: 100% (423/423), 960.57 KiB | 30.00 KiB/s, done.
Resolving deltas: 100% (263/263), done.
阅读全文 »

浅谈之 - HTML 的 meta 标签有多少种

发表于 2020-09-04 | 分类于 前端相关 , 前端浅谈系列 | | 阅读次数:

前言

meta 标签是 html 标记 head 区的一个关键标签,它位于HTML文档的 <head> 和 <title> 之间(有些也不是在<head>和<title>之间)。它提供的信息虽然用户不可见,但却是文档的最基本的元信息。meta 标签用来描述一个 HTML 网页文档的属性,例如作者、日期和时间、网页描述、关键词、页面刷新等。

meta 标签结构

从官方文档来看 : The Document-level Metadata element, 这个标签有四个属性:

  • charset
  • content
  • http-equiv
  • name

charset

charset 属性规定 HTML 文档的字符编码。 它是 HTML5 中的新属性,且替换了

1
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

虽然仍然允许使用 http-equiv 属性来规定字符集,但是使用新方法可以减少代码量。

常用的值有:

  • UTF-8 - Unicode 字符编码
  • ISO-8859-1 - 拉丁字母表的字符编码

在理论上,可以使用任何字符编码,但并不是所有浏览器都能够理解它们。某种字符编码使用的范围越广,浏览器就越有可能理解它。 如需查看所有可用的字符编码,请访问 IANA 字符集。

阅读全文 »

mysql 查询的时候时区转换为本地时区

发表于 2020-09-04 | 分类于 mysql遇到的小问题 | | 阅读次数:

问题

最近在做业务的时候,有遇到了一个问题,就是用户的连接记录在库里面存放的是 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。

阅读全文 »

使用 AWS Global Accelerator 加速你的服务

发表于 2020-08-13 | 分类于 aws 相关 | | 阅读次数:

前言

之前有用户反馈我们的服务接口请求速度慢,比如一个请求从请求到响应用了 1.5s, 但是我通过 nginx 日志来看的话,这一条请求处理的时间只有 0.2s, 也就是 http 请求在往返途中其实消耗了 1.3s。 所以如果要优化接口速度的话, 其实就是优化请求线路。

加速线路的几种方式

通常我们经常用的有以下三种:

1. 静态资源的 CDN 加速

这个也是绝大部分网站经常用的,就是通过 CDN 的边缘节点,进行静态资源的缓存,然后优先走最近的节点,从而节省请求时间。 各大云厂商都有提供这种服务,比如 aws 的 cloudfront。

2. 动态 CDN 加速

所谓的动态内容加速,是指用户在请求一些动态内容时,如网站中的 .asp、.jsp、.php和.cgi接口、API接口等,不直接请求源站,而是由基于地理位置的DNS调度,请求最靠近用户的云服务节点,再由云服务节点通过优化过的传输网络(公网,但比普通BGP更优化的链路),转发请求到源站,达到优化和加速的目的。当然这其中有很多其他的传输层面的优化,比如访问链路优化、传输内容压缩合并、智能选路、链路复用等技术。

阅读全文 »

记录一下自己常用的几个 shell 指令(备忘)

发表于 2020-08-06 | 分类于 系统相关 | | 阅读次数:

前言

感觉自己年纪越来越大,记性越来越不好使了, 所以想做个备忘。将自己常用的一些 shell 指令记一下。 一方面是有时候想用的时候,忘记了。 一方面是有些指令略长, 有时候也会忘记了一部分细节。 所谓好记性不如烂笔头。 还是做下备忘比较靠谱。 (天天用就还好,没那么容易忘,问题是有些指令半个月一个月才用一次,每次都会忘记一部分细节,也是蛋疼)

常用指令

1.查看程序重启是不是 oom 导致的

有时候程序会无缘无故重启,这时候就要看 error log,是 panic 还是 fatal, 但是有时候 error log 也是空的,但是这时候就要看是不是因为内存原因被系统杀死了,所以查看指令如下:

阅读全文 »

linux 使用 alias 来简化 docker 命令

发表于 2020-08-06 | 分类于 系统相关 , docker 相关 | | 阅读次数:

前言

自从 用 docker 来部署 mqtt vernemq 之后,后面的指令也会变得很长,比如,如果要进入容器的目录,就要这样子:

1
sudo docker exec -it vernemq-release-cn-1 /bin/bash

每次都要输入这么一大串,很麻烦,所以后面就考虑用添加别名的方式来弄。

编写 alias 命令

Linux操作系统中打开一些应用,有时需要进入对应的文件夹,打开对应的程序,不是很方便。alias命令是一种命令别名命名法,可以将一些复杂的命令简化成一个我们自己命名的相对简单好记的命令。能够极其方便我们的操作。

实操过程

阅读全文 »

github建站系列(15) -- Hexo博客NexT主题右上角添加fork me on github入口

发表于 2020-06-22 | 分类于 github建站系列 | | 阅读次数:

前言

之前看到别人的 blog 上面有一个黑色的 github 的 fork 入口,觉得还挺好的。 打算在自己的 blog 也搞一个。

操作很简单,可以参照这个博文 Hexo博客NexT主题右上角添加fork me on github入口

操作

将这一串代码复制到 themes/next/layout/_layout.swig 文件中<div class="headband"></div>下面一行即可

阅读全文 »

github建站系列(14) -- NexT 修改内容区域的宽度

发表于 2020-06-22 | 分类于 github建站系列 | | 阅读次数:

前言

我之前在 pc 上浏览我的 blog 的时候,发现旁边留白太多了,这样在浏览代码块时经常要滚动滚动条才能阅读完整,体验不是很好,同时觉得也不太美观。 所以想调整内容区域的宽度。

我参照这个文章调整: NexT | 修改内容区域的宽度

操作

NexT 对于内容的宽度的设定如下:

  • 700px,当屏幕宽度 < 1600px
  • 900px,当屏幕宽度 >= 1600px
  • 移动设备下,宽度自适应

如果需要修改内容的宽度,同样需要编辑样式文件。 而样式文件的位置在于

  • 主题的布局定义 Hexo/themes/next/source/css/_schemes/Picses/_layout.styl
  • 样式的用户配置 Hexo/themes/next/source/css/_custom/custom.styl
阅读全文 »

初试 webrtc SFU 开源框架 - Kurento

发表于 2020-06-19 | 分类于 webrtc相关 | | 阅读次数:

前言

最近有在看多方 webrtc 的解决方案: 多方 webrtc 的选择, 后面觉得 SFU 应该是不错的解决方案,而目前开源的 SFU 框架有好几个:

  • Janus
  • Jitsi
  • Kurento
  • mediasoup
  • Medooze

后面打算一个一个用下,看看效果, 所以本次先用 Kurento 这个框架看看效果。

阅读全文 »

多方 webrtc 的选择

发表于 2020-06-19 | 分类于 webrtc相关 | | 阅读次数:

前言

我们通常用的 webrtc 技术其实是一对一的 call,也就是 peer to peer。

ClientA 和 ClientB 如果能够顺利建立 P2P 的连接,则可直接通过 P2P 互相交换数据。如果由于某些网络环境原因,无法成功打通 P2P 连接的话,则可以通过一台 TURN Server 来中转数据给对方。

但是有时候我们会有一对多的情况,比如视频直播之类的(视频直播还有另一种技术: 推流 rtmp - cdn), 甚至是多对多的情况,比如多方会议。 这时候是没法满足的。所以我们需要对 webrtc 技术延伸出 一对多,甚至 多对多的 架构形式。结合网上的资料 (以下的资料和总结大量参考了文章底部列出的参考资料)。 要实现多方的 webrtc,有以下三种选择:

  • Mesh
  • MCU
  • SFU
阅读全文 »

docker 容器安装 vim

发表于 2020-06-19 | 分类于 docker相关 | | 阅读次数:

前言

有时候在使用 docker 容器的时候, 容器会默认没有安装 vim, 比如前段时间我在测试 kerento 的时候,要在容器中修改某一个配置文件,然后再重启,这时候在修改的时候,就会提示:

1
2
root@f596838cdaaf:/etc/kurento/modules/kurento# vim WebRtcEndpoint.conf.ini 
bash: vim: command not found

这时候就会提示 命令不存在。 这个是因为在创建 docker 镜像的时候,并没有把 vim 也放进去, 其实这个是非常常见,因为很多的 docker image 的创建都是基于那个最白版的 Ubuntu 系统,那个里面就没有 vim 命令,只有一些最基础的,比如 ls, cat 之类的,我们可以去 /bin/ 查看一下,当前所支持的 shell 指令:

阅读全文 »

一些很有意思的站点或者文章

发表于 2020-06-04 | 分类于 杂文 | | 阅读次数:

前言

因为自己的团队会定期进行好文好站的分享,发现一些文章或者站点非常有意思,又能学习,又不会枯燥,所以就记下来备忘一下。后续要学习或者推荐的时候,可以直接从这里拿

教你设计模式的神奇站点

推荐理由: 学不会设计模式,是因为你还没用过这个神奇的网站。图文并茂的方式讲设计模式,个人觉得这种方式更加利于记忆,也更加有趣。网站有包括中文在内的五种语言翻译,以及八种编程语言的代码示例

玩游戏也能写 git

推荐理由: 如果你觉得学习 Git 很枯燥,那是因为你还没玩过这款游戏!什么?玩游戏也能学git?是的,亲测简单又有趣,学习效果还真好,十分炫酷。大家一起来通关吧。

为什么这么设计系列文章

推荐理由: 很多技术人员耳熟能详的基础知识,但是你有深究为啥要这么设计吗,比如为啥 js 中 0.1 + 0.2 不等于 0.3 吗? 为什么 Mac 地址不需要全球唯一 ? 为什么总是需要无意义的 ID ? 这些设计理念当初都是怎么来的 ? 这个是一个开始看就停不下来的站点

阅读全文 »

web 安全之 - 使用 CVSS V3.0 来判断安全漏洞的严重性

发表于 2020-05-25 | 分类于 web安全 | | 阅读次数:

前言

作为一个站点,肯定少不了那些好心的 researcher 给你的站点或者服务提出各种各样的安全缺陷, 让你去修改,并且适当的给他们一点奖励。 所以如何评价安全漏洞的危害性就显得很重要, 毕竟你也不希望一个小安全问题就给一大笔现金奖励吧,钱多也不是这么花的。 而且除了对安全漏洞评分之外, 还需要根据不同的危害性给予不同的奖励。 比如我们就是以 CVSS 3.0 标准来对安全漏洞进行级别划分,并且根据以下级别进行奖励:

  1. 无危害性 –> 0 –> 没有奖励
  2. 低危害性 –> 0.1 - 3.9 –> 我们产品的一年 vip 使用权限
  3. 中危害性 –> 4.0 - 6.9 –> $xxx 现金奖励
  4. 高危害性 –> 7 - 10 –> $xxxx 现金奖励

接下来接下来讲一下 CVSS 3.0 是一个怎么样的标准:

阅读全文 »

web 安全之 - 开启HSTS让浏览器强制跳转HTTPS访问

发表于 2020-05-25 | 分类于 web安全 | | 阅读次数:

前言

前段时间一位好心的白帽子发了一封邮件过来:

1
2
3
4
5
6
Hi 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 检测截图

png

阅读全文 »

web 安全之 - A 标签target=”_blank”的安全问题及解决办法

发表于 2020-05-14 | 分类于 web安全 | | 阅读次数:

前言

前段时间,有位好心的白帽子给我们发了一封邮件,讲了一个关于 A 标签target=”_blank”的安全问题:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Hi 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 我们的主页,不过这些大的站点一般也不会太大的危害,但是当务之急还是将这些外链的这个安全问题修复一下。

阅读全文 »

web 安全之 - 页面禁用 referer(第三方站点的 referer 头部泄露重置密码链接)

发表于 2020-05-07 | 分类于 web安全 | | 阅读次数:

前言

之前有个好心的白帽子有发了一个邮件过来:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
i 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 头部来得到这个重置密码的链接,比如下图:

阅读全文 »

web 安全之 - 关于重置密码链接的几个安全问题

发表于 2020-04-29 | 分类于 web安全 | | 阅读次数:

前言

最近一直有在处理一些安全问题,其中有几个是跟重置密码链接相关的安全问题, 所以就想谈一谈关于重置密码链接的几个安全问题,包括以下几个情况:

  1. 刷忘记密码接口使其一直发送邮件
  2. 第三方站点的 referer 头部泄露重置密码链接
  3. 发送新的重置密码链接的时候, 并没有将旧的重置密码链接设置为无效
  4. 重置密码链接用过之后并没有马上设置为无效
  5. 登录密码长度没有限制
  6. 重置密码成功,其他端的 session 就要全部设置为过期。 客户端要重新进行登录
  7. 修改邮箱的时候,要将未失效的重置密码邮件都设置为无效
  8. 重置密码的校验接口,要做速率限制

因此我们在设计这个功能的时候,一定要严防以上情况。

阅读全文 »
123…13
Zach Ke

Zach Ke

做最咸的那一条

246 日志
27 分类
57 标签
GitHub
© 2021 Zach Ke
由 Hexo 强力驱动
|
主题 — NexT.Pisces v5.1.4