前言

前段时间有一个很神奇的需求，因为 cacti 的业务预警需求，我要在一个表内， 找到 5 分钟之内， 得到连接失败的去重复的设备数的数量和所有连接的去重复的设备数的数量， 然后得到 5 分钟内，按照唯一设备的失败率是多少，用一个 sql 表示。

处理

前言

前段时间有位好心的白客有发了一封邮件过来，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

Hi team, 
    
    this time i founded this vulnerability in your website.
    
    Vulnerability 9 : No csrf on login 
    
    Level : critical
    
    Login form is not protected against Cross Site Request Forgery.
    An attacker can craft html page containing POST information to have victim sign into an attacker's account, where the victim can add information assuming he/she is logged into the correct account, where in reality, the victim is signed into the attacker's account where the changes are visible to the attacker.
    
    The real issue here, is that when the victim runs the html Proof of Concept, the account is logged in to attacker's without any visible warnings, thus the victim is capable of theft of data and potentially vulnerable to account takeover.
    ...

简单的来说，就是虽然我们其他的业务接口都有 csrf token 的令牌校验，但是那是建立在用户登录后的情况下才下发的。 而恰恰登录接口是没有 csrf 校验，所以具备 CSRF 安全攻击的隐患，让我们赶紧修复。

修复问题

之前我们就非常重视 CSRF 的危害性 (具体看 web安全系列(1) - web 安全攻击和防护)，所以在用户登录的业务接口中，都会校验下发的 csrf token 令牌。如果校验不对，就认为非法请求。 但是恰恰登录接口是用来下发令牌的，所以这个接口就没有 csrf 令牌校验了。

前言

前段时间有位好心的白客有发了一封邮件过来，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Hi Team,
    
    This time I found this vulnerability in https://www.example.com/
    
    Vulnerability Type: Missing Certificate Authority Authorization Rule
    
    Description:
    
    Certificate Authority Authorization (supported by LetsEncrypt and other CAs) allows a domain owner to specify which Certificate Authorities should be allowed to issue certificates for the domain. All CAA-compliant certificate authorities should refuse to issue a certificate unless they are the CA of record for the target site. This helps reduce the threat of a bad guy tricking a Certificate Authority into issuing a phony certificate for your site.
    
    The CAA rule is stored as a DNS resource record of type 257. You can view a domain's CAA rule using a DNS lookup service:
    
    
    https://dns.google.com/query?name=example.com&type=A&dnssec=true    
     
     
    Vulnerable Location: https://caatest.co.uk/example.com
     
    ...

简单的来说，就是我们的站点并没有添加 DNS CAA 保护。 具有被中间人劫持的风险。 不过确实是这样子，那时候确实并没有为我们的站点添加 CAA 的 DNS 记录，这个是他的站点检测截图：

前言

前段时间有让 DBA 归档了一些数据库表，有包含统计表，也有包含一些业务表。 当然对于统计表来说，是会有定时归档的计划任务的。 不过这些事情一般都是由 DBA 来做，在请教了一下 DBA 之后，我也整理了一下 mysql 的数据库表的一些归档策略。

通用的归档逻辑

一般是以下面的图为例:

假设归档大表 A, 操作的过程大体分为 3 部分：

1. 生成只有原表 A 的表结构的空表 A_temp (ps, 这里有一个 id 自增长的 AUTO_INCREMENT的值的问题, 下文会分类说明), 这时服务端还是访问表 A
2. 对原表 A 和 A_temp 进行 rename 操作: A -> A_timeA, A_temp -> A, rename 操作会对相关的表加表级别的锁, 这个操作的时间很快(而且因为会锁表，所以也不用担心在这个过程 A 表会有入数据或者更新数据), 这时服务端访问的是新的表 A (也就是原来的空表 A_temp)

3. 因为归档时间范围问题, 一般我们需要将一些数据补偿回到新的 A 表中, 补偿的方式为分批执行:

   1	insert into A ... select ... from A_timeA WHERE ...

4. 归档 A_timeA 表，并且删除掉一些中间表(回补的时候，会涉及到将一些数据先存放到中间表)

前言

早在之前，有收到一个白客的邮件，说我们发送电子邮件的域名缺少安全检查，让我们最好补上对应的安全检查：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

I'm an independent cyber security researcher i have found multiple issues in your website.

