Orien Daily
- 📸 @turu3_kame3
今日明日と来週末は、吹奏楽の県大会してます。
皆さんの練習の成果が発揮されますように(人)
ここ数日、職場での全員に対象の課題や、事務局している舞台関連団体の監査や理事会総会資料を片付け、やっと昇段審査に向き合えます。私も普段の成果が発揮できますように(人)
来月初旬の予定です。 #剣道
原文 #剣道 - 📸 @YEJIDataBase
rockcake Instagram Story Update
🔗https://www.instagram.com/stories/rockcake_/3943722690834045228?utm_source=ig_story_item_share&igsh=eW90OWkzMmsxNTJp
rockcake Instagram 故事更新
🔗https://www.instagram.com/stories/rockcake_/3943722690834045228?utm_source=ig_story_item_share&igsh=eW90OWkzMmsxNTJp #YEJI #ITZY #있지 #예지 #イェジ #옞덩봤덩
原文 #黄礼志 - 📸 @YEJIDataBase
Brand P:ReinSein Instagram update
🔗https://www.instagram.com/p/Da6682vkxey/?igsh=emV5M2o4MmpldnUw
品牌P：ReinSein Instagram更新
🔗https://www.instagram.com/p/Da6682vkxey/?igsh=emV5M2o4MmpldnUw #YEJI #ITZY #있지 #예지 #イェジ #옞덩봤덩
原文 #黄礼志 - 📸 @storingyeji ×3
공주님 오늘도 너무너무너무 이뻐요🥺
http://xhslink.com/o/2kU4Z1K4PuL
公主，你今天也这么漂亮🥺
http://xhslink.com/o/2kU4Z1K4PuL #예지 #YEJI
原文 #黄礼志 - 📚 「〜にあたって」不是“做的时候”都能用
很多人写邮件、研究计划、实验说明时，会把「〜にあたって」当成高级版的「〜とき」「〜際に」来用，于是写出像「コードを実行するにあたって、Pythonを起動してください」这种句子。问题就在这里：「〜にあたって」不是单纯表示“在……的时候”，它带有“面对一个重要阶段、正式行动或关键节点，在开始前有必要做准备或说明”的感觉。它适合写在研究开始、系统导入、方针决定、調査実施、論文投稿这类场景里，不适合套在太小、太日常、太机械的动作上。
和它最容易混的有两个。一个是「〜際に」，这个更中性，重点只是“在……之际 / 在……时”，正式但不一定重大，所以能用的范围更广。另一个是「〜上で」，它强调“在……方面”或“为了……而必须先考虑的条件”，常和判断标准、注意事项、前提条件连在一起。简单说，事件本身有“启动某个正式事项”的分量时，用「〜にあたって」；只是说明某个时点或流程节点，用「〜際に」；如果是在谈条件、考量、运用上的前提，更常用「〜上で」。
比如研究和技术语境里，可以直接这样说。
本研究を開始するにあたって、先行研究の整理と評価指標の定義を行った。
在开展这项研究之前，我们先整理了既有研究并定义了评价指标。
新しい認証基盤を導入するにあたって、既存ユーザーへの影響を最小限に抑える設計が必要だ。
在导入新的认证基础设施时，需要采用把对现有用户影响压到最低的设计。
論文を投稿する際に、参考文献の書式が投稿先の規定と一致しているか確認してください。
投稿论文时，请确认参考文献格式是否符合投稿目标期刊的规定。
这里第三句故意用了「際に」而不是「にあたって」，因为重点只是投稿流程中的确认动作，不是在强调“投稿”这件事本身的重大启动感。要是你写成「論文を投稿するにあたって」，也不是一定错，但语气会更像“在正式进入投稿这一阶段之前，要先做哪些准备”，重心已经变了。
💡 記憶ポイント：遇到“研究开始、制度导入、项目启动、重要决定”这类有分量的节点，用「〜にあたって」最自然；如果只是“填写、确认、点击、执行”这种普通流程动作，别硬拔高，通常用「〜際に」或者更直接的「〜とき」。。 - 🔐 JWT Algorithm Confusion：为什么“验签”也会被你自己绕过
很多人第一次学 JWT，会把注意力放在“有没有签名”上，却忽略了更关键的一件事：服务端到底是按什么规则验这个签名的。JWT 头里有一个alg字段，告诉接收方“我用的是哪种算法”。问题就出在这里——如果服务端傻乎乎地信了这个字段，让令牌自己决定该怎么被验证，攻击者就有机会把“本该用非对称密钥验证的令牌”，伪装成“用对称密钥验证的令牌”，甚至在更糟的实现里直接改成none。这不是密码学失效，而是实现者把控制权交给了不可信输入。
现实里最典型的坑，是服务端原本想用 RS256。正常情况下，签发方拿私钥签名，验证方拿公钥验证，攻击者只有公钥也没法伪造。但如果验证库或业务代码写得烂，看到 JWT 头里写着HS256就切到 HMAC 模式，而且还把“本来公开的 RSA 公钥”当成 HMAC 的 secret 去验，那攻击者就能用这个公开公钥自己生成一个“合法”签名。于是整个认证系统从“只有私钥持有者能签”退化成“谁拿到公钥谁都能签”。这就是 Algorithm Confusion 的本质：不是数学被攻破，是程序把不同信任模型混在了一起。
为什么这种事会发生？因为很多系统把“解析 token”和“决定安全策略”塞进了一步，开发者图省事，直接把 token 丢进库里让它自动判断。自动判断在业务代码里通常就是灾难。安全边界不该由攻击者上传的头字段决定，应该由服务端配置决定：这个接口只接受 RS256，那就硬编码只验 RS256；这个 issuer 的 key set 是什么，也应该提前绑定，而不是收到什么就信什么。再往前一步，kid这种字段如果还能触发本地文件读取、远程取 key、或从多个 key 中随便选，那问题只会更大。
防御其实不复杂，但很多团队就是不做。第一，服务端必须显式指定允许的算法，不能从 token 头里“协商”。第二，不要把同一套验证逻辑同时兼容 HMAC 和 RSA/EC，混用就是在制造特殊情况。第三，验证时把 issuer、audience、过期时间、not before 一起校验，不要只看签名过不过。第四，选库时看默认行为，凡是“自动推断算法”“自动接受 none”“随手喂一个 key 就能跑”的库，都该提高警惕。安全问题最烦的地方就在这：代码看起来能跑，用户也能登录，但边界已经烂了。
🧪 你在审一个老系统，发现它验证 JWT 的代码会先读取 token 头里的alg，如果是RS256就用公钥验签，如果是HS256就把同一份配置里的publicKey字符串当作 HMAC secret。现在攻击者只能拿到公开公钥，不能拿到私钥。这个系统还能被伪造管理员 token 吗？为什么？答案：algHS256
💡 核心记忆：JWT 的算法选择权必须在服务端手里，绝不能交给 token 头自己决定。 - 🔑 Shell 里的 pipefail：为什么前面的命令明明失败了，脚本还显示成功？
很多人第一次写 Shell 管道时都会踩这个坑：cat missing.txt | grep hello | wc -l，明明最前面的cat已经报错了，整条命令最后却可能返回成功。原因不神秘，Shell 对管道的默认设计就是“看最后一个命令的退出状态”。这在交互式命令行里很实用，因为你常常真正关心的是最后产出的结果，比如grep有没有匹配到、wc有没有算完；但一进脚本，这个设计就容易把错误吞掉，让 CI 绿灯、日志好看、结果却是错的。pipefail就是拿来修这个默认行为的。打开set -o pipefail之后，只要管道中有一个命令失败，整条管道就会被判定为失败。这样一来，上游读文件失败、网络请求失败、解压失败，不会再被下游命令“洗白”。很多自动化脚本都会把set -euo pipefail放在开头，核心不是仪式感，而是尽早把坏数据拦住，别让后面的命令在垃圾输入上继续跑。
但这里还有个常见误会：pipefail不是“返回第一个失败”，而是“返回最后一个失败的非零状态”。这意味着它能告诉你这条管道出问题了，却不负责替你定位是哪一段坏了。真要查，就得看PIPESTATUS，或者把长管道拆开。好代码不是往一条命令里塞五六段玄学管道，而是让每一步都能单独验证。否则你得到的不是简洁，是一条难以调试的黑盒。
🧪 课后一题：执行false | true时，默认情况下退出状态是多少？开启set -o pipefail之后又是多少？答案：truefalse
💡 易混淆点：pipefail只影响“管道”里的退出状态，不会自动让所有脚本更安全；像变量未定义、普通命令失败、子命令逻辑错误，还要分别靠set -u、set -e和清晰拆分步骤来处理。
