发表于   |   分类于

引言

用了这么久了PHP+Nginx了，你了解他们之间的通信原理吗？这一次做一回真正的PHPer（在上一篇文章里边已经全面介绍了CGI、FastCGI、PHP-FPM，所以本文对于这些概念不再介绍的那么详细）

PHP-FPM

PHP-FPM的全称是PHP FastCGI Process Manager，PHP-FPM是FastCGI的实现，并提供了进程管理的功能。FastCGI进程包含master进程和worker进程两种进程。master进程只有一个，负责监听端口，接收Nginx的请求，而worker进程则一般有多个(可配置)，每个进程内部都嵌入了一个PHP解释器，是PHP代码真正执行的地方。

Nginx

Nginx (“engine x”) 是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。这里介绍一下什么是正向代理和反向代理，这个对于我们理解Nginx很重要

正向代理

我们那访问国外的网站为例，比如访问Google、Facebook。我们需要借助vpn才能访问，我们借助vpn访问国外的网站，其实就是个正向代理的过程，上图：

vpn对于用户来说，是可以感知到的（因为用户需要配置连接），vpn对于google服务器来说，是不可感知的(google服务器只知道有http请求过来)。所以，对于用户来说可以感知到，而对于服务器来说感知不到的服务器，就是正向代理服务器（vpn）

反向代理

拿Nginx作为反向代理服务器实现负载均衡来举例，假设此时我们访问百度，看图：

当用户访问百度时，所有的请求会到达一个反向代理服务器，这个反向代理服务器会将请求分发给后边的某一台服务器去处理。此时，这个代理服务器其实对用户来说是不可感知的，用户感知到的是百度的服务器给自己返回了结果，并不知道代理服务器的存在。也就是说，对于用户来说不可感知，对于服务器来说是可以感知的，就叫反向代理服务器（Nginx）

PHP-FPM+Nginx通信

FastCGI致力于减少Web服务器与CGI程序之间互动的开销，从而使服务器可以同时处理更多的Web请求。与CGI这种为每个请求创建一个新的进程不同，FastCGI使用持续的进程来处理一连串的请求。这些进程由FastCGI进程管理器管理，而不是web服务器。

通过图来理解PHP-FPM和Nginx的通信

（1）当Nginx收到http请求（动态请求），它会初始化FastCGI环境。（如果是Apache服务器，则初始化modefastcgi模块、如果是Nginx服务器则初始化ngxhttp_fastcgi_module）

（2）我们在配置nginx解析php请求时，一般会有这样一行配置：

fastcgi_pass 127.0.0.1:9000;

或者长这样：
fastcgi_pass unix:/tmp/php-cgi.sock;

它其实是Nginx和PHP-FPM一个通信载体（或者说通信方式），目的是为了让Nginx知道，收到动态请求之后该往哪儿发。（关于这两种配置的区别，后边会专门介绍）

（3）Nginx将请求采用socket的方式转给FastCGI主进程

（4）FastCGI主进程选择一个空闲的worker进程连接，然后Nginx将CGI环境变量和标准输入发送该worker进程（php-cgi）

（5）worker进程完成处理后将标准输出和错误信息从同一socket连接返回给Nginx

（6）worker进程关闭连接，等待下一个连接

不从配置的角度，再描述一下PHP和Nginx的通信

我们知道Nginx也是有master和worker进程的，worker进程直接处理每一个网络请求
其实在Nginx+PHP的架构里边，php可以看做是一个cgi程序的角色，因此出现了php-fpm进程管理器来处理这些php请求。php-fpm和nginx一样，也会监听端口（通过nginx.conf里的配置我们知道，nginx默认监听8080端口，php-fpm默认监听9000端口），并且有master和worker进程，worker负责处理每一个php请求
关于fastcgi：fastcgi是一个协议。市面上有多种实现了fastcgi协议的进程管理器，php-fpm就是其中的一种。php-fpm作为一种fastcgi进程管理服务，会监听端口，一般默认监听9000端口，并且是监听本机，也就是只接收来自本机的端口请求
关于fastcgi的配置文件，目前fastcgi的配置文件一般放在nginx.conf同级目录下，配置文件形式，一般有两种：

fastcgi.conf和 fastcgi_params。
不同的nginx版本会有不同的配置文件，这两个配置文件有一个非常重要的区别：
fastcgi_parames文件中缺少下列配置：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

我们可以打开fastcgi_params文件加上上述行，也可以在要使用配置的地方动态添加。使得该配置生效

当需要处理php请求时，nginx的worker进程会将请求移交给php-fpm的worker进程进行处理，也就是最开头所说的nginx调用了php，其实严格得讲是nginx间接调用php（反向代理的方式）
我本机配置了能正常解析php程序的nginx配置，介绍一下每一行配置的含义

server{
listen 8080;
index index.php
root /work/html/;
location ~ [^/]\.php(/|$)
{
root /work/html/;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
access_log /work/html/logs/test.log;
}

第一个大括号 server{ }：代表一个独立的server
listen 8080：代表该server监听8080端口
location ~ [^/].php(/|$){ }：代表一个能匹配对应uri的location，用于匹配一类uri，并对所匹配的uri请求做自定义的逻辑、配置。这里的location，匹配了所有带.php的uri请求，例如：http://192.168.244.128:8011/test.php/asdasdhttp://192.168.244.128:8011/index.php等
root /work/html/：请求资源根目录，告诉匹配到该location下的uri到/work/html/文件夹下去寻找同名资源
fastcgi_pass 127.0.0.1:9000：这行代码的意思是，将进入到该location内的uri请求看做是cgi程序，并将请求发送到9000端口，交由php-fpm处理(php-fpm配置中会看见它监听了此端口)
fastcgiparam SCRIPTFILENAME

fastcgiscriptname; ：这行配置意思是：动态添加了一行fastcgi配置，配置内容为SCRIPTFILENAME，告知管理进程，cgi脚本名称。由于我的nginx中只有fastcgiparams文件，没有fastcgi.conf文件，所以要使php-fpm知道SCRIPT_FILENAME的具体值，就必须要动态的添加这行配置

include fastcgi_params; 引入fastcgi配置文件

fastcgi_pass

Nginx和PHP-FPM的进程间通信有两种方式,一种是TCP Socket,一种是Unix Socket.

Tcp Socket方式是IP加端口,可以跨服务器.而UNIX Socket不经过网络,只能用于Nginx跟PHP-FPM都在同一服务器的场景，用哪种取决于你的PHP-FPM配置

Tcp Socket方式：

nginx.conf中配置：fastcgi_pass 127.0.0.1:9000;

php-fpm.conf中配置：listen=127.0.0.1:9000;

Unix Domain Socket方式:

nginx.conf中配置：fastcgi_pass unix:/tmp/php-fpm.sock;

php-fpm中配置：listen = /tmp/php-fpm.sock；

(php-fpm.sock是一个文件,由php-fpm生成)

举例：

两种通信配置方式，Nginx和PHP-FPM的通信过程如下：

Tcp Socket：

Nginx <=socket <=TCP/IP <=socket <=PHP-FPM

(上边画Nginx和PHP-FPM通信的图时就是这种方式，这种情况是Nginx和PHP-FPM在同一台机器上)

看一下Nginx和PHP-FPM不在同一台机器上的情况：

Nginx <=> socket <=> TCP/IP <=> 物理层 <=> 路由器 <=> 物理层 <=> 
TCP/IP <=> socket <=> PHP-FPM

Unix Socket：

Nginx <=> socket <=> PHP-FPM

include fastcgi_params;
在nginx中有很多的fasgcgi*的配置，更多的配置可以在nginx.conf的同级目录中看到，在fastcgi.conf和fastcgiparams中，这两个的区别，上边有说明。看一下里边的内容：

这里边的内容都会被传递给PHP-FPM所管理的fastcgi进程。为什么会传递这些呢？相信大家都用过$SERVER这个全局变量，这里边的值就是从此配置中拿到的。我们可以在fastcgiparams中看到REMOTEADDR，就是客户端地址，PHP之所以能拿到客户端信息，就是因为Nginx的配置中的fastcgiparams。更多ngxhttpfastcgimodule模块的内容，可以看官方文档：http://nginx.org/en/docs/http/ngxhttp_fastcgi_module.html

php-fpm.conf配置

熟悉php-fpm的配置，能帮助我们优化服务器性能

emergency_restart_threshold = 60
emergency_restart_interval = 60s

表示在emergencyrestartinterval所设值内出现SIGSEGV或者SIGBUS错误的php-cgi进程数如果超过 emergencyrestartthreshold个，php-fpm就会优雅重启。这两个选项一般保持默认值

process_control_timeout = 0

设置子进程接受主进程复用信号的超时时间. 可用单位: s(秒), m(分), h(小时), 或者 d(天) 默认单位: s(秒). 默认值: 0.

listen = 127.0.0.1:9000

fpm监听端口，即nginx中php处理的地址，一般默认值即可。可用格式为: ‘ip:port’, ‘port’, ‘/path/to/unix/socket’. 每个进程池都需要设置.

request_slowlog_timeout = 10s
#当一个请求该设置的超时时间后，就会将对应的PHP调用堆栈信息完整写入到慢日志中. 
设置为 ’0′ 表示 ‘Off’
slowlog = log/$pool.log.slow
慢请求的记录日志,配合request_slowlog_timeout使用

下边几个配置参数比较重要：

pm
pm指的是process manager，指定进程管理器如何控制子进程的数量，它为必填项，支持3个值
(1)static: 使用固定的子进程数量，由pm.max_children指定(可以同时存活的子进程的最大数量)
(2)dynamic：基于下面的参数动态的调整子进程的数量，至少有一个子进程(会使用下边几个配置)
pm.start_servers: 启动时创建的子进程数量，默认值为min_spare_servers + max_spare_servers -
 min_spare_servers) / 2