Vulnerability : Missing SPF 


I am just looking at your SPF records then found following. SPF Records missing safe check which can allow me to send mail and phish easily any victim.

PoC:

<?php

$to = "VICTIM@example.com";

$subject = "Password Change";

$txt = "Change your password by visiting here - [VIRUS LINK HERE]l";

$headers = "From: https://karve.io";

mail($to,$subject,$txt,$headers);

?>
SPF record lookup and validation for: xxx.com

后面检查了一下，发现确实是这样子，我们的电子邮件没有加上对应的安全检查，很容易被别人冒发，从而有可能对我们的用户造成严重的电子邮件欺诈。

发送欺诈电子邮件的危害

举个例子，黑客可以通过这个站点 emkei.cz 来冒充我们的官方 support 邮箱来发送一些钓鱼邮件给用户。如果用户信以为真，那么就会对用户的利益造成损失，这就是电子邮件欺诈

前言

虽然在之前的文章有写过，怎么在 windows 7 上通过 docker 来实现多个 golang 环境, 并使用了 Go Module:

• windows7 通过 docker 来实现多个 golang 版本并存
• 初试 Go Module

但是事实上在本机进行开发的时候，还是本地环境装的 golang 环境开发起来更方便 (macOS 还好，差别不大，但是 windows 7 的 docker 实在不怎么友好)， 所以就打算将本机环境的 golang 版本升级到 1.13 版本。

升级 golang 版本

查看了一下，发现本机环境装的 golang 还是 1.7.6 这个版本，太老了

1
2

F:\airdroid_code\go\src\resque-worker-server>go version
go version go1.7.4 windows/amd64

前言

前段时间在小组轻分享中，有成员分享了 <项目百态> 这本书的其中一章 <巨神阿特拉斯>, 由于找不到电子版，所以就手动扫描了 这一章 的 pdf 版本, 这章后面提出来一个问题，有一位万能的，包打天下的领导，对团队来说，是福是祸 ？ 肯定是福，但要防止变成祸。本节描述了这样一个场景，并表明福变为祸的原因。不过，本节并没有提出明确的建议，让读者自己去思考。

思考

本来有这种领导对于下属来说是一件非常幸福的事情，但是一定要警惕，千万不能有 “溺爱” 现象，否则就会出现 “巨婴”。正是因为他太万能了，反而影响下属们的自然成长规律，尤其是下属的领导力和管理经验。总的来说，就是不懂得放权，或者是说是不舍得放权。而这就是祸。

对于这一点，我倒是挺有感触的，我接触技术管理也有 3-5 年了。对于放权更有感触，总结这几年的管理上的成长，我最感谢我领导的地方就是他懂得对我放权，允许我通过犯错误来得到成长。当然有一个很重要的前提就是，不要犯愚蠢的错误或者重复犯错。可以犯经验错误，但是有且仅有一次。

前言

之前有时候要紧急调试线上服务器的代码，一般都是用 Xshell 4 等工具，远程登录到服务器，然后直接用 vim 编辑代码。但是对 vim 语法不够熟练，而且有些代码比较长，显示也不太方便。 如果可以像本地 IDE 那样子显示服务器上的代码，并且直接编辑，实时保存就好了。后面找了一下，发现 vscode 配合他的一个插件 remote ssh， 就可以实现这个功能。

安装

做开发的应该没有人不知道 vscode 的吧，号称前端开发神器。 配合各种各样的插件简直无往不利。 首先去 这边 下载一个，因为我是 windows 7 的。所以就下载 windows 的版本了。

前言

通过 初试 Go Module 我们已经能够使用 Go Module 来安装项目的依赖包。 接下来我们试一下我们正式线上的项目，会有没有问题。

映射 ssh 文件夹

我们将一个叫做 resque-worker-server 的项目，放到容器中的共享目录 /go/src/ 中，并初始化 mod:

1

go mod init gitlab.airdroid.com/airdroid_background/resque-worker-server

然后接下来就直接构建 go build, 但是发现报错了:

前言

