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 不受影响呢？...

NGINX 和 PHP 是一对很好的搭档，那么 nginx 是如何与 php 结合实现 对外的网络访问呢？ 首先 NGINX 作为一个 web 服务器只能处理静态请求，关于动态请求，是通过 CGI 具备的动态请求能力。 NGINX会将动态请求交给 CGI 处理，CGI 将处理结果返回给 NGINX，NGINX 再将请求的结果返给给浏览器 CGI 的作用 当在浏览器中输入一个动态地址时，如 /index.php， 通过 DNS 解析，最终请求会到 web 服务器上，当 NGINX 发现请求时动态请求。会交给 PHP 解释器处理此请求，那再给 NGINX 需要给 PHP 解释器传输哪些数据呢？请求地址，请求方法，请求参数这些东西总归是要有的，但是也不能仅仅是这些，像请求头和 cookie … 也应该包含其中。 那么怎么确定到底该传输哪些数据，以及以什么样的格式传输呢？ CGI 就是解决这个问题而生的。 CGI 全程通用网关接口 (英语：Common Gateway Interface，CGI) 是为提供网络服务而执行控制台应用的程序，提供于服务器上实现动态网页的通用协议。通常情况下，一次请求对应一个CGI 脚本的执行，生成一个 HTML。 CGI 接口规定了 nginx 与动态解释器之前传输数据的参数和格式，为 nginx 和脚本解释器之间建立起了一个桥梁。 CGI 的存在使 web 服务器与动态语言之间的关系进行了解耦，使得 web 服务器可以处理的动态请求，但是 CGI 的设计使通过进程的方式来处理动态请求的，当动态请求过来后，CGI 会起一个进程进行处理，请求结束后关闭进程. 进程的频繁创建和销毁是存在开销的，这也就导致了 CGI 很难应对高并发的场景, FastCGI 的出现解决了这个问题....