pm.min_spare_servers: 空闲状态的子进程的最小数量，如果不足，新的子进程会被自动创建
pm.max_spare_servers: 空闲状态的子进程的最大数量，如果超过，一些子进程会被杀死
(3)ondemand: 启动时不会创建子进程，当新的请求到达时才创建，有下边两个配置
pm.max_children
pm.process_idle_timeout 子进程的空闲超时时间，如果超时时间到没有新的请求可以服务，则会被
杀死
区别：
如果pm设置为 static，那么其实只有pm.max_children这个参数生效。系统会开启设置数量的
php-fpm进程
如果pm设置为 dynamic，那么pm.max_children参数失效，后面3个参数生效
系统会在php-fpm运行开始 的时候启动pm.start_servers个php-fpm进程，
然后根据系统的需求动态在pm.min_spare_servers和pm.max_spare_servers之间调整php-fpm进程数
还有一个比较重要的配置：
pm.max_requests
每一个子进程的最大请求服务数量，如果超过了这个值，该子进程会被自动重启。在解决第三方库的
内存泄漏问题时，这个参数会很有用。默认值为0，指子进程可以持续不断的服务请求

PHP-FPM进程池

php-fpm.conf中默认配置了一个进程池，我们可以打开我们的php-fpm.conf看一下，下边是我的：

现在我们执行一下:ps -aux|grep php-fpm

会看见有一个master，10个worker进程，和我们配置的一样（www为进程池名）

想配置多个，这样做即可：

在nginx中fastcgi_pass这个地方配置使用哪个进程池即可。

（完）

原文参考：知乎文章

发表于   |   分类于

这篇文章是《HTTP API 认证授权术》的姊妹篇，在那篇文章中，主要介绍了 HTTP API 认证和授权技术中用到的 HTTP Basic, Digest Access, HMAC, OAuth, JWT 等各种方式，主要是 API 上用到的一些技术，这篇文章主要想说的是另一个话题——身份认证。也就是说，怎么确认这个数据就是这个人发出来的？

用户密码

要解决这个问题，我们先来看一个最简单的解——使用密码，通常来说，在网络上要证明一个人的身份的话，都需要这个人的一些私密而唯一的东西。比如，像密码这样的东西，很多地方，只要你提供了你的用户名+密码，就可以确定这个人是你（注明：关于密码管理，强密码设定，密码泄漏，密码破解以及密码哄骗不在这篇文章的话题中），也就是说，这个密码是非常私密的事，我们可以假设，这个事全世界只能有当事人一个人知道，所以，当事人得供正确的密码，我们就可以认证这个人了。

为了加强密码的安全程度，一般会使用 2FA（Two-factor authentication）或 MFA（Multi-factor authentication），双因认证或多因认证，这需要用户提供一个唯一的可信设备，比如用户的手机，然后通过验证手机短信，或是像 Google Authenticator 这样的动态口令来完成。这样的安全级别已经算是比较高了。如果能够再加上经常性的变更密码，那么安全级别就更好了。

另外，一些公司还使用了生物密码来进行用户的身份验证，比如人脸识别。但是，我个人觉得人脸识别或是生物识别是比较糟糕的方式，因为：

  • 目前能被验证的生物信息（如人脸和指纹）太容易被别人获得和伪造了。
  • 这样东西不能被变更和吊销，密码可以被吊销和重置，人脸则不能。

密钥对和证书

密码可以解决身证认证的问题有很多问题，最重要的一个问题就是，你要把你的密码提供给对方，对方才能验证你的身份。你不可能把你的密码提供给全世界的人吧，这样的话，全世界的人都有你的密码了，那么任何人都能变成你了。所以，用户密码这个事只能存在于权威机构和普通用户之间，不能存在于普遍应用中。所以，这里需要使用更好的解决方案。

使用 ECC（Elliptic-Curve Cryptography）椭圆曲线密码术，可以通过一个“密钥对”进行非对称加密。这种技术，在对信息进行加密和解密时，使用两个不同的密钥，其中一个用来做加密，另一个做解密。这样一来，我们就可以把其中一个密钥公布出去，称之为公钥，另一个密钥私密地保管好，称之为私钥。

比如，我用我的私钥加密信息，然后，我把这个私钥所配对的公钥发布给所有人，大家都用公钥解密信息，不用我的公钥你解密不了这个信息。这样一来，就可以保证这个信息是我发出来的，不但保证了信息安全，还完成了身份认证。

这样的现实案例一般用于网站，也就是用户得要知道我访问的这个网站是真实的，不是别人做的。因为 DNS 很容易被 hack，你连上一个不可信的网络，这个网络里的 DNS 把这个网站的 IP 地址解析成什么 就是什么了。但是有了这个加密的机制后，网站把自己的信息加密后连同公钥给到访问者，访问解密后就知道是不是这个网站了。

但是，这里还是会有一个很严重的问题，那就是中间人攻击。如下图所示：

中间人 Chad 把自己伪装成 Bob 向 Alice 要信息，然后，再伪装成 Alice 对 Bob 说，这就是 Alice 的公钥，于是 Bob 也无法验证是不是 Alice 的公钥，因为公钥里就是一堆乱七八糟的数据，我们完全不能分辨哪个公钥属于 Alice 的。试想，如果我们收到声称属于银行的密钥。我们怎么知道它确实属于你的银行？

这里的答案就是使用数字证书。证书跟我们的身份证非常类似，其需要一个可信机构来颁发和验证的。这个证书机构 CA（Certificate Authority）是一个是大家都相信的权威机构，他用他的人品保证（当然一般会被严格管理和审计），CA 机构同样使用这样的非对称加密的技术来完成颁发和验证的事。下图展示了这一过程。

说明一下上面这个图：

  1. 为了解决公钥认证的问题的，我们需要一个权威的CA 机构。
  2. Alice 把自己的信息（姓名、组织，地址，电邮，网址等）和自己的公钥打包成一个 CSR 的文件，发给 CA 机构，
  3. CA 机构会来找 Alice 做物理世界的认证，如果通过后，就会用自己的机构私钥，把CSR 变成一个签名证书。
  4. Bob 同学拿到 Alice 的证书，用 CA 机构的公钥解密后，得到 Alice 的公钥
  5. 后面就可以签证 信息是否来自 Alice 了。

是的，这个过程就是在“套娃”，这种证书机构还可以给下级的证书机构发证，于是就会一层套一层地，形成一个证书链，顶层的叫根证书，你得绝对信任之。对于验证证书真实性的客户端，它需要能够验证链中所有 CA 的签名，这意味着客户端需要访问链中所有 CA 的证书。

证书生成过程演示

并不是所有的场景都需要向这些大型的 CA 机构申请公钥证书，在任何一个企业，组织或是团体内都可以自己形这样的“小王国”，也就是说，你可以自行生成这样的证书，只需要你自己保证自己的生成证书的私钥的安全，以及不需要扩散到整个互联网。下面，我们用 openssl命令来演示这个过程。

