web开发

PageSpy 是货拉拉开发的一款可以远程调试前端页面、小程序的工具。在调试端，你可以像操作 chrome 控制台一样很方便的查看 console 输出、网络请求、本地存储、SEESION/COOKIE。基本上 PageSpy 的调试端相当于一个 chrome 控制台，只不过他可以让你本地调试任何远程的客户端。 关于 PageSpy 在前端远程调试利器 PageSpy 更详细的介绍。 理论上 PageSpy 能力还是很强大的，为了保证方案更好的落地，我们希望在解决我们主要痛点的同时，接入成本要尽可能的简单。 我们准备用 PageSpy 做线上偶发性异常调试,在前端开发中经常会遇到自己测试没问题，但是客户那边有问题。这种问题调试起来往往都会比较繁琐。 通过 PageSpy 可以轻松的看到客户那边的报错信息，可以更方便有效的进行问题的定位。 为了方便管理和排查，我们做了如下参数约定： # title 作为调试端房间列表显示的标识 # project 为所接入项目的标识 new PageSpy({title: 'user01', project: 'test'}) 此外 PageSpy 的引入也是动态加载的，我们在页面的某个位置加入触发机制，当客户出现问题时，我们会告知客户触发加载 PageSpy 复现 Bug， 这时我们的前端工程师就可以在房间列表中查看客户那边的具体报错，辅助前端工程师解决问题。 我们可以看到 PageSpy 还有日志回放的功能。如果引入这个能力，客户只需要加载出 PageSpy ，并触发 Bug 点击上传日志即可。前端工程师可以根据客户上传的日志，通过日志回放看到具体的报错。这样就把问题的反馈变成了异步的形式，无需前端工程师和客户都在线。 PageSpy 日志回放，目前只支持 WEB 端，我们业务主要以小程序为主，且可以比较方便的找到客户帮忙排查问题，因此并没有使用这个功能。

