分类 工作备忘 下的文章

项目有存储图像、需要。单靠云主机的弱鸡带宽肯定是撑不住的，所以考虑用对象储存服务。主打弹性成本带宽也管饱，还有一些额外的好处，下文説。下文流水账记录快速部署到可用的状态。其实官方文档已经有足够的信息只是版本有点杂，我需要多出相互比对测试了一番。所以下面这个也可以说是速通教程。

- 阅读剩余部分 -

前端看没有报错，但file_get_contents()返回了 null， 看服务端日志才发现这个提示。

以前也遇到过，备忘一下。当然改用 curl 也是不错的选择。

//$json_token = file_get_contents($url_accesstoken); //ssl报错
//修改方案，构造一个context参数，不验证ssl
$context = stream_context_create([
    'ssl' => [
        'verify_peer'      => false,
        'verify_peer_name' => false
        ]
]);
$json_token = file_get_contents($url_accesstoken,false,$context); //忽略报错，正确返回内容

参考来源：https://qiita.com/mindwood/items/fd23ddcb94fb4eefa99c

因为阿里云和腾讯云调整了免费SSL证书政策从1年有效期改成90日。寻找替代方案，看到cloudflare提供15年的证书，但条件是要使用它们家的DNS/CDN服务。验证是在dns过程中接管的。

跟着别人分享的教程一步步操作下来，证书是申请好配置到位了。同时也出现了标题的问题。请求PHP的响应正确，但如果是静态资源 例如加载 js html css png之类浏览器就会报错 301 提示重定向次数过多。

网上搜了一圈基本在说的是 http强制绑定https，当用户访问http时自动重定向到https的情况，设置在nginx conf 的http的 server{} 部分。这显然和我的项目情况不同，我只配置了443 ssl服务。我并不需要约束http。也没有往nginx的方向去想。

以为是cloudflare这种形式的ssl的问题，一直在CF的设置上去研究。

最后实在被搞烦了...决定弃坑，部署个脚本在服务端每90日自动续签ssl。

发现还是一样的问题，php正常打开，html 提示重定向次数过多

脑子被轰了...回头检查 nginx 的 vhost 配置文件。在 443 server{} 的最底部发现这段东西


location / {
    return 301 https://$host$request_uri;
}

WTF?

搞什么飞机... 为什么lnmp会生成这样奇怪的配置。已经是443了还自己跳转给自己

注释之后...问题消除

项目中用到微信支付，但公众号上已有一个第三方的项目配置过v2版，报文用XML格式的那个旧的支付密钥。没找到接口维护人拿不到旧密钥。

为了不影响已有产品，改写V3接口。本觉得V3用JSON应该是收到拿来，数据方便编辑维护多了。没想到还是埋着不少坑。

腾讯官方的技术支持已经不指望也不想吐槽了，概括四字：依托答辩

没多想，找到文档按部就班开始写了

https://pay.weixin.qq.com/wiki/doc/apiv3/apis/chapter3_1_1.shtml

一开始还挺顺的，觉得接口参数还简化了不少。直到测试提交，下单生成 prepay_id

大意了，来活了。

报错。

{"code":"INVALID_REQUEST","message":"Http头缺少Accept或User-Agent"}

哦，网上搜一下，行~按你要求构造个header补上呗
curl请求的header，定义上

$headers = [
        'Accept: application/json',
        'Content-Type: application/json',
        ];  
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

还是错！

{"code":"SIGN_ERROR","message":"Http头Authorization值格式错误，请参考《微信支付商户REST API签名规则》"}

牛B！都是对header的要求，就不能说明放一块，错误提示放一起，非得像有关部门一样踢一脚说半句。

随即发现这 Authorization 坑有点深.. 过程略过.. 大概知道就是把 V2的签名部分挪到了header里
构造数据、签名、加密、编码一通操作下来
报错

{
  "code":"SIGN_ERROR",
  "detail":{
    "detail":{
      "issue":"sign not match"
    },
    "field":"signature",
    ...
  "message":"Authorization不合法"}

忽略掉过程 N个小时 各种无意义的试错

官方文档牛啤！给的演示代码省略了那么多关键步骤！让开发者自己脑补和发掘隐藏BUG！

要自己解决证书文件换行问题；

openssl_sign(): supplied key param cannot be coerced into a private key

要在文档角落找到获得 serial_no 的方法；
要自己猜接口的数据长度单位是字还是字节；

卡在最后一个错误节点，终于错误提示不在变动，仅仅是告知

{"code":"SIGN_ERROR","detail":{"detail":{"issue":"sign not match"} ..."message":"签名错误，请检查后再试"}

像玩悬赏解谜游戏一样，找到隐藏的链接 而且我们还提供签名/验签/加密/解密工具（点击下载）
验证自己生成的签名和用工具验证的签名，我™直接傻了，没有不同啊？！

QQ截图20230721013527.png

好家伙，卡在那发呆...又回去检查每个步骤，逐行逐字的看。甚至声明了顺序无关的地方都处女座一样把参数按顺序重排，还是错，直到我看见..

QQ截图20230721014034.png

又看了看自己的签名数据

QQ截图20230721013857.png

我把 post 改成大写 POST 试试...

我草你大爷的！！！大写这么重要的事情怎么不早说？！

大活来了，从 1.35.* 升级到 8.*.*

一边操作一边备忘

概述

参考 247大佬的文章，做前置准备(链接在文末)，主要是安装一些新的依赖，以及关键的两个

ghc要更新到 8.10.7 （在1.35.7版本已经升级满足）
cabal 需要更新到 3.8.1.0 （比较矛盾的一点，要升级到这个版本，需要ghc升级到 9.2.8）

因此，一个奇怪的顺序是
1 需要先升级ghc到 9.2.8，
2 然后升级cabal到 3.8.1.0
3 再次设置默认版本ghc为 8.10.7（降级）

最简单最理想的情况下，如无意外。做完前置准备。用官方已经编译好的bin文件直接替换就升级完了
需要自行编译的要进一步获取源码和配置

cntools是否需要配套更新待确认。

最优先目标是先把节点运行平顺过渡上 8.* 版本, stakepool 的管理工具功能的验证可以滞后。






- 阅读剩余部分 -

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 24