背景

公司官网项目，通过两层 nginx 请求数据，发现重定向后地址带上了端口，如：
https://wwww.kch8.top:18000/test?name=huang

项目架构

第一层 nginx

第一层通过代理转发到第二层

1
2
3
4
5
6
7
8
9
10
11

server
{
    listen 80;
    listen 443 ssl http2;
    server_name www.kch8.top kch8.top;

    location /
    {
        proxy_pass http://www.kch8.top:8081
    }
}

第二层 nginx

第二层是 vue 项目，采用 history 模式，故用 try_files 解决浏览器刷新 404 问题

1
2
3
4
5
6
7
8
9
10
11
12

server
{
    listen 8081;
    server_name www.kch8.top kch8.top;
    index index.php index.html index.htm default.php default.htm default.html;
    root /data/web/www.kch8.top/dist;

    location /
    {
        try_files $uri $uri/ /index.html;
    }
}

问题分析

301 问题

第一层只做转发，一般没有问题；往下排查，第二层可能性最大；try_files 引起的一次重定向

try_files 说明

try_files 指令后面可带多个 uri，进行多次匹配，直到找到相关资源为止。
针对上面try_files $uri $uri/ /index.html，
请求的 url 为：https://www.kch8.top/product/detail?productId=100000，
站点部署结构为:

1
2
3
4
5

.
├── index.html
└── product
    └── detail
        └── index.html

上述请求 uri 为/product/detail，根据 try_files 配置，匹配如下：
a. $uri进行匹配，资源文件不存在；
b. 向下$uri/匹配，发现 detail 文件夹存在，则返回 301 地址https://www.kch8.top/product/detail/?productId=100000(detail 文件下存在默认 index.html 文件，并没有匹配 index.html 内容，这和 location 下 uri 匹配有区别)
c. b 步骤不匹配，则找根目录下 index.html，最后这个 uri 一定要存在，否则会报 404 错误；（最后这个匹配是内部重定向，而不是下发 301 或 302 这种）

重定向带端口问题

这个问题是由 try_files 产生了一次重定向，生成的 url 为https://www.kch8.top:8081/product/detail/?productId=100000
url 中域名是通过 server_name 获取；
url 中端口是通过 listen 获取；

解决方案

301 问题

根据站点，根目录文件层级，try_files 做出如下修改：

1

try_files $uri $uri/index.html /index.html

对第二个 uri，直接找目录下的 index.html 文件

重定向带端口问题

重定向 url 中的域名，可以通过server_name_in_redirect控制，默认开启，官方解释：

1

Enables or disables the use of the primary server name, specified by the server_name directive, in absolute redirects issued by nginx. When the use of the primary server name is disabled, the name from the “Host” request header field is used. If this field is not present, the IP address of the server is used.

重定向 url 中的端口，可以通过port_in_redirect控制，默认开启，官方解释：

1

Enables or disables specifying the port in absolute redirects issued by nginx.

关闭绝对重定向，可以通过absolute_redirect控制，默认开启，官方解释：

1

If disabled, redirects issued by nginx will be relative.

故将absolute_redirect设置为off，改为相对重定向，避免出现端口问题

参考资料

1. https://blog.csdn.net/weixin_44457062/article/details/125890694
2. http://nginx.org/en/docs/http/ngx_http_core_module.html#port_in_redirect

https://ayase.moe/2018/11/20/scroll-event/

https://tsejx.github.io/javascript-guidebook/object-oriented-programming/inheritance/prototype-chain/

https://segmentfault.com/a/1190000009247663

经常有粉丝童鞋咨询龙少，这个楼盘不是说卖完了吗，怎么系统还显示“期房待售”？买了新房，什么时候网签？这个月的成交数据，什么时间在系统显示网签？等等问题。

今天就来科普一下，新房网签需要几个步骤：已签认购书——已录入合同——已签合同——已备案。大多数童鞋都是按揭贷款，签完认购书后还需要银行审批贷款，审批通过后才录入合同，最后才网签的，一般周期都在 1-2 个月。