Casbin 是一个强大的、高效的开源访问控制框架，其权限管理机制支持多种访问控制模型。 通俗来讲就是一个权限管理的框架，把常见的权限管理集成在框架中，使用者只需要根据框架规范就可以很方便的实现相应的权限控制。 Casbin 支持的权限管理如下： ACL (Access Control List, 访问控制列表) 具有 超级用户 的 ACL 没有用户的 ACL: 对于没有身份验证或用户登录的系统尤其有用。 没有资源的 ACL: 某些场景可能只针对资源的类型, 而不是单个资源, 诸如 write-article , read-log 等权限。 它不控制对特定文章或日志的访问。 RBAC (基于角色的访问控制) 支持资源角色的RBAC: 用户和资源可以同时具有角色 (或组)。 支持域/租户的RBAC: 用户可以为不同的域/租户设置不同的角色集。 ABAC (基于属性的访问控制): 支持利用 resource.Owner 这种语法糖获取元素的属性。 RESTful: 支持路径, 如 /res/* , /res/: id 和 HTTP 方法, 如 GET , POST , PUT , DELETE 拒绝优先: 支持允许和拒绝授权, 拒绝优先于允许。 优先级: 策略规则按照先后次序确定优先级，类似于防火墙规则。 Model 概念 Model 相当于框架的配置文件，如我想在系统里有可能实现 是ALC 或者 RBAC ，应该如何告诉 Casbin 框架，我实现的是那种类型的权限控制呢?...

Nginx、CGI、FastCGI、php-fpm关系，介绍了 NGINX PHP-FPM FastCGI 之间的关系。 本问介绍一下 NGINX 与 PHP-FPM 是如何进行通讯的，NGINX 是如何将请求转发到 PHP-FPM，PHP-FPM 有事如何知道该区找哪个脚本执行相应的代码逻辑。 建立连接 NGINX 通过 fastcgi_pass 与 PHP-FPM 建立连接，fastcgi_pass 有两种方式进行配置 通过 TCP 连接 fastcgi_pass 127.0.0.1:9000; 优势： 将 PHP-FPM 与 NGINX 进行解耦，可以动态的扩展 PHP-FPM 的服务数量 劣势： 由于将服务暴露到外网，会带来一些安全相关的风险 通过 UNIX socket 连接 fastcgi_pass unix:/var/run/php-fpm.sock; 优势： 进程间通讯，效率更高 劣势 NGINX 和 PHP-FPM 必须在同一系统环境内 两种建立连接的方式都需要 PHP-FPM 配置进行配合，如果 NGINX 采用 TCP 连接，则 PHP-FPM 也需要进行 TCP 的监听，反之亦然。 传递参数 PHP 在处理业务的时候需要一些参数比如：用户的 quey 和 请求 URL…，这些参数 NGINX 是如何传递给 PHP-FPM 的呢？...

TLS 介绍 TLS (和 SSL) 协议位于应用程序协议层和 TCP/IP 层之间，可以在其中保护应用程序数据并将其发送到传输层。 由于协议在应用程序层和传输层之间工作，因此 TLS 和 SSL 可以支持多个应用程序层协议。 TLS 和 SSL 假定使用面向连接的传输（通常为 TCP）， 可以预防如下风险： 消息篡改 消息拦截 消息伪造 TLS 握手 介绍 TLS 整个握手流程如下图所示 客户端请求(clinet hello) 这个阶段主要发送信息如下： 客户端支持的 TLS 版本号 客户端随机数Random 客户端支持的加密方法 客户端支持的压缩算法 服务端响应（server hello） 服务端支持的 TLS 版本号 服务端随机数Random 服务端支持的加密方法 服务端支持的压缩算法 服务端证书发送 服务端发送 server hello 后会发送证书，通常他们俩者在同一个网络包中，即同一个 TLS 记录层消息中。 证书验证（可选） 客户端拿到服务端证书，到证书办法机构的服务器（OCSP responder）验证证书是否可用 Client Key exchange 在此阶段客户端也会生成一个随机数，加上 clinet hello, server hello 生成的随机数一共三个随机数 作为 pre-master，发送给服务器，服务器端收到pre-master算出main master。而客户端当然也能自己通过pre-master算出main master。如此以来双方就算出了对称密钥。 客户端 finished 一个 Finished 消息一直会在一个 change cipher spec 消息后立即发送，以证明密钥交换和认证过程是成功的。一个 change cipher spec 消息必须在其它握手消息和结束消息之间被接收。...

问题分析 近期系统出现了部分 IOS 进入 H5 页面很慢的情况，而 Android 进入却正常。 在排除调程序和网络的问题后，最终把问题定位到 SSL 证书上。要想了解整个问题所在，需要从 TLS 协议开始说起 TLS 握手流程如下图所示 问题就出在客户验证证书这里，这里验证证书是通过 在线证书状态协议（OCSP），进行验证的。OCSP 验证原理也比较简单，就是拿证书信息到证书颁发机构的 OCSP 服务器做校验。 由于我们使用的是国外机构颁发的证书，因此验证证书的服务器也在国外，由于国内网络环境受限的因素，验证服务器无法访问，从而导致整个网站的访问卡在了证书校验这一步，无法正常的完成 TLS 握手。 找到了原因解决的方法也就迎刃而解了，我们把站点证书换成了国内机构颁发的，成功的解决了问题。 问题验证 在苹果官网找到了如下说明，佐证了上述猜想 对 TLS 证书信任状态的评估依照既定的行业标准（如 RFC 5280 所列）执行，且整合了新出现的标准，如 RFC 6962（证书透明度）。在 iOS 11 或更高版本以及 macOS 10.13 或更高版本中，Apple 设备会随撤销及受限证书的当前列表来进行定期更新。该列表由 Apple 信任的每个内建根证书颁发机构及其从属的 CA 签发者所发布的证书撤销清单 (CRL) 聚合而成，列表还可能根据 Apple 的要求酌情包括其他限制。每当使用网络 API 函数进行安全连接时都会使用此信息。如果需要单独列出的 CA 撤销证书太多，信任评估可能需要在线证书状态响应 (OCSP)，否则将无法通过信任评估。 其他一些症状 症状1 IOS 有的进入速度很快，有的进入很慢 出现上述问题的原因是：验证服务器一般都是通过 CDN 分发的，有可能部分 IP 未被限制 症状2 IOS 进入慢的用户，更换网络环境可以更快的进入。 运营商的限制策略不同，导致更换网络提供商后有可能解决问题。 一些疑问 问题出现的时候 Android 并未收到影响，一直进入速度都很快，如果说验证证书的服务器出现问题，为什么 Android 不受影响呢？...