1）生成 CA 的证书（公钥） ca.crt 和私钥 ca.key

openssl req -newkey rsa:2048 \
-new -nodes -x509 \
-days 365 \
-out ca.crt \
-keyout ca.key \
-subj "/C=SO/ST=Earth/L=Mountain/O=CoolShell/OU=HQ/CN=localhost"

2) 生成 alice 的私钥

openssl genrsa -out alice.key 2048

3）生成 Alice 的 CSR – Certificate Signing Request

openssl req -new -key alice.key 365 -out alice.csr \
-subj "/C=CN/ST=Beijing/L=Haidian/O=CoolShell/OU=Test/CN=localhost.alice"

4）使用 CA 给 Alice 签名证书

openssl x509  -req -in alice.csr \
-extfile <(printf "subjectAltName=DNS:localhost.alice") \ 
-CA ca.crt -CAkey ca.key  \
-days 365 -sha256 -CAcreateserial \
-out alice.crt

##双向认证 mTLS
上面，我们说的基本上都是单向认证，大量的场景都是确保用户方访问的是真正的服务方，如：银行，电商网站，等。这样可以保证用户不会被钓鱼网站或是中间人攻击。但是，很多时候，我们也是需要双向认证的。下面是一个典型的场景——微信支付和商户间交互

  • 用户到商家那边买东西，商家要求用户进行支付。
  • 用户选择了微信支付，于是，界面从商户侧切到了微信侧
  • 微信那边支付完成后，商户这边收到微信那边支付完成的通知，于是开始发货。

这个过程中有件事非常重要——就是微信通知商户支付完成的时候。

  • 微信得确保通知到的就是用户所支付商户，而不是别个。
  • 商户也得要能确认，来通知我的就是微信，不是别人。

一般来说，微信会给商户一个 AppID和一个 AppSerct，用这个来确保是我认证过的商户来调用我，然后，需要商户在自己的系统里填一个回调的 URL，并通过平台设置的 key来做 MD5/HMAC的签名来确保是官方的回调。这都是在《HTTP API 认证授权术》中提到过的技术，是相对传统的技术。

如今，mTLS是确保云原生应用程序中服务之间的通信安全的首选协议。 也就是双向认证。

传统的 TLS 认证过程是：

  1. 客户端连接到服务器
  2. 服务器提供其 TLS 证书
  3. 客户端验证服务器的证书
  4. 客户端和服务器通过加密的 TLS 连接交换信息

在 mTLS 中，客户端和服务器都有一个证书，双方都使用他们的公钥/私钥对进行身份验证。与常规 TLS 相比，mTLS 中有额外的步骤来验证双方（以粗体显示的额外步骤）：

  1. 客户端连接到服务器
  2. 服务器提供其 TLS 证书
  3. 客户端验证服务器的证书
  4. 客户端出示其 TLS 证书
  5. 服务器验证客户端的证书
  6. 服务器授予访问权限
  7. 客户端和服务器通过加密的 TLS 连接交换信息

mTLS 需要“根”TLS 证书；这我们自己来完成证书颁发机构的职责。授权客户端和服务器使用的证书必须与此根证书相对应。根证书是自签名的，这意味着我们需要自己创建它。（注：此方法不适用于公共 Internet 上的单向 TLS，因为外部证书颁发机构必须颁发这些证书）

那么，为什么整个互联网上都用了 TLS 了，为什么 不升级一下使用 mTLS？这里有两方面的原因：

  • 公共互联网上要解决的问题是：A) 确保用户访问到的是正确的网站，而不是钓鱼网站。B）网站传输的内容是安全和私密且不会被篡改的。
  • 将 TLS 证书分发到所有最终用户设备将非常困难。生成、管理和验证为此所需的数十亿个证书几乎是不可能的任务。

在较小的范围内，mTLS 对于单个组织非常有用且非常实用，尤其是当这些组织采用零信任方法来确保网络安全时。由于默认情况下零信任方法不信任任何用户、设备或请求，因此组织必须能够在每次尝试访问网络中的任何点时对每个用户、设备和请求进行身份验证。mTLS 通过对用户进行身份验证和设备验证来帮助实现这一目标。

关于 mTLS，这里有一个我用 Golang 写的示例 – https://github.com/haoel/mTLS，大家可以参考一下。

P.S. 本文图版中的卡司来自安全圈的标准 Cast，参看 Alice and Bob。

（全文完）

原文链接：《网络数字身份认证术》

发表于   |   分类于

我们知道，HTTP是无状态的，所以，当我们需要获得用户是否在登录的状态时，我们需要检查用户的登录状态，一般来说，用户的登录成功后，服务器会发一个登录凭证（又被叫作Token），就像你去访问某个公司，在前台被认证过合法后，这个公司的前台会给你的一个访客卡一样，之后，你在这个公司内去到哪都用这个访客卡来开门，而不再校验你是哪一个人。在计算机的世界里，这个登录凭证的相关数据会放在两种地方，一个地方在用户端，以Cookie的方式（一般不会放在浏览器的Local Storage，因为这很容易出现登录凭证被XSS攻击），另一个地方是放在服务器端，又叫Session的方式（SessonID存于Cookie）。

但是，这个世界还是比较复杂的，除了用户访问，还有用户委托的第三方的应用，还有企业和企业间的调用，这里，我想把业内常用的一些 API认证技术相对系统地总结归纳一下，这样可以让大家更为全面的了解这些技术。注意，这是一篇长文！

本篇文章会覆盖如下技术：

  • HTTP Basic
  • Digest Access
  • App Secret Key + HMAC
  • JWT – JSON Web Tokens
  • OAuth 1.0 – 3 legged & 2 legged
  • OAuth 2.0 – Authentication Code & Client Credential

HTTP Basic

HTTP Basic 是一个非常传统的API认证技术，也是一个比较简单的技术。这个技术也就是使用 username和 password 来进行登录。整个过程被定义在了 RFC 2617 中，也被描述在了 Wikipedia: Basic Access Authentication 词条中，同时也可以参看 MDN HTTP Authentication

其技术原理如下：

1、把 username和 password 做成 username:password 的样子（用冒号分隔）

2、进行Base64编码。Base64(“username:password”) 得到一个字符串（如：把 haoel:coolshell 进行base64 后可以得到 aGFvZW86Y29vbHNoZWxsCg ）

3、把 aGFvZW86Y29vbHNoZWxsCg放到HTTP头中 Authorization 字段中，形成 Authorization: Basic aGFvZW86Y29vbHNoZWxsCg，然后发送到服务端。

4、服务端如果没有在头里看到认证字段，则返回401错，以及一个个WWW-Authenticate: Basic Realm=’HelloWorld’ 之类的头要求客户端进行认证。之后如果没有认证通过，则返回一个401错。如果服务端认证通过，那么会返回200。

我们可以看到，使用Base64的目的无非就是为了把一些特殊的字符给搞掉，这样就可以放在HTTP协议里传输了。而这种方式的问题最大的问题就是把用户名和口令放在网络上传，所以，一般要配合TLS/SSL的安全加密方式来使用。我们可以看到 JIRA Cloud 的API认证支持HTTP Basic 这样的方式。

但我们还是要知道，这种把用户名和密码同时放在公网上传输的方式有点不太好，因为Base64不是加密协议，而是编码协议，所以就算是有HTTPS作为安全保护，给人的感觉还是不放心。

Digest Access

中文称“HTTP 摘要认证”，最初被定义在了 RFC 2069 文档中（后来被 RFC 2617 引入了一系列安全增强的选项；“保护质量”(qop)、随机数计数器由客户端增加、以及客户生成的随机数）。

其基本思路是，请求方把用户名口令和域做一个MD5 – MD5(username:realm:password) 然后传给服务器，这样就不会在网上传用户名和口令了，但是，因为用户名和口令基本不会变，所以，这个MD5的字符串也是比较固定的，因此，这个认证过程在其中加入了两个事，一个是 nonce 另一个是 qop

  • 首先，调用方发起一个普通的HTTP请求。比如：GET /coolshell/admin/ HTTP/1.1
  • 服务端自然不能认证能过，服务端返回401错误，并且在HTTP头里的 WWW-Authenticate 包含如下信息：