最近打算把服务端的一些 Go 服务升级到 1.13, 并且用上 Go Module 这个 Go 的第三方包管理机制。 虽然早在 Go 1.11 版本发布的时候，就推出了 Go Module 这个机制了，但是毕竟那时候还在跟 Go dep 撕逼呢, 而且是第一个版本出来的新机制，有点不敢用，怕入坑之后爬不出来。 一直等到了 1.13 版本，这个机制已经相对成熟了，而且几乎取代了 vendor 机制了，也被广大 gopher 接受了，所以是时候升级上来了。而且升级的代价其实不高，因为 Go 的版本发布几乎都遵守Go1兼容协议, 也就是说我们几乎不需要改代码依然有很大的概率可以编译成功(事实上改动的确实不多，无非就是针对 Go Module 机制，将一些第三方依赖的引用进行调整，具体的业务逻辑几乎不用动)。改动成本那么低，又可以告别 Go path, 采用更加优雅的 Go Module, 何乐而不为，所以本文主要是讲一下 Go Module 的一些简单试用。

前言

前面讲了很多关于 air-ui 组件的东西，包括多语言，主题定制，构建等等。但是其实一个组件库包含那么多的组件，在开发的时候，难免会遇到很多奇奇怪怪的问题，本节就讲一下在开发这些组件的时候，遇到的一些问题，以及怎么解决。(虽然很大程度上复用了 element-ui 的组件逻辑代码，但是难免还会有其他的坑)。

兼容 jsx 语法

之前在处理 jsx 语法的时候，有报错：

1
2
3
4
5
6
7
8
9
10

const wrap = (
  <div
    ref="wrap"
    style={ style }
    onScroll={ this.handleScroll }
    class={[this.wrapClass, 'air-scrollbar__wrap', gutter ? '' : 'air-scrollbar__wrap--hidden-default']}
  >
    { [view] }
  </div>
);

前言

在 自建vue组件 air-ui (14) -- 打包构建(dev 和 dist) 我们已经知道 air-ui 的 dev 构建 和 dist 构建。 接下来我们讲一下为啥还需要一个 pub 的构建任务，以及这个任务是用来干啥的。

直接将 master 分支作为第三方库拉取的分支

假设我们没有 pub 任务。直接就使用 dist 构建生成 lib 目录，然后将代码提交到 master 分支，并且用 master 打了一个 tag。
这时候我们就可以在某一个项目上用这种方式去加载 air-ui:

1

"air-ui": "git+ssh://git@gitlab.xxx.com:web/vue-ui.git#v0.0.4",

然后我们很顺利引用了:

1
2
3
4

import AirUI from 'air-ui';
import 'air-ui/lib/styles/index.css';

Vue.use(AirUI);

前言

UI组件的一个很重要的功能，就是允许可以定制化主题。 而且这也是为啥写组件的时候，要把对应组件的 scss 样式抽出来，不让其打包到 air-ui.common.js 的原因，这个原因就跟语言包为啥也要抽出来，不打包进去的原因。因为这样会增加 air-ui.common.js 的体积，而且我们要使用定制化主题的话，或者使用其他语种的，原有的打进去的默认主题和默认语种，就都没有用了。 所以这也是为啥当我们引入 air-ui.common.js 的时候，也要同时引用 css 文件的原因，因为 air-ui.common.js 并没有包含样式。

var.scss

为了更好的提供组件主题定制，我们规定所有可定制化的参数，全部写在 var.scss, 也就是说，假设我新做了一个组件，叫 dropdown, 并且我希望他有几个样式可以被定制化，那么就可以把参数写在 var.scss 文件里面 (这个文件不涉及到具体的 class 样式，全部都是参数), 那么就可以在这个文件加上以下参数：

1
2
3

$--dropdown-menu-box-shadow: xxx !default;
$--dropdown-menuItem-hover-fill: xxx !default;
$--dropdown-menuItem-hover-color: xxx !default;

前言

本节主要讲一下 air-ui 的打包。 air-ui 的构建主要分为 3 个环境:

1. 本地开发环境 dev
2. 打组件包 dist
3. 打 pub 包并打 tag pub

本节主要是讲一下前两种方式， dev 和 dist, 至于最后的 pub 方式,因为遇到的坑比较多，所以会再开一节来讲。

前言

通过上节 自建vue组件 air-ui (12) -- 国际化机制 我们已经知道怎么在 air-ui 进行国际化配置了。但是还遗留几个问题没有解决：

1. 我们现在是有默认引入 zh-CN.js 这个文件的，这样会导致我们后面打包出来的 air-ui.common.js 体积变大，我们要怎么将之抽出来？？
2. 组件单独打包出来的话，引入的时候，要怎么接入多语言机制？？

