现代化的PHP-写好注释

注释

有个段子：程序员最恨写注释和不写注释的人。个人认为注释主要作用是方便别人或者自己以后能快速理解这段代码逻辑和提升开发效率，这样要说的是如何使用注释来提升开发效率。

总所周知，PHP 是弱类型语言，变量的类型是可以变的，但在实际业务中，一个变量或者函数的返回值往往是确定的，确定的类型能提升我们的编码效率，也能把一些低级的错误（弱类型不代表无类型）扼杀在摇篮里。

PHP 主要通过类型声明来说明变量的类型，PHP7 开始允许更多的函数参数类型限定。比如下面这个例子，声明入参是 int 类型，但使用了 array 函数来处理，PhpStorm 能给出实时的提醒。

调用函数参数错误的话也有提示：

但 PHP 会有隐式类型转换，如上面传入浮点数的时候并没有提示错误，因为这也是合理的。不过 PHP 可以开启严格模式来检查此类错误。

PHP 内置的类型声明基本上够用了，但一般使用注释来实现更加丰富的功能。PHPDoc 是注释 PHP 代码的非正式标准，它有许多不同的标记可以使用。PhpStorm 能根据函数/类方法自动生成基本的标记：

基本标记 @param 和 @return 也很好理解，参数和返回值，作用和 PHP 自带的类型声明差不多，主要用来限制调用方传参和使用返回值。除了这两个标记之外，还有很多其它比较好用的标记。

Continue Reading…

GitHub 研发链 travis-ci 和 codecov 介绍

经常混迹于 GitHub 的话就会发现很多项目都有一些徽章，出现最多的就数这两个了：

这些徽章都是可以点击的，第一个点进去是 https://travis-ci.org/，travis-ci 是一个 CI（Continuous integration，持续集成） 平台，主要提供集群编译、单测、集成测试的环境。.org 的服务对公有仓库免费，.com 面向私人、团队、公司的项目提供商业支持（收费）。使用起来非常简单，使用 Github 帐号登录进去，就能看见开始界面：

核心就是.travis.yml的文件配置，一开始可以根据自己的语言选择初始的配置文件：https://docs.travis-ci.com/user/customizing-the-build#Specifying-Runtime-Versions。我这边的项目使用的是 Python，初始配置是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
language: python
python:
  - "2.6"
  - "2.7"
  - "3.2"
  - "3.3"
  - "3.4"
  # PyPy versions
  - "pypy"  # PyPy2 2.5.0
  - "pypy3" # Pypy3 2.4.0
  - "pypy-5.3.1"
# command to install dependencies
install:
  - pip install .
  - pip install -r requirements.txt
# command to run tests
script: pytest

官方注释可以说非常详细，我就不画蛇添足做说明了，根据自己代码实际情况做调整即可：

1
2
3
4
5
6
7
8
9
10
language: python
python:
  - "2.7"
# command to install dependencies
install:
  - pip install -r requirements.txt
# command to run tests
script:
  - nosetests -sv tests
  - nosetests -c demo/nose.cfg demo

配置好之后再 push 代码，就能在 travis-ci 页面上看见项目的构建、测试结果了：

点击图标就能生成我们需要的 MD 语法的代码了，粘贴进 README.MD 中就能显示了。

第二个徽章是 codecov.io（单测覆盖率统计平台），接入过程也很简单，也是不同语言选择不同的配置文件，codecov 可以无缝衔接 travis-ci，只需要在原来的配置文件上稍作修改即可，核心就是生成单测的结果文件。修改后的 .travis.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
language: python
python:
  - "2.7"
# command to install dependencies
install:
  - pip install -r requirements.txt
  - pip install codecov
# command to run tests
script:
  - nosetests -sv --with-coverage --cover-tests --cover-package=py_http_api_test tests
  - nosetests -c demo/nose.cfg demo
after_success:
  - codecov

在原来的基础上多了 codecov nose 插件的下载和运行单测时多了--with-coverage等参数。最后还是再次 push 代码就能看见单测覆盖率报告了：

codecov 还有自己的配置文件：codecov.yml。用来实现一些定制化需求，比如说我需要排除一些模块，不进入覆盖率统计：

1
2
3
4
5
# https://docs.codecov.io/docs/ignoring-paths
ignore:
  - "tests/*"
  - "demo/*"
  - "py_http_api_test/http_test.py"

徽章生成代码的话在setting中可以找到：

除了上面介绍的这两个徽章，还可以通过 shields.io 平台生成一些其它的徽章，甚至可以自定义，比如 https://img.shields.io/badge/Python-2.7-brightgreen.svg 就可以生成一个表示 Python 版本的徽章，别人能看懂就行。