WWW-Authenticate: Digest realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
  • 其中的 nonce 为服务器端生成的随机数，然后，客户端做 HASH1=MD5(MD5(username:realm:password):nonce:cnonce) ，其中的 cnonce 为客户端生成的随机数，这样就可以使得整个MD5的结果是不一样的。
  • 如果 qop 中包含了 auth ，那么还得做 HASH2=MD5(method:digestURI) 其中的 method 就是HTTP的请求方法（GET/POST…），digestURI 是请求的URL。
  • 如果 qop 中包含了 auth-init ，那么，得做 HASH2=MD5(method:digestURI:MD5(entityBody)) 其中的 entityBody 就是HTTP请求的整个数据体。
  • 然后，得到 response = MD5(HASH1:nonce:nonceCount:cnonce:qop:HASH2) 如果没有 qop则 response = MD5(HA1:nonce:HA2)
  • 最后，我们的客户端对服务端发起如下请求—— 注意HTTP头的 Authorization: Digest …
    GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
 realm="testrealm@host.com",
 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
 uri="%2Fcoolshell%2Fadmin",
 qop=auth,
 nc=00000001,
 cnonce="0a4f113b",
 response="6629fae49393a05397450978507c4ef1",
 opaque="5ccc069c403ebaf9f0171e9517f40e41"

    维基百科上的 Wikipedia: Digest access authentication 词条非常详细地描述了这个细节。

摘要认证这个方式会比之前的方式要好一些，因为没有在网上传递用户的密码，而只是把密码的MD5传送过去，相对会比较安全，而且，其并不需要是否TLS/SSL的安全链接。但是，别看这个算法这么复杂，最后你可以发现，整个过程其实关键是用户的password，这个password如果不够得杂，其实是可以被暴力破解的，而且，整个过程是非常容易受到中间人攻击——比如一个中间人告诉客户端需要的 Basic 的认证方式 或是 老旧签名认证方式（RFC2069）。

App Secret Key + HMAC

先说HMAC技术，这个东西来自于MAC – Message Authentication Code，是一种用于给消息签名的技术，也就是说，我们怕消息在传递的过程中被人修改，所以，我们需要用对消息进行一个MAC算法，得到一个摘要字串，然后，接收方得到消息后，进行同样的计算，然后比较这个MAC字符串，如果一致，则表明没有被修改过（整个过程参看下图）。而HMAC – Hash-based Authenticsation Code，指的是利用Hash技术完成这一工作，比如：SHA-256算法。

（图片来自 Wikipedia – MAC 词条 ）

我们再来说App ID，这个东西跟验证没有关系，只是用来区分，是谁来调用API的，就像我们每个人的身份证一样，只是用来标注不同的人，不是用来做身份认证的。与前面的不同之处是，这里，我们需要用App ID 来映射一个用于加密的密钥，这样一来，我们就可以在服务器端进行相关的管理，我们可以生成若干个密钥对（AppID, AppSecret），并可以有更细粒度的操作权限管理。

把AppID和HMAC用于API认证，目前来说，玩得最好最专业的应该是AWS了，我们可以通过S3的API请求签名文档看到AWS是怎么玩的。整个过程还是非常复杂的，可以通过下面的图片流程看个大概。基本上来说，分成如下几个步骤：

  • 把HTTP的请求（方法、URI、查询字串、头、签名头，body）打个包叫 CanonicalRequest，作个SHA-256的签名，然后再做一个base16的编码
  • 把上面的这个签名和签名算法 AWS4-HMAC-SHA256、时间戳、Scop，再打一个包，叫 StringToSign。
  • 准备签名，用 AWSSecretAccessKey来对日期签一个 DataKey，再用 DataKey 对要操作的Region签一个 DataRegionKey ，再对相关的服务签一个DataRegionServiceKey ，最后得到 SigningKey.
  • 用第三步的 SigningKey来对第二步的 StringToSign 签名。

  • 最后，发出HTTP Request时，在HTTP头的 Authorization字段中放入如下的信息：
Authorization: AWS4-HMAC-SHA256 
Credential=AKIDEXAMPLE/20150830/us-east-1/iam/aws4_request, 
SignedHeaders=content-type;host;x-amz-date, 
Signature=5d672d79c15b13162d9279b0855cfba6789a8edb4c82c400e06b5924a6f2b5d7

其中的 AKIDEXAMPLE 是 AWS Access Key ID， 也就是所谓的 AppID，服务器端会根据这个AppID来查相关的 Secret Access Key，然后再验证签名。如果，你对这个过程有点没看懂的话，你可以读一读这篇文章——《Amazon S3 Rest API with curl》这篇文章里有好些代码，代码应该是最有细节也是最准确的了。

这种认证的方式好处在于，AppID和AppSecretKey，是由服务器的系统开出的，所以，是可以被管理的，AWS的IAM就是相关的管理，其管理了用户、权限和其对应的AppID和AppSecretKey。但是不好的地方在于，这个东西没有标准 ，所以，各家的实现很不一致。比如： Acquia 的 HMAC，微信的签名算法 （这里，我们需要说明一下，微信的API没有遵循HTTP协议的标准，把认证信息放在HTTP 头的 Authorization 里，而是放在body里）

JWT – JSON Web Tokens

JWT是一个比较标准的认证解决方案，这个技术在Java圈里应该用的是非常普遍的。JWT签名也是一种MAC（Message Authentication Code）的方法。JWT的签名流程一般是下面这个样子：

  1. 用户使用用户名和口令到认证服务器上请求认证。
  2. 认证服务器验证用户名和口令后，以服务器端生成JWT Token，这个token的生成过程如下：
    • 认证服务器还会生成一个 Secret Key（密钥）
    • 对JWT Header和 JWT Payload分别求Base64。在Payload可能包括了用户的抽象ID和的过期时间。
    • 用密钥对JWT签名 HMAC-SHA256(SecertKey, Base64UrlEncode(JWT-Header)+’.’+Base64UrlEncode(JWT-Payload));

3.然后把 base64(header).base64(payload).signature 作为 JWT token返回客户端。

4.客户端使用JWT Token向应用服务器发送相关的请求。这个JWT Token就像一个临时用户权证一样。

当应用服务器收到请求后：

  1. 应用服务会检查 JWT Token，确认签名是正确的。
  2. 然而，因为只有认证服务器有这个用户的Secret Key（密钥），所以，应用服务器得把JWT Token传给认证服务器。
  3. 认证服务器通过JWT Payload 解出用户的抽象ID，然后通过抽象ID查到登录时生成的Secret Key，然后再来检查一下签名。
  4. 认证服务器检查通过后，应用服务就可以认为这是合法请求了。

我们可以看以，上面的这个过程，是在认证服务器上为用户动态生成 Secret Key的，应用服务在验签的时候，需要到认证服务器上去签，这个过程增加了一些网络调用，所以，JWT除了支持HMAC-SHA256的算法外，还支持RSA的非对称加密的算法。

使用RSA非对称算法，在认证服务器这边放一个私钥，在应用服务器那边放一个公钥，认证服务器使用私钥加密，应用服务器使用公钥解密，这样一来，就不需要应用服务器向认证服务器请求了，但是，RSA是一个很慢的算法，所以，虽然你省了网络调用，但是却费了CPU，尤其是Header和Payload比较长的时候。所以，一种比较好的玩法是，如果我们把header 和 payload简单地做SHA256，这会很快，然后，我们用RSA加密这个SHA256出来的字符串，这样一来，RSA算法就比较快了，而我们也做到了使用RSA签名的目的。

最后，我们只需要使用一个机制在认证服务器和应用服务器之间定期地换一下公钥私钥对就好了。

这里强烈建议全文阅读 Anglar 大学的 《JSW：The Complete Guide to JSON Web Tokens》

OAuth 1.0

OAuth也是一个API认证的协议，这个协议最初在2006年由Twitter的工程师在开发OpenID实现的时候和社交书签网站Ma.gnolia时发现，没有一种好的委托授权协议，后来在2007年成立了一个OAuth小组，知道这个消息后，Google员工也加入进来，并完善有善了这个协议，在2007年底发布草案，过一年后，在2008年将OAuth放进了IETF作进一步的标准化工作，最后在2010年4月，正式发布OAuth 1.0，即：RFC 5849 （这个RFC比起TCP的那些来说读起来还是很轻松的），不过，如果你想了解其前身的草案，可以读一下 OAuth Core 1.0 Revision A ，我在下面做个大概的描述。

