#fedimovie インシデント第三報です。

諸々手を打ち、サービス再開しました。

本件、都合上、noellaboを削除しました。それ以外の変更点はありません。

大きな事故につながる不具合を発生させ、また対応が遅れまして、大変申し訳ありません。

ユーザーがログインする仕組みのWebサービス（サイト）では非常に危険かつ初歩的なミス（やってはいけないこと）であり、お恥ずかしい限りです。

なお、本トラブル発生中にアクセスされたみなさんは、事情を察し、自身はアクセスを打ち切り、それぞれ報告をあげてくださいました。

本件が最小の対応で解決できたのは、すべてみなさんの善意によるものです。

一般にこのようなことは想定できないところで、極めてレアな、幸運な状況でした。ありがとうございました。

少し技術的なフォローをしておきます。

PeerTubeのようなログインベースのシステムは、同じURLに対するアクセスでも、ログイン状態やログインしているユーザーにより異なる内容を表示します。

他方、nginxやCloudflareのようなコンテンツをキャッシュするサーバは、基本的な動作としては、URLをキーにして、同じURLに対する2回目以降のリクエストを代理で応答する仕組みです。

そのままではユーザーごとに違う内容を返すシステムがうまく動かないので、キャッシュしてはいけない情報をアプリケーション（PeerTube）からつたえたり、キャッシュしてよい期限を短く指定するなど、キャッシュサーバが中継することを前提として、配慮した設計にします。

この点、MastodonやMisskeyはしっかり作られていて、単純にキャッシュサーバを介すようにしても問題は起きません。

PeerTubeはこのあたりはまだ調整中といったところで、基本的にはキャッシュは利用できず、一部、実験的な設定方法が案内されている段階です。
（つづく）
#fedimovie

FediMovieでは、この設定部分を誤り、設定変更後に最初にアクセスした管理者の情報がそのままキャッシュされ、他のユーザーに同じ情報が表示され、利用可能となる、重大な不具合を発生させてしまいました。

原理的にはそのようなところですが、よく確認する……というのはあまり参考にならないので、それ以外の教訓として……

今回の件では、管理者アカウントで日常使用することの危険がありました。

私個人のアカウントがみえたぐらいであったらあまり深刻ではないのですが、なにしろ管理者としての権限が付与されています。

実際は、初期作成の管理者は別に存在したのですが、切り替える手間を面倒くさがって、自分のアカウントに管理権限を付与しました。まあこれがマズイことが、本件、よくわかります。

もうひとつは、配布元の手順通りではない設定に踏み込むからには、対象システムの特性をよく調べておく必要があるということです。

この点、たいへん見込みが甘かった。コードをみるまでもなく、ドキュメントでわかる内容で、まあわかるだろう、大丈夫だろう、という慢心であったといえます。

反省しきりです。
#fedimovie