一次隐蔽到极致的WordPress/CloudPanel SEO劫持排雷记录

背景 某天在 Google Search Console 中收到提示:Alternative page with proper canonical tag 在GSC点开链接后发现一个异常现象: 关键特征 感谢有GPT帮助理清思路,我做了如下测试 这已经明确指向:服务器级 cloaking(搜索引擎定向劫持) 排雷顺序 Step 1:用curl直接验证是否是服务器级跳转 此处看到的并不是我自己网站的内容,而是陌生网站。至此说明是服务器层面的跳转! Step 2:立刻检查 PHP 全局auto_prepend_file(此处并没有发现问题) 如果输出不是 no value,而是类似: 说明是PHP层面的文件注入。这个场景的GPT推荐的,但是我这里并不是PHP层面注入,因此走向下一步。 Step 3:确认注入位置(CloudPanel 场景) 根据GPT建议我继续筛查php fpm的注入 此时看到这样的内容: 然后我把base64进行解密,看到: 这是典型的注入 Step 4:清除注入并重启PHP-FPM Step 5:立即复测 此时已经返回正常内容。 为什么这个问题如此隐蔽? 因为它满足了所有“最难发现”的条件: 当然为了发现这个问题,gpt也引导我走了一些弯路: 结语 这是一次典型的 SEO Cloaking / PHP全局注入 案例。真正的教训不是“漏洞多高级”,而是思路能否正确,并推动排查往前走。希望这篇记录能帮你少走弯路。

Transaction Search中internal id作为搜索条件,一次最多可以搜多少个id

问题 以下代码中: workOrderIds最多可以放多少internal id呢? 经过实际测试 最多理论上无限制,但实际出bug的概率极大,很容易这个条件失效导致搜索出全部的transaction进而超时。在不失效的情况下,全部workorder数据140K条,搜索其中~6000条的情况下,大约耗时15分钟。 最佳方案是把workOrderIds的长度控制在1000以内,这样在总数据140K,按照id搜索其中~6000条,搜索运行6次并把结果拼接,大约耗时3-5分钟。 有待测试的问题 欢迎补充。

用Shopify GraphQL Admin API实现对账

问题 Shopify在实行GraphQL API之后没有之前的REST API的类似payout_id查询这笔到账对应哪些订单的功能,把问题抛给GPT得到了如下结论 这个方案会导致无法确定balance transaction的范围究竟有多大,需要调取多少才能收集完所有属于指定payout的数据 解决方案 根据文档显示,可以在query中添加payout_date和payout_status作为条件,形成如下的请求 此处query内容为显示payout date是2025-08-04的balanceTransaction,且payout状态是PAID。注意如果条件输错,请求过程中会忽视query的条件,直接显示所有结果。你也可以根据自己的需求调整nodes中显示哪些字段。 因为NetSuite的SuiteScript是不支持GQL的,我们需要把请求转换成http post请求,转换之后请求的body如下。请注意还需要设置X-Shopify-Access-Token和Content-Type=application/json。 请求的结果请参考文档。

macOS通过SMB访问群晖NAS提示密码错误

症状 macOS通过Go to server访问本地群晖NAS提示密码错误,SMB的版本设置最高版本SMB3,最低版本SMB2。重置用户名和密码无效。在Windows下访问正常。 解决方法 用户名改为全大写,问题解除。

SuiteScript开发中辨别环境

问题 如何设计程序可以在正式环境刷新沙盒后不会导致涉及接口的逻辑出现两个环境的混乱 解决方案 在开发时使用runtime.accountId进行逻辑判断,如果是正式环境则runtime.accountId是1234567这样的account ID,如果是测试环境则会包含沙盒的编号比如1234567_SB1。 对于向外发送请求的情况,可以针对环境不同设置不同的URL,这样正式环境的代码刷新到沙盒也不会导致沙盒请求外部系统的正式环境。