根据RFC 5849，可以看到 OAuth 的出现，目的是为了，用户为了想使用一个第三方的网络打印服务来打印他在某网站上的照片，但是，用户不想把自己的用户名和口令交给那个第三方的网络打印服务，但又想让那个第三方的网络打印服务来访问自己的照片，为了解决这个授权的问题，OAuth这个协议就出来了。

  • 这个协议有三个角色：
    • User（照片所有者-用户）
    • Consumer（第三方照片打印服务）
    • Service Provider（照片存储服务）
  • 这个协义有三个阶段：
    • Consumer获取Request Token
    • Service Provider 认证用户并授权Consumer
    • Consumer获取Access Token调用API访问用户的照片

整个授权过程是这样的：

  1. Consumer（第三方照片打印服务）需要先上Service Provider获得开发的 Consumer Key 和 Consumer Secret
  2. 当 User 访问 Consumer 时，Consumer 向 Service Provide 发起请求请求Request Token （需要对HTTP请求签名）
  3. Service Provide 验明 Consumer 是注册过的第三方服务商后，返回 Request Token（oauth_token）和 Request Token Secret （oauth_token_secret）
  4. Consumer 收到 Request Token 后，使用HTTP GET 请求把 User 切到 Service Provide 的认证页上（其中带上Request Token），让用户输入他的用户和口令。
  5. Service Provider 认证 User 成功后，跳回 Consumer，并返回 Request Token （oauth_token）和 Verification Code（oauth_verifier）
  6. 接下来就是签名请求，用Request Token 和 Verification Code 换取 Access Token （oauth_token）和 Access Token Secret (oauth_token_secret)
  7. 最后使用Access Token 访问用户授权访问的资源。
    下图附上一个Yahoo!的流程图可以看到整个过程的相关细节。

因为上面这个流程有三方：User，Consumer 和 Service Provide，所以，又叫 3-legged flow，三脚流程。OAuth 1.0 也有不需要用户参与的，只有Consumer 和 Service Provider 的， 也就是 2-legged flow 两脚流程，其中省掉了用户认证的事。整个过程如下所示：

  1. Consumer（第三方照片打印服务）需要先上Service Provider获得开发的 Consumer Key 和 Consumer Secret
  2. Consumer 向 Service Provide 发起请求请求Request Token （需要对HTTP请求签名）
  3. Service Provide 验明 Consumer 是注册过的第三方服务商后，返回 Request Token（oauth_token）和 Request Token Secret （oauth_token_secret）
  4. Consumer 收到 Request Token 后，直接换取 Access Token （oauth_token）和 Access Token Secret (oauth_token_secret)
  5. 最后使用Access Token 访问用户授权访问的资源。
    最后，再来说一说OAuth中的签名。
  • 我们可以看到，有两个密钥，一个是Consumer注册Service Provider时由Provider颁发的 Consumer Secret，另一个是 Token Secret。
  • 签名密钥就是由这两具密钥拼接而成的，其中用 &作连接符。假设 Consumer Secret 为 j49sk3j29djd 而 Token Secret 为dh893hdasih9那个，签名密钥为：j49sk3j29djd&dh893hdasih9
  • 在请求Request/Access Token的时候需要对整个HTTP请求进行签名（使用HMAC-SHA1和HMAC-RSA1签名算法），请求头中需要包括一些OAuth需要的字段，如：
    • Consumer Key ： 也就是所谓的AppID
    • Token： Request Token 或 Access Token
    • Signature Method ：签名算法比如：HMAC-SHA1
    • Timestamp：过期时间
    • Nonce：随机字符串
    • Call Back：回调URL
      下图是整个签名的示意图：

图片还是比较直观的，我就不多解释了。

OAuth 2.0

在前面，我们可以看到，从Digest Access， 到AppID+HMAC，再到JWT，再到OAuth 1.0，这些个API认证都是要向Client发一个密钥（或是用密码）然后用HASH或是RSA来签HTTP的请求，这其中有个主要的原因是，以前的HTTP是明文传输，所以，在传输过程中很容易被篡改，于是才搞出来一套的安全签名机制，所以，这些个认证的玩法是可以在HTTP明文协议下玩的。

这种使用签名方式大家可以看到是比较复杂的，所以，对于开发者来说，也是很不友好的，在组织签名的那些HTTP报文的时候，各种，URLEncode和Base64，还要对Query的参数进行排序，然后有的方法还要层层签名，非常容易出错，另外，这种认证的安全粒度比较粗，授权也比较单一，对于有终端用户参与的移动端来说也有点不够。所以，在2012年的时候，OAuth 2.0 的 RFC 6749 正式放出。

OAuth 2.0依赖于TLS/SSL的链路加密技术（HTTPS），完全放弃了签名的方式，认证服务器再也不返回什么 token secret 的密钥了，所以，OAuth 2.0是完全不同于1.0 的，也是不兼容的。目前，Facebook 的 Graph API 只支持OAuth 2.0协议，Google 和 Microsoft Azure 也支持Auth 2.0，国内的微信和支付宝也支持使用OAuth 2.0。

下面，我们来重点看一下OAuth 2.0的两个主要的Flow：

  • 一个是Authorization Code Flow， 这个是 3 legged 的
  • 一个是Client Credential Flow，这个是 2 legged 的。

    Authorization Code Flow

    Authorization Code 是最常使用的OAuth 2.0的授权许可类型，它适用于用户给第三方应用授权访问自己信息的场景。这个Flow也是OAuth 2.0四个Flow中我个人觉得最完整的一个Flow，其流程图如下所示。

下面是对这个流程的一个细节上的解释：

1）当用户（Resource Owner）访问第三方应用（Client）的时候，第三方应用会把用户带到认证服务器（Authorization Server）上去，主要请求的是 /authorize API，其中的请求方式如下所示。

https://login.authorization-server.com/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Fexample-client.com%2Fcallback%2F
&scope=read
&state=xcoiv98CoolShell3kch

其中：

  • client_id为第三方应用的App ID
  • response_type=code为告诉认证服务器，我要走Authorization Code Flow。
  • redirect_uri意思是我跳转回第三方应用的URL
  • scope意是相关的权限
  • state 是一个随机的字符串，主要用于防CSRF攻击。

2）当Authorization Server收到这个URL请求后，其会通过 client_id来检查 redirect_uri和 scope是否合法，如果合法，则弹出一个页面，让用户授权（如果用户没有登录，则先让用户登录，登录完成后，出现授权访问页面）。

3）当用户授权同意访问以后，Authorization Server 会跳转回 Client ，并以其中加入一个 Authorization Code。 如下所示：

https://example-client.com/callback?
code=Yzk5ZDczMzRlNDEwYlrEqdFSBzjqfTG
&state=xcoiv98CoolShell3kch

我们可以看到，

请流动的链接是第 1）步中的 redirect_uri
其中的 state 的值也和第 1）步的 state一样。

4）接下来，Client 就可以使用 Authorization Code 获得 Access Token。其需要向 Authorization Server 发出如下请求。

POST /oauth/token HTTP/1.1
Host: authorization-server.com

code=Yzk5ZDczMzRlNDEwYlrEqdFSBzjqfTG
&grant_type=code
&redirect_uri=https%3A%2F%2Fexample-client.com%2Fcallback%2F
&client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&client_secret=JqQX2PNo9bpM0uEihUPzyrh

5）如果没什么问题，Authorization 会返回如下信息。

{
  "access_token": "iJKV1QiLCJhbGciOiJSUzI1NiI",
  "refresh_token": "1KaPlrEqdFSBzjqfTGAMxZGU",
  "token_type": "bearer",
  "expires": 3600,
  "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciO.eyJhdWQiOiIyZDRkM..."
}

其中，

  • access_token就是访问请求令牌了
  • refresh_token用于刷新 access_token
  • id_token 是JWT的token，其中一般会包含用户的OpenID

6）接下来就是用 Access Token 请求用户的资源了。

GET /v1/user/pictures
Host: https://example.resource.com

Authorization: Bearer iJKV1QiLCJhbGciOiJSUzI1NiI

Client Credential Flow

Client Credential 是一个简化版的API认证，主要是用于认证服务器到服务器的调用，也就是没有用户参与的的认证流程。下面是相关的流程图。

