この前から夜中に暇々にtsedで作っていた API おもちゃもある程度まとまってきて、動かすサーバーも調整していて、先の連休で動くかなーとか思っていたら、本番にデプロイしたら動かない。。。

ローカルで動くが本番で動かない的な話は、ロジックミスではなく設定ミスみたいな話が多いので、気づけば1文字修正で直るが、把握できなければ延々何ヶ月かけても解決しない的な話になりがち。。。(プログラマの徹夜ってのはこういうので起きやすい)

細かく切り分けをやってみると、今度は「デプロイしたAPI側でセッションが保存出来ない(アクセス都度にセッションが変わる)」という現象が見えた。

セッションが保存できないみたいな話はphp案件でも見たことあった話で、これもまたwebサーバーや環境設定的な話で延々時間を食われる予感がする訳で。。。

で、ふとchrome側のコンソールを見ると以下のメッセージが。

A cookie associated with a cross-site resource at http://..... was set without the `SameSite` attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

ネット検索してみると、ブラウザのセキュリティ強化で cookie(セッションの識別に使われる)のクロスサイト共有したければ`SameSite=None` and `Secure`の設定が必要との話。

おもちゃのAPIだからユーザ管理や認証の仕組みを最小限(最小限が必ずしも悪い訳では無く、仕組みが単純化するので弱くはない)にしようとしていた訳だが、そこをはしょったら怒られた訳です。結果として`SameSite=None` and `Secure`を設定したら解決。

Server.ts

this.app.raw.use(session({
      secret: process.env.SESSION_SECRET || "",
      resave: true,
      saveUninitialized: true,
      store: store,
      cookie: {
        sameSite: "none",
        secure:true
      }
    }));

いや、こんなのはwebの専門家じゃないとわからんだろう と思いつつも、そのあたりを見越して詳細なエラーメッセージが出るのが今風だなぁと。

でも個人おもちゃ作りで、休日2日くらい食われるのはちともったいない。