使用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的代码：

function add(x, y) {

return x + y;

}

module.exports = add;

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

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断言风格。因为这更接近其它语言的风格。

运行一下测试代码：

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

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

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

// 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运行即可。但这里我一直失败，遇到如下这些错误：

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 等框架加载源代码模块。这里我们将源代码和测试代码稍微改造一下就行了：

function add(x, y) {

return x + y;

}

// module.exports = add;

// 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);

});

成功运行：

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

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

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

参考资料：

测试框架 Mocha 实例教程，https://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

2016年5月22日

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

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

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

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

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

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

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

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

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

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

配置Nginx，开启HTTP/2

HTTP/2（超文本传输协议第2版，最初命名为 HTTP 2.0），是在 Google 之前提出的 SPDY 协议的基础上演变而来，相对 HTTP1.1 增加了连接复用、头部压缩、服务端 push 等特性。与 HTTP1.1 完全语义兼容，几乎可以无缝升级。目前主流浏览器都已经支持 HTTP/2 了（IE 自 IE 11 开始支持）。

开源版本的 Nginx 从 1.9.5 版开始支持 HTTP/2，其实配置也很简单，升级 Nginx 到最新版本，然后把之前 HTTPS 配置中的 spdy 改成 http2 就行了（listen 443 ssl http2 default_server），但改了之后发现并没有生效，直接退回到了 HTTP1.1。nginx -V 查看编译参数也带有 --with-http_v2_module，应该没什么问题才对。Google 了一把发现是 OpenSSL 版本的问题，我使用的是 ubuntu 14.04 下的 ppa:nginx/stable 源，这个源上的 Nginx 是在 OpenSSL 1.0.1f 上编译而成的，而 OpenSSL 的这个版本不支持 ALPN，所以无法开启 HTTP/2。

Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2. Using the “Next Protocol Negotiation” (NPN) TLS extension for this purpose (available since OpenSSL version 1.0.1) is not guaranteed.

知道原因就好办了，先升级本地的 OpenSSL到最新版：

1 2	$ openssl version OpenSSL 1.0.2h 3 May 2016

然后替换 Nginx 源为 ppa:ondrej/nginx 重新安装 Nginx：

$ sudo add-apt-repository --remove ppa:nginx/stable

$ sudo add-apt-repository ppa:ondrej/nginx

$ sudo apt-get update

$ sudo apt-get install -f nginx nginx-common nginx-full

$ nginx -V

nginx version: nginx/1.10.0

built with OpenSSL 1.0.2g 1 Mar 2016 (running with OpenSSL 1.0.2h 3 May 2016)

TLS SNI support enabled

现在再打开网站，发现 HTTP/2 已经开启成功了。

当然如果你是 ubuntu 16.04，就没有那么麻烦了，直接安装 Nginx 配置一下就行：https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-with-http-2-support-on-ubuntu-16-04

一个css选择器的小坑

之前博客主题中的有序列表显示有点问题，列表标记位置会在正文左边突出一部分，所以设置了 padding 值来解决此问题：

.article-content ol {

padding-left: 20px;

}

但有发现无序列表也有这个问题：

所以想当然的在之前的位置后面把 ul 标签加上：

.article-content ol, ul {

padding-left: 20px;

}

然后就悲剧了，页面上其它位置的 ul 也 padding-left: 20px 了：

好久没写 css 了，百思不得其解，试过 .article-content > ol, ul、.article-content section > ol, ul 都不行，甚至怀疑同级标签也有继承的关系。后来发现其它地方会把 class 标签写两次才恍然大悟，应该是逗号「,」优先级更高一点，把选择器解析成了 .article-content ol 和 ul 两部分，所以选择器写成 .article-content ol, .article-content ul 就可以了。

不用就会忘，随便改点东西就踩坑了。Orz!

2016年5月10日

PHP单元测试-mock和数据库测试

在计算机编程中，单元测试（英语：Unit Testing）又称为模块测试, 是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

本文主要是根据PHPUnit（The PHP Testing Framework）文档结合实例简单介绍一下 PHP 单元测试中 mock 和数据库测试。如果你是初次接触单测的话建议先看一下 PHPUnit 文档中的入门章节。

通常来说是开发程序和单测是同步进行的，项目提测的时候核心模块都需要包括单测（报告），但这个要求在不同的公司、部门、项目组要求不一样。虽然单测会占用一定的开发时间但总的来说单测是利远大于弊，最大的好处是自己或者别人后续更新模块功能时不用担心对原有功能造成了影响而不知情。