这个过程非常简单，本质上就是Client用自己的 client_id和 client_secret向Authorization Server 要一个 Access Token，然后使用Access Token访问相关的资源。

请求示例

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=czZCaGRSa3F0Mzpn
&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

返回示例

{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create"
}

这里，容我多扯一句，微信公从平台的开发文档中，使用了OAuth 2.0 的 Client Credentials的方式（参看文档“微信公众号获取access token”），我截了个图如下所谓。我们可以看到，微信公众号使用的是GET方式的请求，把AppID和AppSecret放在了URL中，虽然这也符合OAuth 2.0，但是并不好，因为大多数网关代理会把整个URI请求记到日志中。我们只要脑补一下腾讯的网关的Access Log，里面的日志一定会有很多的各个用户的AppID和AppSecret……

小结

讲了这么多，我们来小结一下（下面的小结可能会有点散）

两个术语和三个概念

  • 区分两个术语：Authentication（认证） 和 Authorization （授权），前者是证明请求者是身份，就像身份证一样，后者是为了获得权限。身份是区别于别人的证明，而权限是证明自己的特权。Authentication为了证明操作的这个人就是他本人，需要提供密码、短信验证码，甚至人脸识别。Authorization 则是不需要在所有的请求都需要验人，是在经过Authorization后得到一个Token，这就是Authorization。就像护照和签证一样。
  • 区分三个概念：编码Base64Encode、签名HMAC、加密RSA。Base64编码是为了更好的传输（没有怪异的字符，可以传输二进制文件），等同于明文，HMAC签名是为了信息不能被篡改，RSA加密是为了不让别人看到是什么信息。

    明白一些初衷

  • 使用复杂地HMAC哈希签名方式主要是应对当年没有TLS/SSL加密链路的情况。
  • JWT把 uid 放在 Token中目的是为了去掉状态，但不能让用户修改，所以需要签名。
  • OAuth 1.0区分了两个事，一个是第三方的Client，一个是真正的用户，其先拿Request Token，再换Access Token的方法主要是为了把第三方应用和用户区分开来。
  • 用户的Password是用户自己设置的，复杂度不可控，服务端颁发的Serect会很复杂，但主要目的是为了容易管理，可以随时注销掉。
  • OAuth 协议有比所有认证协议有更为灵活完善的配置，如果使用AppID/AppSecret签名的方式，又需要做到可以有不同的权限和可以随时注销，那么你得开发一个像AWS的IAM这样的账号和密钥对管理的系统。

    相关的注意事项

  • 无论是哪种方式，我们都应该遵循HTTP的规范，把认证信息放在 Authorization HTTP 头中。
  • 不要使用GET的方式在URL中放入secret之类的东西，因为很多proxy或gateway的软件会把整个URL记在Access Log文件中。
  • 密钥Secret相当于Password，但他是用来加密的，最好不要在网络上传输，如果要传输，最好使用TLS/SSL的安全链路。
  • HMAC中无论是MD5还是SHA1/SHA2，其计算都是非常快的，RSA的非对称加密是比较耗CPU的，尤其是要加密的字符串很长的时候。
  • 最好不要在程序中hard code 你的 Secret，因为在github上有很多黑客的软件在监视各种Secret，千万小心！这类的东西应该放在你的配置系统或是部署系统中，在程序启动时设置在配置文件或是环境变量中。
  • 使用AppID/AppSecret，还是使用OAuth1.0a，还是OAuth2.0，还是使用JWT，我个人建议使用TLS/SSL下的OAuth 2.0。
  • 密钥是需要被管理的，管理就是可以新增可以撤销，可以设置账户和相关的权限。最好密钥是可以被自动更换的。
  • 认证授权服务器（Authorization Server）和应用服务器（App Server）最好分开。

(全文完)

原文链接： HTTP API 认证授权术

原文姊妹篇链接：《网络数字身份认证术》

发表于   |   分类于

这两天跟 Cali 和 Rather 做了一个线上的 Podcast – Ep.5 一起聊聊团队协同。主要是从 IM 工具扩展开来聊了一下团队的协同和相应的工具，但是聊天不是深度思考，有一些东西我没有讲透讲好，所以，我需要把我更多更完整更结构化的想法形成文字。（注：聊天聊地比较详细，本文只是想表达我的主要想法）

国内外的企业 IM 的本质差别

国内企业级在线交流工具主要有：企业微信、钉钉、飞书，国外的则是：Slack、Discord这两大IM工具，你会发现，他们有很多不一样的东西，其中有两个最大的不同，一个是企业管理，一个是企业文化。

企业管理

Slack/Discrod 主要是通过建 Channel ，而国内的IM则主要是拉群。你可能会说，这不是一样的吗？其实是不一样的，很明显，Channel 的属性是相对持久的，而群的属性则是临时的，前者是可以是部门，可以是团队，可以是项目，可以是产品，可以是某种长期存在的职能（如：技术分享），而拉群则是相对来说临时起意的，有时候，同样的人群能被重复地拉出好几次，因为之前临时起意的事做完了，所以群就被人所遗忘了，后面再有事就再来。很明显，Channel 这种方式明显是有管理的属性的，而拉群则是没有管理的。

所以，在国内这种作坊式，野蛮粗放式的管理风格下，他们需要的就是想起一出是一出的 IM 工具，所以，拉群就是他们的工作习惯，因为没有科学的管理，所以没有章法，所以，他们不需要把工作内的信息结构化的工具。而国外则不然，国外的管理是精细化的，国外的公司还在重度使用 Email 的通讯方式，而 Email 是天生会给一个主题时行归类，而且 Email 天生不是碎片信息，所以，国外的 IM 需要跟 Email 竞争，因为像 Email 那样给邮件分类，把信息聚合在一个主题下的方式就能在 IM 上找到相关的影子。Channel 就是一个信息分类，相当于邮件分类，Slack 的 回复区和 Discord 的子区就像是把同一个主题信息时行聚合的功能。这明显是懂管理的人做的，而国内的拉群一看就是不懂管理的人干的，或者说是就是满足这些不懂管理的人的需求的。

企业文化

团队协作和团队工作最大的基石是信任，如果有了信任，没有工具都会很爽，如果没有信任，什么工具都没用。信任是一种企业文化，这种文化不仅包括同级间的，还包括上下级间的。但是，因为国内的管理跟不上，所以，就导致了各种不信任的文化，而需要在这里不信任的文化中进行协同工作，国内的 IM 软件就会开发出如下在国外的 IM 中完全没有的功能：

  • 监控员工。获取员工的工作时间以及工作位置。
  • 有详细的已读标注。这样会给对方要回复的压力。
  • 发出的信息不能修改，不能删除，非常有限地可撤回。

而国外的 IM 则是，发出的信息可以修改/删除，没有已读标准，也不会监控员工。这种时候，我总是会对工作在这种不信任文化中人感到可怜……如果大家需要靠逼迫的方式把对方拉来跟我一起协作，我们还工作个什么劲啊。

小结

所以，我们可以看到，畸形的企业管理和企业文化下，就会导致畸形的协同工具。最令人感到悲哀的是，有好多同学还觉得国内的钉钉非常之好，殊不知，你之所以感觉好用，是因为你所在的环境是如此的不堪。你看，人到了不同的环境就会有不同的认识，所以，找一个好一些的环境对一个人的成长有多重要。

给一些新入行的人的建议就是，一个环境对一个人的认知会有非常大的影响，找一个好的环境是非常重要，如果不知道什么 环境是好的，那就先从不使用钉钉为工作协同软件的公司开始吧……

什么是好的协同工具

我们从上面可以得到，协同的前提条件是你需要有一个基于信任的企业文化，还需要有有结构化思维的科学的管理思维。没有这两个东西，给你的团队再多的工具都不可能有真正好有协同的，大家就是装模作样罢了。

假设我们的管理和文化都没有问题，那下面我们来谈谈协同工具的事。

我个人觉得 IM 这种工具包括会议都不是一种好的协同工具，因为这些工具都无法把信息做到真正的结构化和准确化，用 IM 或是开会上的信息大多都是碎片化严重，而且没有经过深度思考或是准备的，基本都是即兴出来的东西，不靠谱的概率非常大。

找人交流和开会不是有个话题就好的，还需要一个可以讨论的“议案”。在 Amazon 里开会，会前，组织方会把要讨论的方案打印出来给大家看，这个方案是深思过的，是验证过的，是有数据和证据或是引用支撑的，会议开始后，10 -15分钟是没有人说话的，大家都在看文档，然后就开始直接讨论或发表意见，支持还是不支持，还是有条件支持……会议效率就会很高。