将语言包文件引用单独抽出来

我们知道在打 air-ui.common.js 包的时候，之所以会把语言包的 zh-CN.js 打进去是因为，只要入口文件有引用的话，那么默认就会打包进去，打包链是这样子的：

前言

air-ui 组件库的某些组件也会用到一些提示语，除了允许用传参来自定义之外，肯定会有预设值。 比如 air-select 组件的时候，可以允许搜索的，

如果搜索不到，会有一个默认提示： 无匹配数据， 这个就是这个组件的其中一个提示语预设值。而且这个预设值其实是中文。接下来我们看看是怎么实现的？

前言

通过上节 自建vue组件 air-ui (10) -- vuepress 写文档 (进阶版) 其实关于 vuepress 写文档的事情，也基本上能说的也差不多了。本节主要是在这个基础上再进行一下补充，将一些在 air-ui 组件库写文档中遇到的一些奇葩的问题，以及怎么解决的，这个也列一下，做一下备忘录。

第三方库 Popper 的报错

之前有遇到一个很奇怪的情况，就是写autocomplete demo 的时候，在本地运行中，是可以 work 的：

而且打包到另外一个项目用第三方库的方式引用，也是可以的：

1
2
3
4
5
6
7
8
9
10

<air-col :span="12">
    <div class="sub-title">激活即列出输入建议</div>
    <air-autocomplete
            class="inline-input"
            v-model="state1"
            :fetch-suggestions="querySearch"
            placeholder="请输入内容"
            @select="handleSelect"
    ></air-autocomplete>
</air-col>

但是一旦放到 vuepress 文档里面，就会报错？？

前言

通过上节 自建vue组件 air-ui (9) -- 用 vuepress 写文档 已经会写 button 标签的文档了。 并且写了 7 个例子用来描述 button 和 button-group 的属性，所以最后的 Button.md 的代码如下:

还是很详细的，具体文档效果上一节的最后有 gif 截图显示。 接下来我们继续写其他已完成组件的文档。

内置服务组件的文档怎么写？？

那么问题来了，对于标签组件的文档，我们还可以当做局部组件来引入。那么这种内部服务组件呢，或者指令类型的组件？？ 要怎么引入？？ 毕竟在 vuepress 环境下，可没有像 air-ui 项目那样，可以在 main.js 对组件库进行全局注册？？ 那么怎么找到 vuepress 的 vue 对象呢 ？？

前言

从前面的章节中，我们知道怎么创建组件，但是我们测试组件属性的时候，都写在 home.vue 中，而且只有 demo，没有配上对应的属性描述。所以接下来我们要做的就是开始为这些已完成的组件来写文档。

element-ui 的文档

我们可以看到 element-ui 的文档还是写的非常好的。

不过他这个文档的项目，其实就是他们自己写的。感兴趣的可以自己去看代码，就在源码项目的 examples 目录，执行 yarn dev 就可以把这个站点跑起来。它有例子也有对应的代码和注释。可以说非常的清晰。但是不适合 air-ui, 原因有两个:

1. 自己从头再去搞一个文档项目，性价比太低了，没有那么时间。
2. 他们是先写 demo 代码，再把代码通过 markdown-it 编译成 vue 文件，然后再嵌进去的，而且样式也是写在一起的。导致后面如果要新加一个组件的说明文档，得去调代码，调完代码再写进去。无论是扩展还是维护，其实成本都不低。

所以总的来说，看起来效果不错，但是真的不适合我，性价比太低。可以先看一下，最后 air-ui 成形的文档效果：

前言

在之前的文章中，我们已经知道怎么去创建一个组件了，并且怎么初始化，但是有没有发现一个细节，就是 element-ui 除了完整引入的方式，比如:

1
2
3
4

import ElementUI from 'element-ui';
import 'element-ui/lib/theme-chalk/index.css';

Vue.use(ElementUI);

还支持按需引入的方式：

1
2
3
4
5
6
7
8

import { Button, Select } from 'element-ui';

Vue.component(Button.name, Button);
Vue.component(Select.name, Select);
/* 或写为
 * Vue.use(Button)
 * Vue.use(Select)
 */

听说这种方式可以减少项目体积。 如果本节讲一下 air-ui 怎么做到按需引入。