/ddddddiary

ルノアール。アルゴリズム。添字が苦手すぎる。

明日こそ早起きして図書館使いたい

とりあえず部屋片付けてルノアール行ってひとしきりいつものアルゴリズムとか。んあ〜　しばらくできてなかったんで、もう一回再起動するのがほんとにだるい。でもまあなんとかやった。

晩飯に乾麺作ったけどパスタと間違えて塩クソ入れてクソしょっぱくなった　ごまかそうとして油そば風にしたら更にしょっぱくなった

はあ〜ひたすら実装してなんとか間に合った。久々に徹夜したので反動で一日潰す。

実装する。ようやく認証周りに一段落ついたので、あと API、、、5割ぐらい終わったかな。

---

• SSH接続をWebブラウザの純粋なHTTP上で実現する
  • すごない？（4年前の記事）HTTP Streaming の未来感じたい
• Bun の非互換な拡張 API
  • Bun が調子乗ってるらしい　アカンかもな
• DHH discusses SQLite (and Stoicism) - YouTube
  • DHH がストイシズム（？）と SQLite について語る動画
  • まだ見てないけど絶対おもしろいだろ

実装してる。なんかいろいろ面倒くさい。なるべくサッと実装したいのだが・・・

---

• 今社内アプリの実装中。API サーバは Rust + Lambda、フロントは Vercel に置いた Next.js という構成。フロントの認証部分は既に作られていて、Auth.js （旧 NextAuth）を使って、外部のサービスプロバイダと OAuth 2.0 で認証している。API サーバにフロントで発行した認証情報を渡そうとしたところ面倒くさいことが起こった。
• Auth.js は Next.js のようなフルスタック系 JS フレームワーク用の認証ライブラリで、いろんな OAuth プロバイダをプラグイン的に簡単に導入できたり、サーバとクライアントでセッションを手軽に共有できるところに旨味がある。
• セッション共有の仕組みの基盤には cookie が使われていて、cookie として発行される値は認証した結果得られるユーザ情報を JWT にエンコードしたものになっている。
• しかし今回は API は別オリジンにあり、しかも別の言語で書かれているのだった。 なので cookie を API に渡すのは面倒だし（3rd Party Cookie になるので Safari で死ぬ、Next.js 側でプロキシすればいけるけど）、JWT を取り出して渡すことができたとしても、今度は受け取ったトークンを検証する複雑な Auth.js の関数を移植しなければならない。
  • とはいえ OAuth ダンスを自分で実装するのは辛いので Auth.js は使いたい。
• しかたないのでユーザ情報を簡単に検証できる（もちろん鍵で署名はするけど） JWT にして、API に送ってやる方針にした。
  • この判断を下すまでに時間がかかってしまった・・・