但是这个议案其实是可以由大家一起来完成的，所以，连打印或是开会都不需要。试想一下，使用像 Google Doc 这样的协同文档工具，把大家拉到同一个文档里直接创作，不香吗？我在前段时间，在公网上组织大家来帮我完成一个《非常时期的囤货手册》，这篇文章的形成有数百个网友的加持，而我就是在做一个主编的工作，这种工作是 IM 工具无法完成的事。与之类似的协同工具还有大家一起写代码的 Github，大家一起做设计的 Figma……这样创作类的协同工具非常多。另外，好多这些工具都能实时展示别人的创作过程，这个简直是太爽了，你可以通过观看他人创作过程，学习到很多他人的思路和想法，这个在没有协同工具的时代是很难想像的。

好的协同工具是可以互相促进互相激励的，就像一个足球队一样，当你看到你的队友在勇敢地争抢，拼命地奔跑，你也会被感染到的。

所以，好的协同就是能够跟一帮志同道合，有共同目标，有想法，有能力的人一起做个什么事。所以，在我心中我最喜欢的协同工具从来都是创作类的，不是管理类的，更不是聊天类的。管理和聊天的协同软件会让你产生一种有产出的假象，但其实不同，这种工具无论做的有多好，都是支持性的工具，不是产出类的工具，不会提升生产力的。

另外，在创作类的协同工具上如果有一些智能小帮手，如：Github 发布的 Copilot。那简直是让人爽翻天了，所以，真正能提升生产力的工具都是在内容上帮得到你的。

结束语

我其实并不喜欢今天所有的 IM 工具，因为我觉得信息不是结构化的，信息是有因果关系和上下文的，是结构化的，是多维度的，不是今天这种线性的方式，我们想像一下“脑图”或是知识图，或是 wikipedia 的网关的关联，我们可能就能想像得到一个更好的 IM 应该是什么 样的……

协同工作的想像空间实在是太大了，我觉得所有的桌面端的软件都会被协作版的重写，虽然，这种协作软件需要有网络的加持，但是协作软件的魅力和诱惑力实在的太大了，让人无法不从……

未来的企业，那些管理类的工具一定会被边缘化的，聊天类的会被打成一个通知中心，而创作类的会大放异彩，让大家直接在要干的事上进行沟通、交互和分享。

（全文完）

原文链接：聊聊团队协同和协同工具

发表于   |   分类于

问题：

在PHP中使用fsockopen实现异步请求时，发现请求有发出，但是响应不是200而是499，导致被请求脚本并未按要求执行。

这个问题的起源与解决方案。

php中怎么使用fsockopen实现异步请求，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

php执行一段程序，有可能几毫秒就执行完毕，也有可能耗时较长。

例如，用户下单这个事件，如果调用了些第三方服务进行发邮件、短信、推送等通知，可能导致前端一直在等待。

而有的时候，我们并不关心这些耗时脚本的返回结果，只要执行就行了。这时候就需要采用异步的方式执行。

众所周知，PHP没有直接支持多线程这种东西。我们可以采用折衷的方式实现。这里主要说的就是fsockopen。

通过fsockopen发送请求并忽略返回结果，程序可以马上返回。

示例代码：

$fp = fsockopen("www.example.com", 80, $errno, $errstr, 30);
if (!$fp) {
       echo "$errstr ($errno)<br />\n";
} else {
       $out = "GET /backend.php   HTTP/1.1\r\n";
    $out .= "Host: www.example.com\r\n";
    $out .= "Connection: Close\r\n\r\n";

    fwrite($fp, $out);
    /*忽略执行结果
    while (!feof($fp)) {
        echo fgets($fp, 128);
    }*/
       fclose($fp);
}

需要注意的是我们需要手动拼出header头信息。通过打开注释部分，可以查看请求返回结果，但这时候又变成同步的了，因为程序会等待返回结果才结束。

实际测试遇到的问题

实际测试的时候发现，不忽略执行结果，调试的时候每次都会成功发送sock请求；但忽略执行结果，经常看到没有成功发送sock请求。查看nginx日志，发现很多状态码为499的请求。

后来找到了原因：

fwrite之后马上执行fclose，nginx会直接返回499，不会把请求转发给php处理。

客户端主动端口请求连接时，NGINX 不会将该请求代理给上游服务（FastCGI PHP 进程），这个时候 access log 中会以 499 记录这个请求。

解决方案：

1)nginx.conf增加配置

#忽略客户端中断
fastcgi_ignore_client_abort on;

2)fwrite之后使用usleep函数休眠20毫秒：

usleep(20000);

后来测试就没有发现失败的情况了。

相关链接：

参考文章1

参考文章2

参考文章3

发表于   |   分类于

在线扩容，是在磁盘不够用时，直接不停机不停服的情况下扩展磁盘空间。

非常好用。不过，需要系统支持。

一、扩容概述（官网说明）

https://help.aliyun.com/document_detail/35095.html

这个是是前提，包括：扩容场景、系统盘扩容上限、数据盘扩容上限、扩容计费等。
是在进行技术操作前的一些须知与准备工作。
确认在用的ECS实例与云盘支持“在线扩容”之后，才能进行后续的操作。

二、在线扩容云盘（Linux系统）（官网说明）

https://help.aliyun.com/document_detail/113316.htm

这个是具体的执行Linux系统的云盘“在线扩容”的详细步骤。
包括：前提条件，背景信息，操作步骤，支持在线扩容的操作系统，常见问题，其他扩容场景。

其中【操作步骤】又包括：
步骤一：创建快照；
步骤二：在控制台扩容云盘容量；
步骤三：查看云盘分区情况；
步骤四：扩容分区；
步骤五：扩容文件系统。

三、实际操作步骤【关键】（实际操作）

1、例子：扩容/dev/vda 由80G扩容到160G

在阿里云上进行在线扩容操作 ：

存储与快照 > 云盘页面选择云盘后，单击云盘扩容，选中在线扩容，并设置扩容后容量
Linux上执行命令

2、查看磁盘信息：fdisk -l

3、查看要扩容的分区的文件系统类型：df -hT

4、安装growpart工具
CentOS 7及以上版本：运行命令 yum install cloud-utils-growpart
Debian 9及以上版本、Ubuntu14及以上版本：运行命令 apt install -y cloud-guest-utils

5、运行命令，扩容分区：growpart /dev/vda 1（1前面有空格）

6、扩容文件系统：resize2fs /dev/vda1 （这里1前面没有空格）

7、查看是否扩容成功：df -hT

四、几个问题的解决

1、问题出现在上述详细步骤的“4、安装growpart工具”这一步，由于CentOS8不再被支持，而造成了yum源错误的问题。

错误提示为：

Error:Failed to download metadata for repo 'AppStream'

解决方案：

由于CentOS 8操作系统版本结束了生命周期而导致YUM源出错的问题：
https://help.aliyun.com/document_detail/405635.htm

发表于   |   分类于

苹果开发者账号的类型与发布方式

开发者账号类型

苹果开发者账号有个人版（99美金/年），公司版（99美金/年）和企业版（299美金/年）三种。

99美金属于标准计划；

标准计划还分为标准个人计划和标准公司计划，区别是：如登记为标准个人计划（个人开发者），则应用程序商店中的“seller name”将显示您个人的名称，如登记为标准公司计划（公司开发者）则应用程序商店中的“seller name”将显示公司的法定名称，同时您可以把其他会员添加到开发团队。

299美金属于企业计划。

一、99美金个人开发者账号：

1、开发者能够自由地创造iPhone / iPod Touch/ iPad的商业应用，并且能够发布他们的应用程序（免费或收费）在App Store上

2、App Store中的“seller name”将显示您个人的名称

3、每年可以设置100台测试机做开发及测试用

4、不允许开发人员创建一个团队

二、99美金公司开发者账号：

1、开发者能够自由地创造iPhone / iPod Touch/ iPad的商业应用，并且能够发布他们的应用程序（免费或收费）在App Store上

2、App Store中的“seller name”将显示公司的法定名称

3、每年可以设置100台测试机做开发及测试用

4、允许开发人员创建一个团队，可以把其他成员添加到开发团队