下面是一个具体的例子，在 web 开发中这样一个场景可能很常见：PHP 提供一个帐号注册的接口供前端调用，接口先检验一下此用户名是否已经存在，不存在的话插入数据库，返回注册成功。接口代码是这样的：

<?php

require_once "lib/Join.php";

require_once "lib/Db.php";

use web\lib\Db;

use web\lib\Join;

$username = $_POST['username'];

$password = $_POST['password'];

$db = new Db('user');

$join = new Join($db->connect());

echo json_encode($join->signIn($username, $password));

主要调用了 Join 类的 signIn 方法。我们来看看 Join 类是啥样：

<?php

namespace web\lib;

require_once "Db.php";

class Join

{

private $db;

function __construct(Db $db)

{

$this->db = $db;

}

public function signIn($userName, $password)

{

if ($this->db->exists('user', ['username' => $userName])) {

return [

'code' => 1,

'msg' => "user has exists",

];

}

else {

$this->db->insert('user', [

'username' => $userName,

'password' => $password,

]);

return [

'code' => 0,

'msg' => "success",

];

}

逻辑很简单，先调用 Db 类的 exists 方法判断用户名是否存在，不存在的话使用 insert 方法插入数据。Join 类是这次业务新加的，比较重要，需要单测来保障质量，但这里用到了个 Db 类，这个库是以前就有的（坑），可能会影响本模块单测的正确性，而且 Db 类需要连接数据库，比较麻烦，这种场景就需要 mock 了。本文说的 mock 是广义上的，包括 Stubs（桩件）和仿件对象(Mock Object)。

将对象替换为（可选地）返回配置好的返回值的测试替身的实践方法称为上桩(stubbing)。可以用桩件(stub)来“替换掉被测系统所依赖的实际组件，这样测试就有了对被测系统的间接输入的控制点。这使得测试能强制安排被测系统的执行路径，否则被测系统可能无法执行”。

将对象替换为能验证预期行为（例如断言某个方法必会被调用）的测试替身的实践方法称为模仿(mocking)。

我们这里应用的是打桩的概念。signIn 方法有两个分支：用户名存在和不存在。所以我们需要让 Db 类的 exists 方法在输入某个（些）用户名的时候返回 true。主要使用 PHPUnit_Framework_TestCase 类提供的 getMockBuilder() 方法来建立一个桩件对象：

// 为Db类创建桩件

$db = $this->getMockBuilder('web\lib\Db')

->getMock();

代码看上去很像是实例化了一个类，其实原理也和这个差不多，PHPUnit 通过反射机制获取到类及其方法的信息，然后使用内置模板生成一个新类。我们需要 mock 掉 insert 和 exists 方法：

$db = $this->getMockBuilder('web\lib\Db')

->disableOriginalConstructor()

->setMethods(['insert', 'exists'])

->getMock();

这里使用了桩件生成器的 setMethods() 方法来设置哪些方法被上桩，以下是生成器提供的方法列表：

setMethods(array $methods) 可以在仿件生成器对象上调用，来指定哪些方法将被替换为可配置的测试替身。其他方法的行为不会有所改变。如果调用 setMethods(null)，那么没有方法会被替换。
setConstructorArgs(array $args) 可用于向原版类的构造函数（默认情况下不会被替换为伪实现）提供参数数组。
setMockClassName($name) 可用于指定生成的测试替身类的类名。
disableOriginalConstructor() 参数可用于禁用对原版类的构造方法的调用。
disableOriginalClone() 可用于禁用对原版类的克隆方法的调用。
disableAutoload()可用于在测试替身类的生成期间禁用 __autoload()。

然后分别设置两个方法的参数和返回值。这里 insert 操作比较简单，可以用 willReturn($value) 返回简单值：

1 2	$db->method('insert') ->willReturn(true);

上面的例子中，使用了 willReturn($value) 返回简单值。这个简短的语法相当于 will($this->returnValue($value))。而在这个长点的语法中，可以使用变量，从而实现更复杂的上桩行为。我们这里的需求是需要根据预定义的参数清单来返回不同的值，显然这是一个映射（map），PHPUnit 提供现成的 returnValueMap() 方法来做这个事情：

// mock method multiple calls with different arguments

$map = [

['user', ['username' => 'yaozhen'], true],

[$this->anything(), $this->anything(), false],

];

$db->method('exists')

->will($this->returnValueMap($map));

完整的单测代码： Continue Reading...

2016年3月31日

【译】简单介绍通过Predis库在PHP中使用Redis

本文翻译自《An Introduction to Redis in PHP using Predis》，已得到作者 @Daniel Gafitescu 的允许。原文版权归作者和 sitepoint.com 所有，如果你有原文使用需求请自行联系作者。

Redis 是一个开源的内存数据库服务器，得益于内建的数据类型，Redis 不仅仅只能做简单的 key/value 存储。

Redis 由 @Salvatore Sanfilippo 在 2009 年发布，因为其受欢迎和增长迅速，被很多大公司比如 VMware（后来聘请作者去全职工作）、GitHub、Craigslist、Disqus、Digg、Blizzard、Instagram 等（详见：https://redis.io/）使用。

你可以使用 Redis 做会话（session）处理程序，当你使用负载均衡的分布式服务时特别有用。Redis 也可以用作发布/订阅系统，很优雅的创建一个在线聊天或者实时订购程序。关于 Redis 的文档，所有的命令以及其它信息都能在项目网站 redis.io 上找到。

一直以来都有 Redis 和 Memcache 哪个更好的争论，文章 as the benchmarks show 显示在相同的基础操作上两者不相上下。Redis 比 Memcache 有更多的特性，比如内存存储、磁盘持久化、原子操作、事务以及不用记录每一次变化到磁盘上而是用服务端的数据结构来代替。

在这篇文章中将介绍如何使用 Predis 库所提供的一部分基础但很有用的 Redis 命令。

容易安装

Redis 容易安装，简明的安装说明发表在产品的下载页。从我个人经验来看，如果你运行在 Ubuntu 上而又没有安装 TCL（只需运行 sudo apt-get install tcl 即可安装）将会报错。一旦 Redis 安装完成，你可以运行服务：

1 2	gafitescu@ubun2:~$ /usr/local/bin/redis-server * The server is now ready to accept connections on port 6379

在 Redis 的网站上显示的有很多语言可用的 Redis 客户端，每种语言都有好几个。对于 PHP 来说有 5 个。在本文中我使用的是 Predis 库，但是你可能也需要作为 PHP 模块编译、安装的 phpredis 扩展。

译者注：有些人可能在 Predis 库和 phpredis 扩展中难于选择，但两者在一般场景下相差不大，目前都支持 PHP7。phpredis 扩展在性能上可能有一些优势，而 Predis 库源码更加优雅（适合学习、阅读），支持 PHP 新的语法特征，但文档较少（这也是我翻译这篇文章的主要原因）。还有，Predis 也有扩展支持（但作者好像没精力维护了，目前还不支持 PHP7），用于提高性能和提供一下其它的特性。

如果你向我一样在机器上安装的有 Git，你只需克隆 Predis 仓库。否则你就要下载 ZIP 包然后解压。（译者注：可以使用更加简便的 composer 安装：composer require predis/predis）

1	gafitescu@ubun2:~$ git clone git://github.com/nrk/predis.git

测试一下，创建一个如下内容的 test.php 文件，测试是否能通过 Predis 连接上运行着的 Redis。

<?php

require "predis/autoload.php";

PredisAutoloader::register();

// since we connect to default setting localhost

// and 6379 port there is no need for extra

// configuration. If not then you can specify the

// scheme, host and port to connect as an array

// to the constructor.

try {

$redis = new PredisClient();

$redis = new PredisClient(array(

"scheme" => "tcp",

"host" => "127.0.0.1",

"port" => 6379));

echo "Successfully connected to Redis";

}

catch (Exception $e) {

echo "Couldn't connected to Redis";

echo $e->getMessage();

}

当你运行这个脚本，你应该能如愿的看见（输出）信息："Successfully connected to Redis"。

译者注：这里可能有点小问题，代码不会按照预期捕获 Redis 连接失败的异常，因为在初始化 Redis 客户端类的时候并没有真正的连接，而是在运行第一个命令时才做连接，所以需要额外运行一下 $redis->connect(); 来触发连接操作。详见：https://github.com/predis/predis/issues/61

使用 Redis

在这个章节你将了解众多 Redis 提供的命令的概况。Memcache 也有相似的命令，如果你熟悉 Memcache，这些列表对你来说看起来都不会陌生。 Continue Reading...

2016年3月16日

Nginx+PHP-FPM 500 504错误简析

最近新配置的 Nginx + PHP-FPM 环境遇到了几次 Nginx 500（Internal Server Error）和 504（gateway timeout）错误。就索性把配置修改的过程记录下来，已备后查。

先说一下 500 错误，这个一般是 PHP 代码错了，看一下 PHP 的 error 日志就清楚了。但有时候是 Nginx 和 PHP-FPM 配置不当导致的，比如说上传文件的场景。我们都知道 php.ini 文件里面 post_max_size 和 upload_max_filesize 两个配置项决定了文件上传的大小。但上调配置后发现大文件上传还是会 500，原来是因为 Nginx 也会限制上传文件的大小，有 client_max_body_size 配置项决定。这里还有一个比较重要的参数：client_body_buffer_size。为了节省资源 Nginx 不会把 request body 里面的数据一口气读到内存中，而是分片处理，这个参数就是设置缓存区的大小（一般也不用改），大于缓冲区大小的数据会以一个个小文件（buffer_size）形式存储到 client_body_temp_path，为了避免高并发下缓存文件冲突和一些文件系统限制（比如 ext3 磁盘格式文件夹下一级文件个数限制为 3.2w 个）以及提高性能可根据业务需要设置多级子目录。还需特别注意的是路径要有被 Nginx 进程写的权限，不然又会 500 错误了。

然后是 504 错误，除了业务代码本身超时更多是配置问题。还是先说 PHP 的配置，很多人都知道 PHP 脚本有执行时间限制（php.ini 中的 max_execution_time），但在 PHP-FPM 却是 php-fpm.conf 中的 request_terminate_timeout 配置项控制的。还有就是 max_input_time 配置项，值比较小的话在接收大文件或大数据量 POST 请求的时候可能会超时，一般不用做改动，因为大部分场景都是上游 web server 接收好数据后传给 PHP-FPM 进程的，传输的非常快，几乎不会超时，但也不能一概而论，要看具体业务场景。然后就是 Nginx 的锅了，刚也说到是 Nginx 接收好（或者说是转发）数据后传给下游，在这个承上启下的环节很容易超时。几个比较重要的配置项：fastcgi_send_timeout 控制向下游（这里是 PHP-FPM）发送数据的超时时间，与之对应的一个配置项是 fastcgi_read_timeout，表示读取下游 response 的超时时间，这里需要注意的是要和前面说的 request_terminate_timeout 保持一致（或大于）。还有一个配置项 fastcgi_connect_timeout，表示和下游 FastCGI 建立连接的超时时间，不过这个值就不用设置的太长了，不然下游某个节点挂了就会夯住 Nginx 的处理线程，影响业务。

我所遇到的场景就是上面这些，可能还有其它一些情况，具体问题具体分析应该也很好解决。

参考资料：

https://nginx.org/en/docs/http/ngx_http_core_module.html

https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html

《PHP-CGI 进程 CPU 100% 与 file_get_contents 函数的关系》 http://zyan.cc/tags/request_terminate_timeout/1/

《PHP超时处理全面总结》 https://segmentfault.com/a/1190000000313184

《PHP file upload affected or not by max_input_time?》 https://stackoverflow.com/questions/11387113/php-file-upload-affected-or-not-by-max-input-time

2016年1月24日

一个 MySQL 用户名长度的坑

今天使用 PHP 连接一个 MySQL 数据库的时候连不上，提示无权限。

因为 MySQL 是在另外一个机房，首先想到的是防火墙的原因，但使用 MySQL-cli 却能正常连接，遂排除这种可能。

又怀疑是 PHP 框架的问题，写了一个简单的测试脚本，主要语句：mysqli_connect()，并打印出错误。运行一下还是不行，错误如下：

1	Access denied for user 'xxx_us@10.xxx.xxx.xxx' (using password:YES)

真是奇了怪了，这个用户创建时指定的是通配符 '%'，而且在别的机器都可以连接。又把测试脚本放在以前一直运行的环境（PHP 7）中，能运行通过。

看来是是环境问题（PHP 5.4）了，回过头来看那句报错，发现用户名好像被截断了（应该是xxx_user），是不是显示的问题，随便改一个用户名试试，同样报错，用户名却没有截断。这时又想了想是不是 MySQL 的版本太高（5.7.10）了。找了个 MySQL 5.5 的环境，创建相同的用户却发现报错了：String 'xxx_user' is too long for user name (should be no longer than 16)。查询 MySQL 文档发现：MySQL user names can be up to 32 characters long (16 characters before MySQL 5.7.8). https://dev.mysql.com/doc/refman/5.7/en/user-names.html

这样看来应该是老版 PHP 的 mysqli 扩展内部限定了用户名的长度，但新版的 MySQL 却可以创建更长的用户名了。知道原因了就很好办了，创建一个短用户名 OK 了。其实也是阴差阳错，因为新库是多应用共有，所以用户名创建的比较长。_(┐「ε:)_

2015年12月29日

Nginx HTTPS 配置实践

前言

博客使用 HTTPS 已经有一段时间了，最近把当时的配置过程梳理了一遍，希望能对有需要的同学有所帮助。

概念介绍

最近 HTTPS 是越来越流行了，前一阵子的百度，最近的淘宝、知乎，都已经开启了全站 HTTPS 的时代。HTTPS 即 Hypertext Transfer Protocol Secure，简单理解就是在 HTTP 协议上加了一层加密。具体的细节以后弄透彻了再写写。

无利不起早，那么 HTTPS 的好处是什么呢？我个人觉得有以下几点：

数据传输加密，防止信息被窃取。使用 HTTP 协议时，用户的密码、银行账户、隐私信息等都是在网络上明文传输，很容易被中间人截取。
防欺诈。当你使用 EV 级别证书（https://www.wosign.com/EVSSL/index.htm）时，浏览器网址显示和一般 SSL 证书不一样。可以对比下：https://www.paypal.com/signin/ 和 https://www.baidu.com/。使用此类证书的网址，主流的浏览器都会在地址栏显示企业的名称（支持中文），增加了网站信任度，进一步防止用户被钓鱼网站欺骗，当然证书的价格也更贵一些。
防止劫持。这点可以说是国内各大公司下决心支持 HTTPS 的主要原因了。一旦被劫持，用户访问速度会变慢，看到的内容会被篡改，比如商家在百度投放的广告被替换成竞品的广告，淘宝的商品被带上小尾巴（返利链接），甚至直接跳转到x东。这些不光是损害用户的利益，更是直接影响公司收入。
使用新的技术。比如 SPDY/HTTP2（头部压缩、连接复用、Server Push等）的基础都是 HTTPS，新协议对移动端 APP 性能提升帮助很大：《双11手淘前端技术： H5性能最佳实践》

当然 HTTPS 不是银弹，不是用了就保险了，安全是一个整体，这是典型的水桶场景，往往一个系统被攻破是在其薄弱的环节。

证书申请

证书申请的大概流程是，首先在自己的服务器使用 openssl 命令（尽量使用高版本的 OpenSSL，除了能规避漏洞，还能使用更高级的密钥加密/交换算法，提升安全性和性能）生成 csr 和 key 文件，命令如下：

1	openssl req -new -newkey rsa:2048 -sha256 -nodes -out example.com.csr -keyout example.com.key.pem -subj "/C=CN/ST=Beijing/L=Beijing/O=Example Inc./OU=Web Security/CN=example.com"

如命令参数所示，私钥 key RSA 的加密强度是 2048 位（rsa:2048）。CSR 文件使用了更安全的 sha256（SHA-2）摘要算法（SHA-1算法在2016年将不被证书厂商和现代浏览器支持）。

-subj 参数指定证书申请者的信息，如果不直接使用此参数，也会有交互式的命令提示填写这些参数。此部分具体参数释义：

Country Name (2 letter code): 输入国家地区代码，例如中国的 CN

State or Province Name (full name): 地区省份

Locality Name (eg, city): 城市名称

Organization Name (eg, company): 公司名称

Organizational Unit Name (eg, section): 部门名称

Common Name (e.g. server FQDN or YOUR name): 申请证书域名，如果是泛域名证书，则应该填写 *.example.com

Email Address: 电子邮箱

命令还会提示输入challenge password，这个不是加密证书，而是相当于一个二次认证密码，如果厂商证书支持challenge password，而且你也设置了的话，后续证书操作需要验证这个密码，提高安全性。

生成的 CSR（Certificate Signing Request，即证书签名请求，不是证书）文件包含了证书的主要信息和公钥，同时生成了私钥 key 文件（注意保存）。然后把 CSR 文件提交给 CA 厂商（不用提交 key 文件），一般提交的时候会让你选择服务器类型，本文指选的 Nginx。中间还会有一个域名所有者验证过程，一般几分钟后（根据证书类型不同，时间不一样）就会发一份邮件给你。

邮件附件一般会带有厂商用 CA 私钥签好的证书文件 example.com.cert.pem（包含域名、CA 信息，key 对应的公钥，CA 的签名）。同时会给你 CA 的证书链 example.com.cert.ca.pem，如果 CA 证书是多个文件（通常包括 1-2 个中间证书和 1 个根证书），那么需要按照证书信任链由下游到上游，把文件合并成 example.com.cert.ca.pem（cat COMODOECCDomainValidationSecureServerCA.crt COMODOECCAddTrustCA.crt ~~AddTrustExternalCARoot.crt~~ > example.com.cert.ca.pem）。不用把根证书放进 CA 证书链文件里面，因为浏览器和操作系统都内置了根证书，也只认自己内置的根证书。

不过现在更流行的是使用 acme.sh 自动申请和续签 Let’s Encrypt 证书，即免费又好用。acme.sh 提供的方式有很多种，大家按需配置即可，我是 DNSPod + Nginx，仅供参考：

# 申请证书

acme.sh --issue -d example.com -d www.example.com -d api.example.com --dns dns_dp --keylength ec-256

# 安装证书位置

acme.sh --install-cert --ecc -d example.com \

--key-file /path/ssl/example.com.key.pem \

--ca-file /path/ssl/example.com.cert.ca.pem \

--fullchain-file /path/ssl/example.com.cert.full.pem \

--reloadcmd "sudo systemctl force-reload nginx"

证书处理

后面的步骤各个 HTTP Server 就有点不一样了：

# Nginx，自己的证书和CA证书组成下游到根的完整证书链，key单独配置

cat example.com.cert.pem example.com.cert.ca.pem > example.com.cert.full.pem

# Lighttpd，key和自己证书合并为一个新的证书，ca证书单独配置

cat example.com.key.pem example.com.cert.pem > example.com.key.cert.pem

# 附 Lighttpd 的配置：

$SERVER["socket"] == "xxx.example.com:443" {

ssl.engine = "enable"

ssl.pemfile = "/path/ssl/example.com.key.cert.pem"

ssl.ca-file = "/path/ssl/example.com.cert.ca.pem"

server.name = "xxx.example.com"

……

}

tomcat 则比较特别，证书编码格式需要的不是 pem 而是 JKS，得转换一下。

# 先转换为pfx格式

openssl pkcs12 –export –out example.com.cert.pfx –in example.com.cert.full.pem –inkey example.com.key.pem

# 回车后输入pfx证书的密码两次

# 使用java jdk将pfx格式证书转换为jks格式证书

keytool -importkeystore -srckeystore example.com.cert.pfx –destkeystore example.com.cert.jks -srcstoretype PKCS12 -deststoretype JKS

# 回车后输入一次pfx证书密码，然后输入两次要设置的jks证书密码

到这里为止出现了好几个文件，可能有点迷糊，这里总结一下

文件名	释义
example.com.csr	Certificate Signing Request，证书签名请求，不是证书
example.com.key.pem	证书私钥（key），不能泄露（即使是对 CA 厂商），和CSR文件成对存在
example.com.cert.pem	自己的域名证书（pem格式），包含 key 对应的公钥
example.com.cert.ca.pem	CA厂商证书链（pem格式）
example.com.cert.full.pem	合并了自己证书和CA证书的完整证书链（pem格式）
example.com.key.cert.pem	合并了key和域名证书的文件（pem格式）
example.com.cert.pfx	pfx/p12格式的完整证书链（包含了key）
example.com.cert.jks	jks格式（JAVA）的完整证书链（包含了key）

对于这几种文件的区别，可以参考：https://www.cnblogs.com/yjmyzz/p/openssl-tutorial.html、https://blog.freessl.cn/ssl-cert-format-introduce/。实际不用那么麻烦，一般证书厂商会提供不同 webserver 的配置文件，如果没有则需要动手一下，或者使用证书厂商提供的转换工具。

TLS握手简述

借由这几个证书文件，简单介绍一下 TLS 的握手过程（RSA 密钥交换方式）：

客户端	服务端
ClientHello 明文发送握手请求（上报支持的能力）生成一个随机数r1
	ServerHello 明文返回域名证书（example.com.cert.full.pem）还会返回一个随机数r2 这里服务端也可以要求客户端提供证书进行校验（流程会有所不同，省略）
对证书进行验证，前面有介绍，证书中包含 CA 信息和签名信息，逐级向上验证即可 ClientKeyExchange 验证通过后从域名证书中拿出公钥，然后使用公钥加密PreMasterSecret（随机生成），发送给服务端（密文）
	服务端使用私钥（example.com.key.pem）解密得出PreMasterSecret
客户端使用r1、r2、PreMasterSecret生成session key（会话密钥）	服务端也用同样的方式生成session key，生成算法相同（PRF）
使用session key进行对称加密

可以看出核心就是 PreMasterSecret 是密文，其它都是明文。如果中间人想要截取就只能替换证书中的公钥（用自己私钥解密），因为证书本身也有完整性签名，就只能替换整个证书，但证书又是一级级到 Root CA 校验，所以 TLS 握手的结果是安全的。

证书逐级验证的过程（来源：https://security.stackexchange.com/questions/56389/ssl-certificate-framework-101-how-does-the-browser-actually-verify-the-validity）

才疏学浅，介绍的非常简陋，建议阅读 https://halfrost.com/https_tls1-2_handshake/ 及系列文章

配置详解

下面正式开始 Nginx 的配置详解。 Continue Reading...

2015年10月30日

Ubuntu 平滑升级 MySQL 到 5.7

最近 MySQL 发布了 5.7 正式版（https://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html）。5.7 可以说是里程碑式的版本，提高了性能，并增加了很多新的特性。不管怎么样，先升级再说。

首先我的 Ubuntu 版本是 14.04，已经通过 ppa 的方式安装了 MySQL 5.6，所以首先得去掉这个源。

sudo apt-add-repository --remove ppa:ondrej/mysql-5.6

# 如果没有 apt-add-repository 先安装上

# sudo apt-get install software-properties-common

手工删除的话可以去 /etc/apt/sources.list.d 目录下干掉类似 xxx_mysql-5.6_xxx.list 的文件即可。

然后再安装上官方 apt 源，先在 https://dev.mysql.com/downloads/repo/apt/ 下载最新的 deb 文件，然后使用 dpkg 命令添加源，最后执行安装 MySQL 命令即可：

wget http://dev.mysql.com/get/mysql-apt-config_0.5.3-1_all.deb

sudo dpkg -i mysql-apt-config_0.5.3-1_all.deb

sudo apt-get update

sudo apt-get install mysql-server

需要注意的是在添加源那一步的时候，会叫你选择安装 MySQL 哪个应用，这里选择 Server 即可，再选择 MySQL 5.7 后又会回到选择应用的那个界面，此时选择 Apply 即可。

安装完之后还需执行一下 sudo mysql_upgrade -u root -p 更新数据（重要）。

一般这样就完事了，数据什么的都完整无缺。

1 2	$ mysql -V mysql Ver 14.14 Distrib 5.7.9, for Linux (i686) using EditLine wrapper

但一般就是会出现一点小插曲。我在 MySQL 自动启动的时候起不来了：

也没看见日志在哪儿，在 /etc/mysql 目录下找日志的时候发现多了个 my.cnf.dpkg-dist 文件，对比一下发现和原来的 my.cnf 不太一样呀，把原来的 my.cnf 备份后使用这个文件替换掉。再次启动 MySQL 果然 OK 了。

这篇文章写得还是没啥营养，权当做个记录吧。等以后水平高了，再来填 MySQL 5.7 新特征及其优化的坑。

update:

关于配置优化，介绍一个好网站：https://www.percona.com/software/mysql-tools

我 1 CPU，1 GB RAM 的配置如下： Continue Reading...

本 Blog 不支持评论，如有疑问或建议请联系我，以完善内容，期望帮助到更多的同学

我的编程人生

yaozhen's blog

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

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

配置Nginx，开启HTTP/2

一个css选择器的小坑

PHP单元测试-mock和数据库测试

【译】简单介绍通过Predis库在PHP中使用Redis

容易安装

使用 Redis

Nginx+PHP-FPM 500 504错误简析

一个 MySQL 用户名长度的坑

Nginx HTTPS 配置实践

前言

概念介绍

证书申请

证书处理

TLS握手简述

配置详解

Ubuntu 平滑升级 MySQL 到 5.7