之前网签慢一点的都要半年一年，现在快了很多，但也需要 1-2 个月，所以我们看到的新房每月网签数据实际成交都是 1-2 月之前的数据。

线上签署购房合同和线上备案的具体流程如下：
1、线上选房成功后，冻结的意向金会转入开发商账户转为购房定金，并会在 i 深圳签署认购书，之后系统状态会变成：已签认购书。（港澳台外籍人士，无法在 i 深圳签署认购书、购房合同，需要到开发商线下签署）

2、按开发商的时间约定，携带相关证件和按揭所需资料办理购房手续，一般是先签按揭手续，之后同步缴纳剩余首期款，签署购房相关补充协议。

3、等银行出了贷款承诺函，开发商会按以下流程，完成备案手续。
1）首先向深圳市房地产信息平台系统提交相关资料，核实购房资格，通过后，购房者会收到深圳政务短信平台的短信，内容为申请人的购房资格已核验通过；
2）接着开发商会安排录入购房合同，系统状态会变为：已录入合同；
3）购房合同出来以后，会通知购房者在 i 深圳签署购房合同。之后系统状态会变成：已签合同；
4）完成最后的备案手续后，系统状态会变成：已备案；

4、备案完成后，会通知一次性付款购房者去开发商处领取购房合同；按揭付款的购房者，购房合同会给到银行，银行安排按揭放款。

看完这篇，你清楚深圳新房网签流程了吗？

iOS 支持 der 编码的证书

证书内容格式 pem der

pem: 十六进制编码
openssl x509 -in a.cer -text -noout

der: 二进制编码
openssl x509 -in a.cer -inform der -text -noout

pem 转 der 格式

openssl x509 -in a.cer -outform der -out cer.der

通过 chrome 导出证书

通过上面的步骤1-4，导出cer证书，并通过上述“确定证书格式”生成合适证书

NAME

openssl_user_macros, OPENSSL_API_COMPAT, OPENSSL_NO_DEPRECATED - User defined macros

DESCRIPTION

User defined macros allow the programmer to control certain aspects of what is exposed by the OpenSSL headers.

NOTE: to be effective, a user defined macro must be defined before including any header file that depends on it, either in the compilation command (cc -DMACRO=value) or by defining the macro in source before including any headers.

Other manual pages may refer to this page when declarations depend on user defined macros.

The macros

OPENSSL_API_COMPAT
The value is a version number, given in one of the following two forms:

0xMNNFF000L
This is the form supported for all versions up to 1.1.x, where M represents the major number, NN represents the minor number, and FF represents the fix number, as a hexadecimal number. For version 1.1.0, that’s 0x10100000L.

Any version number may be given, but these numbers are the current known major deprecation points, making them the most meaningful:

0x00908000L (version 0.9.8)
0x10000000L (version 1.0.0)
0x10100000L (version 1.1.0)
For convenience, higher numbers are accepted as well, as long as feasible. For example, 0x60000000L will work as expected. However, it is recommended to start using the second form instead:

mmnnpp
This form is a simple decimal number calculated with this formula:

major _ 10000 + minor _ 100 + patch

where major, minor and patch are the desired major, minor and patch components of the version number. For example:

30000 corresponds to version 3.0.0
10002 corresponds to version 1.0.2
420101 corresponds to version 42.1.1
If OPENSSL_API_COMPAT is undefined, this default value is used in its place: 30300

OPENSSL_NO_DEPRECATED
If this macro is defined, all deprecated public symbols in all OpenSSL versions up to and including the version given by OPENSSL_API_COMPAT (or the default value given above, when OPENSSL_API_COMPAT isn’t defined) will be hidden.

https://www.openssl.org/docs/manmaster/man7/OPENSSL_API_COMPAT.html

https://www.cnblogs.com/chengd/p/7803664.html

指定 openssl 版本

bind.gyp 文件中，增加

1
2
3
4

"defines": [
        "OPENSSL_API_COMPAT=0x10100001L",
        "OPENSSL_CONFIGURED_API=30000",
      ]

指定 libcurl 版本

LIBCURL_RELEASE=7.78.0 PUBLISH_BINARY="false" sh ./scripts/ci/build.sh