5、公司应在邓白氏注册并拥有有效的DUNS号码

删除Provisioning Profiles,appid,发布证书的后果:

如果app已经上线发布至App Store了，那么此时删除开发者账号的证书和描述文件对已经上线的app来说没什么大的影响，app可以正常使用。如果app在开发阶段，此时删除证书和描述文件，应该是不行的，上架估计都不会通过。

没有实际测试过

三、299美金企业开发者账号：

1、不允许该企业在App Store出售他们的应用程序

2、所开发的应用只能发给其雇员作内部使用

3、UDID数量不限制

4、允许开发人员创建一个团队，团队成员添加到他们的帐户

5、公司应在邓白氏注册并拥有有效的DUNS号码（面向拥有500雇员以上的公司）

删除Provisioning Profiles,appid,发布证书的后果:

所有已经安装的app不能打开，会闪退，在线itms-services协议不能安装

所以企业应用安装到手机上则需要开发者账号上的证书和描述文件来通过手机的验证，此时删除证书和描述文件，则无法通过手机的验证，app也就无法使用了。此时下载的话则无法进行安装，会显示Unable to download app，选择Done或Retry。

但是我测试了删除了appid和发布证书,app没有任何影响,放在fir还是能下载安装,不知道是不是删除时间太短(删除3天了 还是能用)

发布方式（4种）：

一、苹果应用商店发布（App Store）

二、苹果应用商店批量购买发布（Volume Purchase Program）

三、In-House企业应用发布：

1、不能提交到App Store

2、发布应用的具体内容不需要苹果官方审核

3、安装设备的数量没有任何限制

4、把程序放在网站中，提供给最终用户一个链接，他们就能够直接下载并自动安装了

四、Ad Hoc应用发布方式

1、不能提交到App Store

2、不需要经过苹果的评审，

3、限制每个应用不能发布到超过100个设备上

4、把程序放在网站中，提供给最终用户一个链接，他们就能够直接下载并自动安装了

（全文完）

原文链接

发表于   |   分类于

linux查找并移动文件

原文参考

find . -name '10-*.dat' -exec mv {} ../ \;

这里：

=> -exec mv {} /mnt/mp3 \; - 运行mv命令。

=> {} - 字符 ‘{}’ 代表find到的所有内容。

=>../表示当前用户目录的上一级目录

=> \; - 结束 /bin/mv 命令。

亲测可用

移动搜索匹配条件的文件到指定目录

查找并移动

find . -name 'faverifyimage_*.png' -exec mv {} ../ \;

只查找

find . -name 'faverifyimage_*.png';

以下命令是：

移动【当前目录下（不含子目录）】【以faverifyimage_开头的图片文件】到【faverifyimgbk】目录。

说明：扩展了“不含子目录”这个条件，只操作“当前目录”；同时，继续执行了其他格式的图片文件。

find . -maxdepth 1 -name 'faverifyimage_*.png' -exec mv {} ./faverifyimgbk \;
find . -maxdepth 1 -name 'faverifyimage_*.jpg' -exec mv {} ./faverifyimgbk \;
find . -maxdepth 1 -name 'faverifyimage_*.jpeg' -exec mv {} ./faverifyimgbk \;

<<<<<<< HEAD

之后好久没更新。

因为github在2021年08月13日之后停止了账号密码的登录机制。

1005c8acaffa52e5d81b9fff2815f3f1febb6fdc 　　

发表于   |   分类于

一、前方有坑

php在使用加减乘除等运算符计算浮点数的时候，经常会出现意想不到的结果，特别是关于财务数据方面的计算，给不少工程师惹了很多的麻烦。比如今天工作终于到的一个案例：

$a = 2586;

$b = 2585.98;

var_dump($a-$b);

期望的结果是：float(0.02)

实际结果：

float(0.019999999999982)

人生有坑，处处提防

二、防坑攻略：

1、通过乘100的方式转化为整数加减，然后在除以100转化回来……

2、使用number_format转化成字符串，然后在使用（float）强转回来……

3、php提供了高精度计算的函数库，实际上就是为了解决这个浮点数计算问题而生的。

主要函数有：

bcadd — 将两个高精度数字相加

bccomp — 比较两个高精度数字，返回-1, 0, 1

bcdiv — 将两个高精度数字相除

bcmod — 求高精度数字余数

bcmul — 将两个高精度数字相乘

bcpow — 求高精度数字乘方

bcpowmod — 求高精度数字乘方求模，数论里非常常用

bcscale — 配置默认小数点位数，相当于就是Linux bc中的”scale=”

bcsqrt — 求高精度数字平方根

bcsub — 将两个高精度数字相减

前两种流氓的办法就不测试了，使用bcsub测试第三种两数相减的例子，

先看bcsub用法（来自官网）

string bcsub ( string $left_operand , string $right_operand [, int $scale = int ] )

参数

left_operand 字符串类型的左操作数.

right_operand 字符串类型的右操作数.

scale 此可选参数用于设置结果中小数点后的小数位数。也可通过使用 bcscale() 来设置全局默认的小数位数，用于所有函数。

返回值 返回减法之后结果为字符串类型.

测试代码：

var_dump(bcsub($a,$b,2));

结果

0.02

其他的函数请参考PHP官方网站

三、为啥有坑：

php的bug?不是，这是所有语言基本上都会遇到的问题，所以基本上大部分语言都提供了精准计算的类库或函数库。

要搞明白这个原因, 首先我们要知道浮点数的表示(IEEE 754):

浮点数, 以64位的长度(双精度)为例, 会采用1位符号位(E), 11指数位(Q), 52位尾数(M)表示(一共64位).

符号位：最高位表示数据的正负，0表示正数，1表示负数。

指数位：表示数据以2为底的幂，指数采用偏移码表示

尾数：表示数据小数点后的有效数字.

这里的关键点就在于, 小数在二进制的表示, 小数如何转化为二进制呢？

算法是乘以2直到没有了小数为止。这里举个例子，0.9表示成二进制数

0.9*2=1.8 取整数部分 1

0.8(1.8的小数部分)*2=1.6 取整数部分 1

0.6*2=1.2 取整数部分 1

0.2*2=0.4 取整数部分 0

0.4*2=0.8 取整数部分 0

0.8*2=1.6 取整数部分 1

0.6*2=1.2 取整数部分 0

………

0.9二进制表示为(从上往下): 1100100100100……

注意：上面的计算过程循环了，也就是说*2永远不可能消灭小数部分，这样算法将无限下去。很显然，小数的二进制表示有时是不可能精确的 。其实道理很简单，十进制系统中能不能准确表示出1/3呢？同样二进制系统也无法准确表示1/10。这也就解释了为什么浮点型减法出现了”减不尽”的精度丢失问题。

换句话说：我们看到十进制小数，在计算机内存储的不是一个精确的数字，也不可能精确。所以在数字加减乘除后出现意想不到的结果。

四、防坑提示

基于以上原因，所以永远不要相信浮点数结果精确到了最后一位，也永远不要比较两个浮点数是否相等。如果确实需要更高的精度，应该使用任意精度数学函数或者 gmp 函数。

原文链接：https://www.cnblogs.com/kenshinobiy/p/10797902.html

发表于   |   分类于

实际使用的系统：CentOS 6.5

1、方法一 CURL

下载composer.phar文件

curl -sS https://getcomposer.org/installer | php

将composer.phar移动到环境变量中并且更名为composer

mv composer.phar  /usr/local/bin/composer

使用国内镜像

composer config -g repo.packagist composer https://packagist.phpcomposer.com

2、方法二 直接下载composer

下载

wget https://getcomposer.org/composer.phar

安装

cp composer.phar /usr/local/bin/composer
chmod u+x /usr/local/bin/composer

测试

composer –help

3、安装的时候用root用户，使用的时候用非root用户

否则，如果使用root运行会有提示：

运行composer出现do not run Composer as root/super user!

解决方法：

第1步 创建非root的新用户

[root@centos ~]# useradd newname
[root@centos ~]# passwd  newname

第2步 切换为新用户账户

[root@centos ~]# su newname

切换到新用户后 , 即可执行 原来的操作 , 顺利完成 composer 指令。

【注意】同时，需要使用root用户将 /usr/local/bin/composer 设置为755，否则其他用户无法执行该命令。

【本人亲测，使用上述方法2和步骤3成功安装了Composer 2.1-dev版。方法1未测试。】