1
[![Support Python Version](https://img.shields.io/badge/Python-2.7-brightgreen.svg)](https://www.python.org/)

当然徽章不是重点，不是越多的越牛逼，重要的是规范整个研发流程。上面说的两个其实都是属于 CI（持续集成）中最具代表性的两个环节，算是入门了。关于 CI 是一个很大的话题了，这个有机会以后再说一下。

参考资料：

开源项目徽章集锦，https://segmentfault.com/a/1190000004278253

使用 Python nose 组织 HTTP 接口测试

现在前端 Web、移动端 APP 开发基本上是面向接口编程，后端各种 HTTP 接口已经提供好了，大家只要实现逻辑交互和展示就行。那么问题来了，这么多接口如何方便的进行测试呢？根据个人经验，我认为需要解决三个问题：1. HTTP 接口多种多样，测试程序如何统一？2. 测试程序如何规范组织？3. 接口间有上下文依赖，如何解决？

HTTP 接口多种多样，测试程序如何统一？

后端接口可能来自各个系统，GET/POST 协议的、遵循 RESTful 规范的，使用 session 认证、token 认证的，各式各样的接口都存在。但无论怎么变都无法脱离 HTTP 协议。因为组内的技术栈是 Python，这就很容易想到使用 Python 的 requests 库。首先我们使用requests.Session()会话对象，来进行会话保持和 Header、Cookie 等处理。这里我们可以简单封装一个 HttpSession 类，把一些常用操作和设置封装一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
import requests
# 屏蔽https安全警告
# https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
from requests.packages.urllib3.exceptions import InsecurePlatformWarning
from requests.packages.urllib3.exceptions import InsecureRequestWarning
from requests.packages.urllib3.exceptions import SNIMissingWarning
requests.packages.urllib3.disable_warnings(InsecurePlatformWarning)
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
requests.packages.urllib3.disable_warnings(SNIMissingWarning)
 
 
class HttpSession(requests.Session):
    """
    http请求会话
    """
 
    def __init__(self):
        super(HttpSession, self).__init__()
        # 不校验SSL证书
        self.verify = False
        # 超时时间
        self.timeout = (60, 600)
 
    def update_cookies(self, cookies):
        """
        更新当前会话cookie
        :param cookies: cookie字典
        """
        requests.utils.add_dict_to_cookiejar(self.cookies, cookies)
 
    def update_headers(self, headers):
        """
        更新当前会话的header
        :param headers: header字典
        """
        self.headers.update(headers)

通过HttpSession()来获取一个requests session对象，后续的 HTTP 请求都通过它发起。requests 提供 get()、post() 等各种方法调用，但这会让测试代码显得不统一，这里我们直接调用底层的 request 方法，该方法几乎提供了发起一个 HTTP 请求需要的所有参数，非常强大。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
http_session = HttpSession()
 
def test_get_access_token(self):
    """
    获取access_token
    """
    params = {
        "corpid": 'corp_id',
        "corpsecret": 'corp_secret',
    }
 
    response = http_session.request(
        'GET',
        config['dingtalk_oapi'] + '/gettoken',
        params=params
    ).json()
 
    data = response['access_token']
    print data is not None

这样每一个 HTTP 接口的测试都可以通过准备参数、发起请求、断言结果三板斧来解决。

测试程序如何规范组织？

前面我们已经解决了如何快捷的发起一个 HTTP 请求的问题，这让我们几行代码就可以测试一个接口的返回值。但你会发现新的问题又来了，各种脚本散乱在一堆，返回值解析各种中间变量，各种配置硬编码在代码中，测试结果全靠 print，这时 nose 框架就派上用场了。nose 是 Python 最流行的一个单测框架，提供测试 case 设置标签、测试 case 查找、强大的断言函数，格式化/可视化报告输出等功能。这样就可以像写单测一样写 HTTP 接口测试了。我们可以把一类接口的测试放在一个类里面，甚至可以把基础变量的定义放在基础测试类里面，其它测试类继承这个基类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
try:
    import ConfigParser
except ImportError:
    import configparser as ConfigParser
import os
import sys
import unittest
 
import nose.config
import ruamel.yaml
 
from py_http_api_test.http_session import HttpSession
 
 
class HttpTest(unittest.TestCase):
    """
    http接口测试类
    """
    # case配置信息(执行环境)
    config = []
    # http会话对象
    http_session = HttpSession()
 
    @classmethod
    def setUpClass(cls):
        """
        初始化配置信息和http_session对象
        :return:
        """
        env = None
        nose_cfg = None
        argvs = sys.argv[1:]
        for idx, arg in enumerate(argvs):
            # 直接获取case配置文件路径
            if '-env=' in arg:
                env = arg.split('=')[-1]
                break
            # 获取nose的配置文件
            if '--config=' in arg:
                nose_cfg = arg.split('=')[-1]
            if '-c' == arg:
                nose_cfg = argvs[idx + 1]
        # 未获取到case配置文件路径，尝试从nose配置文件中获取
        nose_config_files = nose.config.all_config_files()
        if env is None and (nose_cfg is not None or len(nose_config_files) > 0):
            if nose_cfg is None:
                # 用户未指定nose配置文件，则从系统全局配置文件中获取
                nose_cfg = nose_config_files[-1]
            if not os.path.isabs(nose_cfg):
                nose_cfg = os.getcwd() + '/' + nose_cfg
            cf = ConfigParser.ConfigParser()
            cf.read(nose_cfg)
            try:
                env = cf.get('others', 'env')
            except ConfigParser.Error:
                env = None
 
        if env is not None:
            # 参数不是绝对路径
            if not os.path.isabs(env):
                # 根据当前工作路径获取到绝对路径
                env = os.getcwd() + '/' + env
            with open(env) as f:
                inp = f.read()
            cls.config = ruamel.yaml.safe_load(inp)
 
    @classmethod
    def tearDownClass(cls):
        cls.http_session.close()

HttpTest基类只做了两个工作：1. 创建http会话对象；2. 读取配置文件到类变量config中。配置文件是一个很好的编程实践，这让我们测试程序和数据能够分离，可以通过调用不同的配置文件来测试不同环境的接口，让我们测试程序不光能做线下测试，还能做线上回归和监控，切换成本非常低。

我这里选择 yaml 语法来组织配置信息，yaml 语法风格类似 json，自带基础数据结构，但更加易于书写和阅读，非常适合做配置文件。通过-env=xxx指定配置文件路径（或者 nose.cfg 配置文件中指定），使用 ruamel.yaml 来解析 yaml，转换为 Python 中能直接操作的数据结构。

1
2
3
4
5
6
7
%YAML 1.2
---
# http://open-dev.dingtalk.com/#/corpAuthInfo
dingtalk_oapi: 'https://oapi.dingtalk.com'
corpid: 'dingc2ac01025c48fb7635c2f4657eb6378f'
corpsecret: 'RTw5Vbsh6uKSOu2G25wOmQjQK6SA2NOHNyfHtlEgzQ-CWmvjoGH3c4a-MWTzaJ6Q'
department_parentid: 52711158

这一切都放在setUpClass方法中，在具体测试 case 运行之前就已经准备好这些工作了。 Continue Reading…

WordPress通用优化策略及常用插件推荐

WordPress 安装很方便，可以说是开箱即用。但是随着文章增多，访问量增大，会发现 WordPress 很“慢”。这是 WordPress 本身的 PHP 运行机制导致的，每篇文章都要去数据库读取，而且 WordPress 为了支持各种功能，现在已经非常臃肿，每次请求都要加载很多东西。但正是 WordPress 的功能强大，让我们也能很方便的做各种优化。

0x1 使用最新版本的 PHP 和 MySQL

毫无疑问升级基础运行环境是提高性能最好的方式之一。特别的 PHP7 和 MySQL 5.7 较之前的版本性能提升很大。还可以根据服务器配置适当调整 PHP-FPM 和 MySQL 参数。

0x2 使用缓存插件

这里的缓存有两层意思，一是 PHP 层面的运行数据缓存，二是文章页面静态化。这里推荐两个插件来解决这个问题：

1. Redis Object Cache 一款持久对象缓存插件。其实 WordPress 本身带有对象缓存功能，但是是把序列化的对象缓存在文件中，效果不是很好。这个插件通过重写 object-cache.php 文件，把对象缓存到 Redis。直观的感受就是不光前台页面加载速度快了，而且后台响应速度提升更大。

2. Cache Enabler keycdn 公司开发的一款页面静态化缓存的插件。相比 wp-supercache 等插件更加简洁和强大。建议按照官方说明进行增强设置。我使用的是 Nginx，除了正常设置 gzip 外还开启了 gzip_static 参数，让 Nginx 在读取文件的时候优先读取带 gz 后缀的静态文件，不用再做 gzip 压缩。

顺带推荐一个 gzip 检查网站：https://www.giftofspeed.com/gzip-test/

不过使用高级设置后需要把缓存有效期设置为 0（永不失效），可能会造成缓存不会被更新（正常情况下更新文章缓存会被更新）。这里我是通过删除缓存文件然后访问自己 sitemap 中的链接来刷新缓存：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# rebuild cache according to sitemap.xml
 
import os
import requests
import xml.etree.ElementTree as ET
import time
import shutil
 
 
CACHE_DIR = "/var/www/wordpress/wp-content/cache/cache-enabler/"
SITEMAP_URL = "https://static.iyaozhen.com/sitemap.xml"
 
if os.path.isdir(CACHE_DIR):
    shutil.rmtree(CACHE_DIR)
    try:
        sitemap = requests.get(SITEMAP_URL)
    except (requests.HTTPError, requests.ConnectionError) as e:
        print("get sitemap.xml error: %s" % e)
    else:
        urlset = ET.fromstring(sitemap.content)
        print("start rebuild cache at %s" % time.asctime())
        for url in urlset:
            loc = url[0].text
            try:
                requests.get(loc)
            except (requests.HTTPError, requests.ConnectionError) as e:
                print("request %s error: %s" % (loc, e))
            else:
                print("hit %s" % loc)
            finally:
                time.sleep(0.1)
else:
    print("no cache dir: %s" % CACHE_DIR)

https://gist.github.com/iyaozhen/53e6a57a2f7e945ba1161953959a7cb2

0x3 使用 CDN 和图片压缩

用户有时候感觉网站慢，更多的是静态资源加载慢。页面上的 JS、CSS、图片等都需要消耗服务器带宽。而且中国地域辽阔，跨地区、跨运营商更是问题。这时就需要 CDN 了。现在国内各个云都在相互竞争，CDN 比较便宜，免费的也有很多。我之前使用的是七牛云，不过自从服务器迁到腾讯云之后， CDN 也换到了腾讯（免费12个月）。这里推荐同为 keycdn 出的 CDN Enabler 插件，能将页面中的链接替换为 CDN 链接。同时推荐使用 WP Smush 压缩图片，还有使用 BJ Lazy Load 实现图片懒加载（显著提高首屏加载速度）。最后不要忘记站点和 CDN 都配置一下防盗链。

0x4 升级到 HTTP2

HTTP2 支持请求复用，能提高50-70%的加载速度。首先要配置 HTTPS，再简单的配置下就能支持 HTTP2 了。当然静态资源使用的 CDN 最好也要支持 HTTP2，目前国内就又拍云和老牌 CDN 厂商支持，不过其它的很快也会支持了。

0x5 配置dns-prefetch、preconnect和prerender等资源加载参数

Continue Reading…

WordPress 国内优化

众说周知 WordPress 是全球使用量第一的开源博客系统，本博客就是基于此搭建的。但是 WordPress 在国内有些水土不服，有些地方没有考虑中国的国情（GFW），需要做一些小优化。以下代码直接添加在主题或者子主题的模板函数 (functions.php)文件中即可，此文件可在后台直接编辑（外观->编辑）。

1. 移除 Google CDN 字体。英文博客使用 web-font 还是很不错，各个平台使用同一种字体，极大地提升了用户体验，但是中文博客基本用不上，而且 Google CDN 被墙，还会极大影响页面加载速度，所以还是直接去掉吧。

1
2
3
4
5
6
7
8
9
10
if (!function_exists('remove_wp_open_sans')) {
    function remove_wp_open_sans() {
        wp_deregister_style('open-sans');
        wp_register_style('open-sans', false);
    }
}
// 前台删除Google字体CSS
add_filter('wp_enqueue_scripts', 'remove_wp_open_sans');
// 后台删除Google字体CSS
add_filter('admin_enqueue_scripts', 'remove_wp_open_sans');

2. Gravatar 地址替换。WordPress 默认使用的几个 Gravatar 头像地址都被墙了，建议替换为 V2ex 提供的 CDN 地址（支持 HTTP2）。注意，官方地址路径为 /avatar，V2ex 的 CDN 为 /gravatar。

1
2
3
4
5
6
if (!function_exists('replace_to_v2ex_avatar')) {
    function replace_to_v2ex_avatar($avatarUrl) {
     return preg_replace(["/[0-9]\.gravatar\.com(\/|%2F)avatar/", "/secure.gravatar\.com\/avatar/"], "cdn.v2ex.com/gravatar", $avatarUrl);
    }
}
add_filter('get_avatar', 'replace_to_v2ex_avatar');

3. 使用最新的 jQuery 以及使用 CDN（BootCDN，支持 HTTP2）。需要注意测试，可能有些插件会有兼容问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
if (!function_exists('register_my_jquery')) {
    function register_my_jquery() {
        if (!is_admin()) {
            wp_deregister_script('jquery-core');
            wp_register_script('jquery-core', '//cdn.bootcss.com/jquery/3.1.1/jquery.min.js', true, '3.1.1');
            wp_enqueue_script('jquery-core');
            
            wp_deregister_script('jquery-migrate');
            wp_register_script('jquery-migrate', '//cdn.bootcss.com/jquery-migrate/3.0.0/jquery-migrate.min.js', true, '3.0.0');
            wp_enqueue_script('jquery-migrate');
        }
    }
}
add_action('wp_enqueue_scripts', 'register_my_jquery');

4. 移除自动 dns-prefetch。WordPress 4.6 增加了 dns-prefetch 功能，他会分析页面注入的 js 等脚本然后，加入 DNS 预加载列表。wp-includes/general-template.php：

当然这个功能出发点是好的，但是有些域名解析很慢，预加载可能会拖慢速度，而且我也不需要使用 emoji 和 Google 字体（默认预加载了这两项）。

1
remove_action('wp_head', 'wp_resource_hints', 2);

建议使用插件 instant-articles 来手动设置 DNS 预加载。

目前本博客只进行了这几点国内环境的特色优化，若其它小伙伴还有什么黑科技欢迎评论。当然除了中国特色，也有一些很有效的通用优化策略，敬请期待下篇博文。

参考资料：

最近针对 V2EX 的 Gravatar 头像加载做了一个优化，https://www.v2ex.com/t/141485

http://www.wpbeginner.com/wp-themes/replace-default-wordpress-jquery-script-with-google-library/

https://wordpress.org/support/topic/remove-the-new-dns-prefetch-code/

一个诡异的 Chrome 视频播放（加载）问题

今晚上线了一个新的 web 页面，主要多了一个背景视频功能，大概是这样：http://thenewcode.com/samples/polina.html 。但上线后遇到一个问题，HTTPS 下背景视频很大概率不播放。线下测试的时候遇到过类似的问题，是因为 webserver 没有在 mime.types 文件添加video/mp4    mp4 mp4v mpg4浏览器不能识别的原因，但线上确定不是这个原因。

Chrome 抓包发现是视频文件请求 412 了，单独访问这个视频文件也是 412 偶现不能访问，但 http 下却没有这个问题。查了下 412 是连接建立先决条件失败，第一次遇到这个错误码，直接看状态码定义，看不出个所以然。看起来自己一时半会儿解决不了呀，马上把这个问题抛到公司的群里，一会儿得到了几个大神的回复：很大可能是 If-Match 和 ETag 对不上的问题。仔细看了下 412 的请求 headers 部分确实是这个现象。

可以看到，Chrome 在加载一个视频的时候是分段加载，当某一个请求 412 的时候会造成整个视频加载失败。群里的璐神给了一些参考资料，里面有一段说明：

在大型多 WEB 集群时，使用 ETag 时有问题,所以有人建议使用 WEB 集群时不要使用 ETag，其实很好解决,因为多服务器时, INode不一样，所以不同的服务器生成的 ETag 不一样，所以用户有可能重复下载(这时 ETag 就会不准)，明白了上面的原理和设置后，解决方法也很容易，让 ETag 后面 二个参数，MTime 和 Size 就好了。只要 ETag 的计算没有 INode 参于计算,就会很准了。

觉得这个说得很有道理，决定改一下 Apache 服务器试试。看配置文件的时候发现，http 的配置下有一行 FileETag -INode -MTime Size 的配置，但是 https 下没有，把这一行也加到 https 的配置文件中果然就行了。

虽然问题是解决了，但是感觉还是没有找到根本原因的样子。看了下 Apache 的文档发现 FileETag 默认使用 MTime 和 Size 两个参数，因为集群部署代码时是串行的，且会改变文件的时间（OP 部署系统的锅，中间有一步进行了 cp 操作），所以应该是 MTime 不一样造成了每台服务器上应该是同一个文件的 ETag 不一样，而每个分片请求落在了不同的机器上，造成If-Match和ETag对不上，不是之前猜测的 INode 问题。但感觉还是哪里不对，为什么If-Match和ETag对上了的请求就没问题了，按照理解ETag是用来做缓存的，对不上很正常，web server应该返回完整内容呀。下班回家又仔细想了一下，觉得这个问题应该反过来思考，因为 Chrome 是分段加载视频，需要保证这个视频在加载过程中是没有变动的，这样才有意义，所以需要每次请求都对比 ETag。那么为什么其它浏览器没这个问题了，抓包发现 IE 没有分段下载功能，是当一个文件都加载完成后才播放。FireFox 没有带上 If-Match 的请求头：

Safari 也没有使用 If-Match 的请求头，因此就 Chrome 下有这个问题。If-Match 的说明也验证了我的猜想：

For GET and HEAD methods, used in combination with an Range header, it can guarantee that the new ranges requested comes from the same resource than the previous one. If it doesn’t match, then a 416 (Range Not Satisfiable) response is returned.

当然我这个案例中错误码是 412（通常用作 PUT 方法更新资源出错时），不过这是一个意思，符合预期。

ETag 工作流程和生成算法补充：当客户端第一次向服务器请求资源时，服务器会返回资源并根据资源的一些信息生成 ETag 返回给客户端，客户端不需要了解 ETag 是如何生成的，只需缓存下 ETag 当下次请求时带上（If-None-Match: ETag）。表示如果这个资源的 ETag 和我请求的不一样则返回数据，一样则返回 304。

不同个 webServer 生成 ETag 的算法可能不一样，比如上面提到的 Apache 使用的是 INode MTime Size 三个文件属性计算而得：

1
2
3
4
5
6
$fs = stat($file);
sprintf('Etag: "%x-%x-%s"',
        $fs['ino'],
        $fs['size'],
        base_convert(str_pad($fs['mtime'], 16, '0'), 10, 16)
)

参考资料：

Apache配置Etag详解 http://www.yudouyudou.com/jiaochengheji/wangzhanjianshe/262.html

https://httpd.apache.org/docs/2.4/mod/core.html#fileetag

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn

http://stackoverflow.com/questions/44937/how-do-you-make-an-etag-that-matches-apache

创建 redis systemd 服务

服务器操作系统一直使用的是 ubuntu server，因为安装软件很方便，直接apt-get install就行。但使用 apt 安装 redis 版本比较旧，也没有新的源，所有只能自己编译安装了。不过有个问题，自己编译安装的启动和重启比较麻烦（启动：/usr/bin/redis-server /etc/redis/redis.conf，停止：/usr/bin/redis-cli shutdown）。我在想能不能使用类似 ubuntu service xxx restart 的指令。

搜索了一下发现可以使用upstart来实现这个需求，但是这个在 ubuntu 15.04 已经废弃了，推荐使用更先进的systemd。在 /etc/systemd/system/ 下创建一个 redis.service：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[Unit]
Description=Redis In-Memory Data Store
After=network.target
 
[Service]
User=redis
Group=redis
Type=forking
ExecStart=/usr/bin/redis-server /etc/redis/redis.conf
ExecStop=/usr/bin/redis-cli shutdown
Restart=always
 
[Install]
WantedBy=multi-user.target

其中主要是定义了启动用户，启动命令，停止命令。有个设置比较重要Type=forking，可以理解为 systemd 是一个类似 supervise 的守护进程，forking 表示服务管理器是系统 init 的子进程，用于管理需要后台运行的服务。同时还需要修改 redis 的配置：

1
2
3
daemonize yes
……
supervised systemd

然后就可以使用sudo systemctl start redis命令启动 redis 了。同时支持 stop、restart 等常用指令。启动成功后运行 sudo systemctl status redis查看运行状态：

可以看见 redis 已经正常运行了。可以尝试使用 kill -9 命令把 redis 杀死，你会发现 redis 马上又会被拉起，这样能保证服务能一直运行（当然若是服务有问题一直蹦，谁也救不了你）。若需要开机启动还可以运行sudo systemctl enable redis命令加入到开启启动项里面。

我们平常自己写的程序也可以依样画葫芦写个配置文件，使用 systemctl 来做服务管理，这种方式更加先进，还有一些其它实用的功能。

 

参考资料：

Ubuntu systemd service file for Redis, https://gist.github.com/geschke/ab6afa91b2d9dfcd5c25

systemd – ArchWiki, https://wiki.archlinux.org/index.php/Systemd

How To Install and Configure Redis on Ubuntu 16.04 | DigitalOcean, https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-redis-on-ubuntu-16-04

Ubuntu 16.04 上安装 MySQL 5.7 的一些细节

最近腾讯云折扣力度比较大，在加上之前 DigitalOcean 上的 VPS 访问不是太顺畅，就把服务器迁回了国内。重装了一把 MySQL，遇到了一些细节上的问题，觉得很有意义，记录下。

首先使用 MySQL 官方的源安装，这个在一年前的《Ubuntu 平滑升级 MySQL 到 5.7》中描述过，具体过程不再赘述。说一些细节上的东西：

1. Ubuntu 16.04 要求 2017.01.01 后所有的源必须使用 SHA2 以上版本的摘要签名算法（https://wiki.debian.org/Teams/Apt/Sha1Removal）。目前来说具体表现是在执行sudo apt-get update时会显示一个警告“W: http://repo.mysql.com/apt/ubuntu/dists/xenial/InRelease: Signature by key A4A9406876FCBD3C456770C88C718D3B5072E1F5 uses weak digest algorithm (SHA1)”。访问一下网址确实看见使用的是 SHA1 签名，这个只能等待官方修复。

2. 安装过程中会要求设置 root 密码，这里你可以你直接回车（设置空密码），但实际上是给你创建了一个 auth_socket 的 root 用户，并不是空密码。

这时你登录的话需要使用 socket 方式连入：sudo mysql --protocol=socket --socket=/var/run/mysqld/mysqld.sock，注意这里需要用 root 权限运行，保证有足够权限读取 sock 文件，不然会默认使用当前用户进行传统的 ip+port 登录，这样肯定是登录不上的。登录上去就可以改 root 密码了，正常执行ALTER USER 'root'@'localhost' IDENTIFIED BY 'test';后发现密码并没有被改变（会报 warning），观察上面的截图会发现 root 账号的认证插件用的是auth_socket，我们需要这样执行命令ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'test';。就能回到传统的账号密码认证了。

3. 细心的同学可能已经发现了，多了一个mysql.sys的用户，按照官方的说法这是给 DBA 使用的，防止直接使用 root 账号带来的重命名和误删账号的问题。这个用户默认有一个初始密码，但在日志里面没找到（源码编译 MySQL 5.7 后 mysql_install_db –initialize 时会把密码记录到日志中）。这里索性重新设置一个密码（ALTER USER ‘mysql.sys’@’localhost’ IDENTIFIED BY ‘test’;）。

到这儿基本上已经安装完成了，但若你细心的话会发现在启动日志里面会有一些警告：

1. TIMESTAMP with implicit DEFAULT value is deprecated. Please use –explicit_defaults_for_timestamp server option (see documentation for more details). 这个是说explicit_defaults_for_timestamp缺省值已经废弃了，需要显式的在 my.cnf 设置 explicit_defaults_for_timestamp = 1

2. [Warning] Could not increase number of max_open_files to more than 5000 (request: 65535) 这是个常见的错误，一般修改 /etc/security/limits.conf 即可，但改了之后好像不奏效。这是因为在 /lib/systemd/system/mysql.service 配置中还有参数 LimitNOFILE 限制，把这里也修改了就可以了。

3. 还有日志中时间的时区和系统的不一致，看日志不方便。这是 5.7 新加的参数log_timestamps（http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_log_timestamps），在 my.cnf 设置为 log_timestamps = SYSTEM 即可。

全部搞定后建议执行sudo mysql_secure_installation命令，做一些安全设置，比如禁止root远程登录、删除匿名用户、验证密码安全级别等。

最后介绍一个比较好用的命令：mysql_config_editor，解决命令行登录MySQL便捷性和安全性的问题。我们为了本地登录MySQL方便经常会写一些一键登录的小脚本。基本上都是直接执行 mysql -uroot -p’test’ 命令，这样会带来一个问题，执行的命令会被记录在bash_history中，当然你也可以禁用bash_history的功能，但这样会失去一些便捷性，也不大方便追查历史的问题命令。而且在新版本中直接使用这种方式登录会有警告信息。

这时我们就可以使用 mysql_config_editor 来创建一个 login-path，登录时直接使用mysql --login-path=xxx即可。一个典型的创建指令：mysql_config_editor set –login-path=xxx –host=localhost –user=root –port=3306 –password，然后输入密码。这里需要注意一下，如果粘贴的密码中有特殊字符会有问题，需要加上引号。比如你的密码是 test!@#，需要复制文本 'test!@#' 进行粘贴。创建的文件默认在 ~/.mylogin.cnf，不过这是个二进制文件，看不出来啥（比较安全）。我们可以使用 mysql_config_editor print --all 命令来看看已经创建的 login-path：

这里也能看见密码是加密存储的，在一定程度上保证了安全。而且 .mylogin.cnf 文件可以分发给使用同一个MySQL-client的用户，提高了安全性也方便运维管理。很实用的功能，强烈推荐使用。

MySQL 每个版本都有很多安全性和性能的改进，值得去学习、研究。而且 MySQL 8（现在都流行跳版本）也快出来了，前景更是一片大好。

 

参考资料：

Change user password in MySQL 5.7 with “plugin: auth_socket”, https://www.percona.com/blog/2016/03/16/change-user-password-in-mysql-5-7-with-plugin-auth_socket/

Where is the MySQL 5.7 root password?, https://www.percona.com/blog/2016/05/18/where-is-the-mysql-5-7-root-password/

Do I need to change the mysql.sys password, http://askubuntu.com/questions/824139/do-i-need-to-change-the-mysql-sys-password

Can not increase max_open_files for Mysql max-connections in Ubuntu 15, http://stackoverflow.com/questions/30901041/can-not-increase-max-open-files-for-mysql-max-connections-in-ubuntu-15

使用karma+mocha进行前端测试驱动开发（一）

之前有接触过一些使用 casperJs 做前端自动化测试和页面元素监控，效果还不错，这个后续有时间再介绍一下。但对前端代码层面的测试不是很了解，今天下班比较早，闲来无事，就看了下最近听说的 karma+mocha 前端测试框架，发现还是很有意思，收（刚）获（刚）颇（入）多（门）。目前来看 karma+mocha 非常适合做 TDD（测试驱动开发）。

测试驱动开发（英语：Test-driven development，缩写为 TDD）是一种软件开发过程中的应用方法，由极限编程中倡导，以其倡导先写测试程序，然后编码实现其功能得名。

TDD 提倡写代码之前先把单测写好，然后通过单测来验证代码是否正确。这就需要有一个单测框架（即 mocha），但这还不够，也不能每写完一次就运行一下单测代码，这也效率太低了吧，所以还需要一个框架（即 karma）来做这个事情。

这里先介绍一些 JS 单测框架 mocha（https://github.com/mochajs/mocha，tj 大神的作品，奈何大神觉得 Node 没搞头去搞 go 了）。安装还是比较简单，这里就不多说了。提醒一下，如果是在 Windows 下安装 Node 的话可能需要设置一下环境变量。

实例：一个加法模块src/add.js的代码：

1
2
3
4
5
function add(x, y) {
    return x + y;
}
 
module.exports = add;

各个语言写单测都差不多，就是对预期结果的断言。上面代码对应的测试代码tests/add.test.js：

1
2
3
4
5
6
7
8
var add = require('../src/add.js');
var assert = require('chai').assert;
 
describe('加法函数的测试', function() {
    it('1 加 1 应该等于 2', function() {
        assert.equal(add(1, 1), 2);
    });
});

测试脚本里面应该包括一个或多个describe块，每个describe块应该包括一个或多个it块。

describe块称为“测试套件”（test suite），表示一组相关的测试。它是一个函数，第一个参数是测试套件的名称（“加法函数的测试”），第二个参数是一个实际执行的函数。

it块称为“测试用例”（test case），表示一个单独的测试，是测试的最小单位。它也是一个函数，第一个参数是测试用例的名称（“1 加 1 应该等于 2”），第二个参数是一个实际执行的函数。

断言库有很多种，mocha 并不限制使用哪一种。上面代码引入的断言库是 chai，并且指定使用它的assert断言风格。因为这更接近其它语言的风格。

运行一下测试代码：

filehelper_1472143702070_9

大概流程就是这样，详细的可以查看官方文档。随便说一下，WebStorm 和 PhpStorm 原生支持 mocha，设置一下即可右键运行时直接调用 mocha 来运行当前 JS 单测文件：

20160826005459

20160826005634

20160826005739

单测已经写好了，怎么能让测试驱动我开发呢？这时候就需要 karma（https://github.com/karma-runner/karma）登场了。如 github 主页上所说，Karma 不是一个测试框架，也不是一个断言库，仅仅启动一个 http server，并通过你熟知的测试框架生成运行测试的HTML。Karma 支持的测试框架非常多，如前文介绍，我们这里选择的是 mocha 测试框架和 chai 断言库。

首先安装 karma，然后使用karma init my.conf.js命令生成配置文件。生成文件的过程是交互式的，很友好，注意选择测试框架是 mocha。选错了也没关系，配置文件之后可以手动编辑，大概长这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
// Karma configuration
module.exports = function(config) {
  config.set({
 
    // base path that will be used to resolve all patterns (eg. files, exclude)
    basePath: '',
 
 
    // frameworks to use
    // available frameworks: https://npmjs.org/browse/keyword/karma-adapter
    frameworks: ['mocha', 'requirejs', 'chai'],
 
 
    // list of files / patterns to load in the browser
    files: [
      'test-main.js',
      {pattern: 'src/*.js', included: true},
      {pattern: 'tests/*.test.js', included: false}
    ],
 
 
    // list of files to exclude
    exclude: [
    ],
 
 
    // preprocess matching files before serving them to the browser
    // available preprocessors: https://npmjs.org/browse/keyword/karma-preprocessor
    preprocessors: {
    },
 
 
    // test results reporter to use
    // possible values: 'dots', 'progress'
    // available reporters: https://npmjs.org/browse/keyword/karma-reporter
    reporters: ['progress'],
 
 
    // web server port
    port: 9876,
 
 
    // enable / disable colors in the output (reporters and logs)
    colors: true,
 
 
    // level of logging
    // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
    logLevel: config.LOG_INFO,
 
 
    // enable / disable watching file and executing tests whenever any file changes
    autoWatch: true,
 
 
    // start these browsers
    // available browser launchers: https://npmjs.org/browse/keyword/karma-launcher
    browsers: ['Chrome'],
 
 
    // Continuous Integration mode
    // if true, Karma captures browsers, runs the tests and exits
    singleRun: false,
 
    // Concurrency level
    // how many browser should be started simultaneous
    concurrency: Infinity
  })
}

比较重要的几个参数：

  • frameworks：我们这里需要 mocha 和 chai。框架必须预先通过 npm install karma-xxx --save-dev 命令安装好，支持的框架详见：https://www.npmjs.com/browse/keyword/karma-adapter
  • files：可以配置通配符把源代码和测试代码加载进来。
  • browsers：需要启动的浏览器
  • autoWatch：观察文件是否变动，如有变动则重新运行单测。

最后使用命令karma start my.conf.js运行即可。但这里我一直失败，遇到如下这些错误：

1
2
3
4
5
6
7
8
Chrome 52.0.2743 (Windows 10 0.0.0) ERROR
  Uncaught ReferenceError: module is not defined
  at src/add.js:5
 
Chrome 52.0.2743 (Windows 10 0.0.0) ERROR
  Uncaught Error: Module name "../src/add.js" has not been loaded yet for context: _. Use require([])
  http://requirejs.org/docs/errors.html#notloaded
  at node_modules/requirejs/require.js:143

这是因为上文的代码使用的是node的require()语法，karma是在浏览器端运行的，当然不支持了。如果你的源代码使用的是 AMD、CMD 加载器，测试代码也要使用 requirejs 等框架加载源代码模块。这里我们将源代码和测试代码稍微改造一下就行了：

1
2
3
4
5
function add(x, y) {
    return x + y;
}
 
// module.exports = add;

1
2
3
4
5
6
7
8
9
10
// var add = require('../src/add.js');
// var assert = require('chai').assert;
 
var assert = chai.assert;
 
describe('加法函数的测试', function() {
    it('1 加 1 应该等于 2', function() {
        assert.equal(add(1, 1), 2);
    });
});

成功运行：

20160826014133

karma 可以启动不同的浏览器，所以还可以做兼容性测试。

我修改一下源代码，karma 能自动监听到文件变动，然后显示单测结果，这样我就能实时知道代码是否有问题。

karma

当然这只是 karma 的一个功能，还有很多实用功能等待后续学习。

参考资料：

测试框架 Mocha 实例教程，http://www.ruanyifeng.com/blog/2015/12/a-mocha-tutorial-of-examples.html

[JavaScript] Test Suit 4 – Test Runner – Karma，http://veck.logdown.com/posts/248538-javascript-test-suit-4-test-runner-karma

典型的用户注册页面短信验证逻辑漏洞

用户注册是一个网站基本的功能，做过 web 开发的基本上都写过这个功能，但很多漏洞都出在这个页面上面。这里先不讨论密码加密存储，传输安全等问题，就说说注册页面的功能逻辑。

2016-05-22_000624

如上图的新浪微博注册页面，一般的注册页面都需要填写账号、密码等信息，为了防止恶意注册，都还有一个验证码，这几乎是一个注册页面的标配了。现在有些注册页面会多一个手机验证，防止恶意注册的同时也变相完成了实名制的红头文件要求，但有时候问题就出在这里。

2016-05-18_020524

上图这个注册页面，中规中矩，看似没什么问题，填写一些信息后点击下一步：

2016-05-18_020915

很常见的操作，POST 请求将信息带到下一个页面（校验了图形验证码），跳过来的同时已经给手机发了短信验证码，到目前为止没什么问题，用户体验还不错。不过发现页面上还有一个重新发送的按钮，点击一下发现直接调用 /sendRegMsg 接口发送了短信，接口只接收一个手机号参数，无其它参数。这里就是第一个漏洞：短信发送接口无权限验证，可被恶意调用造成经济损失，还可被利用于“短信炸弹”，而且这家厂商本身就是提供短信验证码服务的，估计“短信炸弹”效果更改。要解决这个漏洞也很简单，加个验证码就行了，但这里可能又会有一个坑（后面细说）。实际短信验证码为 4 位，提交企业名称等信息时也没有图形验证码校验：

2016-05-18_021422

那就好办了，直接跑个小脚本暴力提交（最多9999次）即可：

2016-05-18_024823

这里就是第二个漏洞了，任意手机号注册（一大波薅羊毛党将要来袭）：

2016-05-18_024610

这两个漏洞都是很好修复的，影响也不大，但若安全意识薄弱，逻辑没有理清楚会造成修复不彻底。比如在短信重新发送操作那里加了一个图形验证码，发送短信和提交时都会做校验，但若你调用一次短信发送接口后图形验证码没有重置，我就可以拿着这一个正确的图形验证码一直调用发送短信接口（重放攻击）也能达到恶意调用和“短信炸弹”的目的，提交信息时也可以用这一个的正确图形验证码暴力提交。还有的为了限制短信发送频率，点击发送短信后将发送按钮设置为 disabled="disabled"，然后设置一个定时器 60s 后恢复，这完全也是自己骗自己。

一种比较好的做法是每发一次短信图形验证码都重置，短信验证码填写失败一定次数后重置校验 session，后面任何输入都返回错误。

其实这个漏洞很鸡肋也很低级，但目前这种逻辑漏洞已经成为主要的问题，看似低级，但很难避免，往往影响还很大。而且我们可以看到图形验证码在整个流程中扮演了很重要的角色，但你的图形验证码真的安全吗？答案是否定的，百度贴吧和 12306 “变态”的验证码都是几天内就被破解了，甚至还有人工打码平台，可谓是道高一尺魔高一丈。安全，还是仍重道远呀。

推荐阅读：

黑产揭秘：“打码平台”那点事儿 http://www.freebuf.com/articles/others-articles/104536.html

参考资料：

无（不要问为什么知道这类漏洞）

kanqiu_26461760_2144148040__20160126154003