Orien Daily
- 📸 @Chi419Haru45
みなさん応援📣ありがとうございました🥰
中学最後の個人戦
二回戦負けという結果で呆気なく終わりました😂
思惑通りにはならず悔しさが残った試合でしたが最後まで戦いぬきました🥹
ハル約2年半お疲れ様でした🥹
高校で心機一転頑張って😃
その前に受験勉強だけどね👍 #中学県総体 #剣道
原文 #剣道 - 📸 @goroukun_spp ×2
【唐津警察署】
唐津市内の高校へ出稽古に行き、地元の高校生と の試合等を行いました！
稽古前に自転車の交通マナーや警察官の業務等について説明を行うと、皆さん熱心に聞いてくれました✨ #剣道 #警察官募集
原文 #剣道 - 📸 @nisiosazane ×2
悩んだ末に購入
アクションと謎解きの両方とも物語重視でスタートしました
クリムゾンバタフライもありましたが最初なのでセーラ服でプレイします
プレイしてたらまさかの通り抜ける所でダウンロード待ちが発生したので今日は少ししかプレイ出来てません笑 #加藤小夏 #SILENTHILLf
原文 #加藤小夏 - 📚 「〜にあたって」と「〜際に」：写计划、说明步骤时别混用
很多人写技术文档或研究计划时，会把「実験を始めるにあたって」「実験を始める際に」随手互换。意思看起来都像“在……时”，但语气和使用场景不一样。「〜にあたって」通常用于开始某个重要阶段、采取某个正式行动之前，带一点“在这个节点上，需要先做准备或说明立场”的感觉，所以很适合写研究启动、系统迁移、协议变更、论文投稿这类场景。「〜際に」就更中性，单纯表示“在……的时候”，重点是时间点或场合，不一定有“郑重进入新阶段”的意味。
所以边界很清楚：如果你想表达“在开始一件重要事情之前，先做这些准备”，用「〜にあたって」；如果只是写操作步骤、注意事项、发生条件，用「〜際に」更自然。比如「データ移行にあたって、旧環境のバックアップを取得する」很顺，因为迁移本身是正式动作；但「ファイルを保存するにあたって、名前を入力してください」就别扭，这里只是操作步骤，应该说「保存する際に」。反过来，「発表の際に自己紹介をする」正常，但如果你写「共同研究を開始する際に、守秘義務契約を締結した」，语法没错，只是少了那种“项目启动前的正式准备感”；很多学术和商务文本里会更偏向「開始するにあたって」。
例句可以直接套用。研究室で新しい評価実験を始めるにあたって、再現性を確保するために乱数シードと実行環境を固定した。开始新的评测实验之前，为了保证可复现性，先固定了随机种子和运行环境。
サーバー証明書を更新する際に、クライアント側の証明書検証設定もあわせて確認してください。更新服务器证书时，也请一并检查客户端侧的证书校验设置。
論文を投稿するにあたって、関連研究との違いを一段落で明確に説明できるようにしておく必要がある。投稿论文之前，需要先做到能用一段话明确说明自己和相关研究的差异。
💡 記憶ポイント：「〜にあたって」＝；「〜際に」＝。如果后面只是机械操作说明，别硬用「〜にあたって」。 - 🔐 OAuth 回调劫持：为什么一个“差不多匹配”的 redirect_uri 会变成账号接管
很多人以为 OAuth 登录的风险主要在密码，其实大量事故根本不碰密码，而是出在回调地址redirect_uri的校验太松。OAuth 的核心流程是：用户在身份提供方登录后，授权码code会被浏览器带回业务方预先登记的回调地址。如果服务端只做“包含关系”“前缀匹配”或者允许任意子路径、任意子域，攻击者就能把本该回到你应用的授权码，骗去自己的页面，再拿这个code去换取 access token，结果就是用户刚正常登录，账号却被别人接管了。
为什么这种事会发生？因为很多系统把“能跳回自己网站”理解成了“域名看起来像自己就行”。比如把https://app.example.com/callback放宽成https://app.example.com/*，甚至更糟，允许https://*.example.com/*。一旦某个子域可被上传内容、可被接管，或者存在开放重定向，攻击者就能把 OAuth 服务器返回的code转走。麻烦在于，这不是用户输错密码，也不是浏览器中毒，而是协议落地时把“精确绑定”做成了“模糊容忍”。
现实防护也别搞玄学，直接把边界钉死。redirect_uri必须做精确匹配，最好精确到完整 URL；不要支持通配符子域；不要依赖“先跳到本站再 302 到别处”的补救设计；客户端在发起授权时要带高强度state防 CSRF，移动端和 SPA 还应该用 PKCE，避免授权码被截获后直接复用。还有一个常被忽略的点：如果业务里存在 open redirect，它本身就可能成为 OAuth 回调劫持的跳板，所以开放重定向不是“小漏洞”，放到认证链路里就会升级。
🧪 场景题：某公司把 OAuth 回调地址配置成https://login.example.com/*，而https://login.example.com/redirect?next=存在开放重定向。攻击者发起授权请求，把回调写成https://login.example.com/redirect?next=https://evil.com/catch。用户完成登录后，授权码最终会到谁手里？为什么？答案：login.example.comevil.com/catch
💡 核心记忆：OAuth 最怕的不是密码泄露，而是把授权码送错地方，所以redirect_uri必须精确绑定，不能“差不多就行”。 - 📸 @WhiteSoxVideo
ホワイトソックスが、レート・フィールドの売店に新メニュー「ムネショット」を導入しました。
これはアメリカ風の大型寿司ロールで、最初のロールを食べ終えると、底を押し上げることで中からさらに寿司が出てくる仕組みになっています。 #WhiteSox #村上宗隆
原文 #MLB日本選手 - 🔑 Shell 里为什么要有 exit status
很多人刚学命令行时，只盯着命令有没有“输出”。这其实抓错重点了。对 Shell 来说，一条命令最重要的不只是打印了什么，而是它最后到底算“成功”还是“失败”。这个结果不会靠一句英文提示来判断，而是靠一个很小但非常关键的数字：exit status，也就是退出状态码。
这样设计不是为了学术优雅，而是为了让程序能接着程序说话。人类看得懂 “file not found”，机器不该去猜你这句英文是什么意思。于是 Unix 很早就定了个朴素规则：命令结束时交一个整数出来，0 表示成功，非 0 表示失败。Shell 再根据这个数字决定后面该不该继续执行，比如cmd1 && cmd2只有在cmd1成功时才跑cmd2，而cmd1 || cmd2则是在cmd1失败时才补上第二个命令。你平时觉得这些符号顺手，背后靠的就是 exit status，而不是输出文字。
这里最容易踩坑的地方是：有输出，不等于成功；没输出，也不等于失败。比如grep pattern file找到了会返回 0，没找到常常返回 1，但这不代表程序坏了，只是“没匹配到”。再比如有些命令明明打印了一堆错误信息，如果你不检查$?，或者不把它放进&&、||、脚本的错误控制里，Shell 还是可能继续往下跑，把后续步骤也一起搞脏。更坑的是管道。很多人以为cmd1 | cmd2里只要前面炸了，整个就算失败；实际上默认情况下，Shell 往往只看最后一个命令的退出状态。所以前面已经出错，后面命令如果照样退出 0，你会得到一个“表面成功”的假象。这就是为什么写严肃脚本时常要加set -e，甚至set -o pipefail：不是为了显得专业，是为了别让错误悄悄溜过去。
你可以把 exit status 理解成命令行世界里最基础的协议。输出是给人看的，状态码是给系统接线用的。没有这个约定，自动化脚本、CI、部署流程都会变成一堆脆弱的字符串匹配，稍微换个报错文案就全废了。
🧪 课后一题：执行false && echo ok || echo fail，终端最终会打印什么？为什么？答案：failfalse&&echo ok||echo fail
💡 易混淆点：0在编程里常像“假”，但在 Shell 的 exit status 里，0恰恰表示成功，非0才表示失败或特殊情况。
